The customer has asked us to investigate a little more what requirements are necessary on their side to be able to establish mTLS in the Web Services Data Action that we should establish with their middleware ( called API Gateway).
We initially proposed the first option (Genesys Cloud-signed client certificate for mTLS), which is the one Genesys recommends in their link: https://help.mypurecloud.com/faqs/is-the-mutual-tls-mtls-certificate-publicly-trusted/
In fact, we sent them the root certificate (CA) provided by Genesys, but apparently, for the API Gateway is not a trusted certificate authority (Amazon), and they also rejected it because they could not give them all the intermediate and final certificates, therefore, we could only go the way of (Publicly trusted mTLS client certificate) with DigiCert.
Can you tell us what steps the client must take to establish mTLS with Digicert? where we should upload de Digicert certificate?
As I understand, Genesys Cloud, like our customer Caixabank, has its certificate store in which it trusts, which are all Mozilla certificates.
In the case of Caixa, they will be trusted by the store that has the gateway api, and we already know that it trusts digicert.
On the other hand, when a client (Genesys Cloud) requests a petition to a server (API Gateway), the server presents its certificate and also asks the client to present its own. The client sends its certificate and when the server receives the certificate, the server searches in its store if the CA that signs the client's certificate is there, if it trusts it.
So I have to know what the client must load in its store to trust the certificate issued by Genesys cloud using, is it correct? Thanks in advance
You are correct that in order to leverage data actions in an mTLS environment, you must possess the client certificate in order to add it to your trust store so your API gateway/firewall so that it can be accepted when presented by the data action as it's client certificate. For the Genesys Cloud Certificate Authority, this trust relationship can be established at the root level, meaning that all certificates signed by that CA are accepted; this allows for the trust relationship to be established once, and as certificates are renewed there is no further action to take on your part. This root certificate is available in our resource center: MTLS support for data actions - Genesys Cloud Resource Center The Genesys Cloud certificate authority is a privately held CA, which is maintained as a part of the Genesys Cloud ecosystem. Because of this, there are no intermediate certificates, and the "final" certificate is rotated out automatically with no advanced notice; this is why the recommendation is to establish the trust relationship at the root level, as that allows everything to behave in a fully automated fashion.
With Digicert as the CA, the situation becomes a little more complicated. Because the CA is not unique to Genesys Cloud, it's not recommend that the trust relationship be established at the root level (otherwise ANY Digicert signed certificate would be accepted, essentially negating any potential benefits of mTLS), but rather at the leaf/individual certificate level. This certificate is available by performing a GET on the API route /api/v2/integrations/actions/certificates. This route will return both the current certificate, and any pending certificate that will be deployed soon (more on this in a moment). This certificate is what will be presented by the data action when the integration is configured to use Digicert as the CA and the remote endpoint requests a client certificate.
Using Digicert as the CA also means that there is a little more involved on your end when it comes time for the certificate to be renewed (approximately once a year). When Genesys Cloud renews our client certificate with Digicert, a notification will be sent out via the operational console (currently available via API) notifying customers that there is a new pending certificate. That pending certificate will be kept in waiting for approximately one month, giving customers time to fetch the new certificate from the route previously mentioned and adding it to their trust store. This operation must take place prior to the expiration of the current client certificate in order to avoid any service disruption. Near the expiration of the current client certificate, the Data Action service will "rotate" in the new certificate and begin presenting it when requested by the remote endpoint. At that point the old certificate will be removed from usage, and can be safely removed from your trust store (if you so choose).
@Richard.Schott thanks!!!!! And just to know....the certificate is unique for every organization?? Or is the same certificate around all orgs in same region??? Thanks
Same certificate. the purpose of mTLS here is not to serve as some secret used to access your specified APIs; that is the purpose of the credentials on the integration used by the data action. mTLS in this context is simply to provide assurance that it is in fact the Genesys Cloud platform that is contacting your APIs as a "pre-filter" before secrets are even exchanged.
THis is what this GET method gives me (using postman):
{"message":"The requested operation failed with status 501","code":"not.implemented","status":501,"contextId":"36dd6238-3110-4154-b302-e68042da3359","details":[],"errors":[]}
using a Oauth with admin role, so it not seems to be implemented yet, when is going to be implemented in Dublin orgs?