Menu
I’ll address the first two certificates together as they are closely related, yet distinct in their applications. These certificates fall under the “DocuSign Network Traffic Certificates” tab on DocuSign Support and are essential for encrypting traffic for specific DocuSign services:
When focusing on the account server certificate, it’s important to note that the associated endpoint or service is readily visible when attempting to log into your DocuSign account.
For instance, in the demo environment, the endpoint appears as: `https://account-d.docusign.com`, while for production accounts, it appears as: `https://account.docusign.com`.
This information is also visible when authenticating to DocuSign via the API. In the provided image, authentication is done using JWT. For further details on authentication methods with the REST API, refer to the documentation on eSignature REST API Authentication.
In both examples provided, the URL utilises HTTPS, indicating that the connection is encrypted using TLS. For certain custom integrations, you may opt to verify the certificate. If you decide to do this, you will need the certificate provided by DocuSign, which is typically renewed annually.
Upon authentication into your DocuSign account, the Site certificate comes into play. You’ll observe that after logging in, the endpoint shifts from https://account-d.docusign.com to either https://apps-d.docusign.com/send/home or https://apps.docusign.com/send/home in production environments.
Once again, the connection is secured via HTTPS, and similar to the previous certificate, you have the option to validate this certificate for your custom integration.
In the image provided, the endpoint is shown as demo.docusign.net (displayed as apps.docusign.com in the UI). Depending on the production server serving your account, this endpoint may also vary and could be one of the following: eu.docusign.net, na1.docusign.net, na2.docusign.net, na3.docusign.net, na4.docusign.net, au.docusign.net, or ca.docusign.net.
While this isn’t an exhaustive list of endpoints, these examples should illustrate the underlying concept. Additionally, all endpoints reflect the location where your account is hosted. DocuSign’s services are hosted across different regions, including EU, NA1, AU, and others.
In the intricacies of certificate validation, it’s essential to delve deeper into the process.
SSL operates with the client connecting to our server, where our server sends a certificate chain. Subsequently, the client utilises these certificates for encrypting and decrypting data. For instance, when you visit https://docusign.com, this entire process occurs within your browser, utilising our certificates seamlessly.
However, the necessity for installing our SSL certificates arises due to trust issues. For instance, older platforms like Java 8 may not inherently trust our root certificate. In such cases, you can choose to install our certificate into your app’s trust store, effectively affirming its safety and establishing trust. Alternatively, some setups mandate SSL to be trusted solely through installed SSL certificates in your trust store, although this is a relatively uncommon scenario compared to the Java 8 issue. Generally, SSL operations proceed seamlessly, but these considerations become pertinent in ensuring robust security protocols.
In this segment, I’ll outline two distinct types of single sign-on (SSO) certificates, aiming to maintain clarity without delving into intricate details. However, I’ll include additional links for experts seeking deeper insights into the subject matter.
This particular SSO certificate requires uploading within DocuSign Admin. It’s often confused with the account server certificate we previously discussed, given their association with authentication. However, the distinction lies in the fact that the SSO certificate is utilised for users logging in via single sign-on, typically employing SAML. This certificate is commonly furnished by your Identity Provider (IDP), such as Okta, Azure, Ping Identity, among others.
When this certificate expires, users may lose access to their DocuSign accounts via SSO. Given that the certificate’s provider may vary, it’s crucial to be cognisant of its origin and expiration date. This awareness allows for timely updates within DocuSign Admin to avert any disruptions. The certificate can be conveniently updated in DocuSign Admin under the Identity Provider settings.
The self-signed certificate is available on our DocuSign SSO Service Provider Certificate support page. For a more comprehensive understanding, please refer to the DocuSign support page titled “DocuSign SSO Cert Renewal – Action Required.”
This SSO certificate functions solely as a key container. It is utilized to store the key for the following use cases:
2. SAML responses from Identity Providers (IDPs) are encrypted using the public key, and subsequently decrypted on our end using the corresponding private key. This encryption and decryption process is configured by the IDP.
DocuSign Connect serves as a publishing service, functioning akin to a reverse API service. Users have the option to employ a custom webhook or application to receive events generated on the platform, such as “envelope sent”. Upon occurrence of such events, configured webhooks or applications are intended to receive pertinent event information.
To bolster security measures, Mutual TLS authentication and authorisation can be integrated into DocuSign Connect configurations. This ensures the verification of server identity to the client and vice versa, establishing a two-way encrypted channel between the two entities. For further insights into this topic, please refer to our developer guide.
Copyright FourierIT. 2020