Adam Arrowsmith

April 2016 Release: New Best Practices for SSL Certificate Management

Blog Post created by Adam Arrowsmith Employee on Apr 13, 2016

The April release delivered the remaining functionality for improved SSL certificate management that began in March. You can now deploy public X.509 SSL certificate components independently of processes, view certificates available on the Atom (both your user certificates and the standard Certificate Authority certificates within the Atom's Java runtime), and identify expiring certificates. I wanted to discuss how these features work together and share a few new best practices.


Deploying certificates independently is an optional approach and can work in tandem with deploying certificates the "old fashioned way" as part of process deployment. It's not going to break existing processes and you don't have to cut over in one big bang (or at all). However the features were introduced to address some real challenges. Let's talk about that.



Before getting into the details and in order to make sense of why these features exist, it's important to understand the motivations and pain points. The functionality arose from three common challenges when setting up and managing SSL certificates:

  1. Technical know-how to add a certificate manually to the Java keystore, typically via the command line
  2. Access to the Atom installation to manually add the certificate. Organizational access control policies can make this difficult. Also this is a nonstarter for using the hosted Dell Boomi Atom Cloud.
  3. Handling expiring certificates. First, you need to update that certificate component and redeploy the process, typically requiring some level of validation testing. Second, if you're in the middle of making other changes to the process that aren't ready to deploy yet, you have a real versioning dilemma. And third, to avoid execution failures when there's a non-backward compatible certificate change, you need to carefully coordinate your deployment with the cutover on the destination side.


Separating the certificate deployment from the process has some real practical operational benefits. With that said, let's take a closer look at how the certificate deployment and management features work to clarify exactly what does and does not apply.


Deploying Certificates

You can deploy certificate components directly to environments or atoms just like processes. Certificate deployments follow the exact same mechanics as process deployment and exhibit all the same behaviors with respect to versioning, audit trail, and re-deployment.


On the Deploy tab, select Certificates from the chooser:



You CAN deploy:

  • Public X.509 (SSL) certificates. These are the certificates obtained from the destination application/party and primarily used to encrypt the communication channel. They can also be used for authentication and digital signatures. Common connectors include:
    • HTTP Client (Trust SSL, Client Auth)
    • Web Services SOAP Client (Trust SSL, Client Auth SSL)
    • Mail (Use TLS, Use SSL)
    • AS2 Client including within the Trading Partner component (SSL only, not encryption or signing)


You CANNOT deploy:

  • Private X.509 (SSL) certificates. These are the certificates generated/obtained for yourself and used when receiving requests from another application/party.
  • PGP certificates (public or private). These are the certificates generally used to encrypt the actual document payload, often when exchanging data via FTP or SFTP.
  • SFTP SSH keys. These are not even certificate components currently.


Viewing Certificates

In Manage > Atom Management > select Atom > Certificates you can view the certificates on the given Atom. This is a real time snapshot of what's in the Atom's trust store including both your deployed User Certificates as well as the Certificate Authority certificates included by default in Java runtime used by the Atom. It retrieves the list of certificates from the Atom upon request so the Atom must be online.


To view a certificate's technical details, click the name or arrow. Additionally for User Certificates click Manage next to each certificate to find more information including how it got there (direct deployment, process deployment, shared web server, etc.) and a link to view the certificate component.


User Certificates tab INCLUDES:

  • Public AND private X.509 (SSL) certificates from:
    • Independently deployed certificates
    • Referenced with a normal process deployment
    • Atom shared web server SSL (private)
    • Atom shared web service User Management's client certificates for authentication


User Certificates tab DOES NOT INCLUDE:

  • PGP certificates (public or private)
  • SSL certificates set via connection extensions for the environment or Atom (however extensions is no longer necessary, see best practices below)


Certificate Authority tab INCLUDES:

  • Trusted root certificates included by default in the Java runtime used by the Atom. These are the certificates from authorities like Thawte, VeriSign, Go Daddy, etc.
  • Any certificates you previously added manually to the Java keystore


Certificate Expiration

When a certificate is nearing expiration--within the next 30 days--you will know about it in two ways:

  • A system warning message in your Notification Menu:
  • Warning presented in User Certificates table, highlighted in red:


NOTE: It does NOT send an email alert and there is no API currently to query certificates.


Certificate Selection at Execution Time

There a few things to understand about certificate selection when executing processes:

  • The Atom will use the "closest certificate". If a process's connection references a certificate and you also deploy the certificate independently, it will use the version referenced in the connection. This means if the process connection references an expired certificate but you deploy the new certificate independently, the process will still use the old one and fail.
  • To execute in Test Mode, you will first need to deploy the certificates to the Atom on which you wish to run.


New Best Practices

Now that you have a better understanding of what the new features do, let's talk about how you should use them. Again these new features are an optional approach, can be introduced slowly, and can work in tandem with existing process deployments.


Configuration and Deployment

  • DO use independently deployed certificates for HTTP and Web Services connection endpoints, especially for widely shared connections. Do NOT use connection extensions for these certificates. DO leave a note in the connection's Description field that the certificate reference is left blank intentionally and will be deployed independently.
  • However DO NOT use independently deployed certificates for AS2/trading partners endpoints. Because SSL is often not used for AS2 and because independently deployed certificates do not apply to encryption and signing (the "operation-level fields"), it is recommended to continue to use connection/trading partner extensions or to simply modify and redeploy the process. Because trading partner integrations tend to be relatively stable once implemented and insulated from other integrations, there is generally less regression risk.
  • As for transitioning to this approach, if you have a certificate expiring soon you'll need to update the process anyway make the change now. Otherwise adopt a change-as-you-go strategy: as you need to make other changes to a given process, look to remove the certificate configuration within the connections and deploy the certificates independently. Don't worry about "duplicating" deployed certificates or if some processes are using the deployed certificates vs. a locally-referenced one.
  • Continue to use extensions for environment-specific PGP certificates because they cannot be deployed independently.
  • For SSL Mail connections you can now run these processes in the hosted Atom Cloud (assuming access to the mail server) because you can deploy the certificate independently.



  • Review the certificates in Atom Management at least once a month for any expiring certificates.
  • If you receive a new certificate for a destination application/party, import and deploy it at your convenience any time before the expiration date. It will be there and ready to be used when the time comes.
  • If you need to see by whom and when a certificate was changed, review the audit history in the Deploy screen.


Certificate management may not be the most exciting task but when you have to scramble to replace a certificate in a hurry, you want to be able to do it quickly and easily. So give these new features a try and let us know what you think!