Atomia Cloud Hosting Platform

Certificates in Atomia

Tags: 225 views 0

The certificates that are used in Atomia, their roles, and how to generate new ones.

Certificates and their roles

Certificates are an important part of Atomia and are used to keep the communication between applications secure. This section will describe the different types of certificates used within Atomia.

All Atomia applications have their own certificates which are used to identify the application when communicating with other parts of Atomia. These certificates are defined in their respective applications web.config in the <serviceCertificate> section and are identified by the certificate subject. More information about the function of these certificates can be found here. The following certificates exist in this category (we are assuming the domain for your Atomia environment is myatomia.com):

  • accountapi.myatomia.com
  • actiontrail.myatomia.com
  • admin.myatomia.com
  • automationserver.myatomia.com
  • billing.myatomia.com
  • billingapi.myatomia.com
  • hcp.myatomia.com
  • login.myatomia.com
  • orderapi.myatomia.com
  • sts.myatomia.com
  • userapi.myatomia.com

The GUI applications use a shared certificate for authentication purposes.

  • guicert.myatomia.com

All authentication tokens created by AtomiaIdentity are signed and later validated using a signing certificate.

  • stssigning.myatomia.com

Passwords and other private data stored within the Automation Server and Atomia Billing are encrypted using two encryption certificates. These certificates are normally not replaced. However, if these for any reason need to be replaced all values have to be re-encrypted with an application that Atomia provides upon request.

  • automationencrypt.myatomia.com
  • billingencrypt.myatomia.com

All Atomia frontend applications are served via https. A wildcard certificate is normally used for this purpose.

  • *.myatomia.com (wildcard)

Generating new certificates

By default Atomia generates a set of self signed certificates with an expiration time of ~10 years. If you for any reason need to generate new certificates there are a few things to consider.

Important!

Don’t renew the Data encryption certificate used by the AutomationServer. It’s usable even when expired. If you renew it, you’ll have to re-encrypt all the password properties in the AutomationServer DB using an app that Atomia will provide to you on request.

Keep in mind

  • Make sure that the transformation files are using the new certificate hashes.
  • Make sure that the atomia.ini (unattended.ini) is updated with the new certificate hashes, so that that the right values are set when applying transformations.
  • Atomia certificates are needed not only in Personal store, but also in Trusted People. Therefore, make sure that the you have the newest certs in the right places.

With this in mind, generating new certificates to replace the current ones is done by following the following procedure:

  1. Clone the puppet-atomia repository from https://github.com/atomia/puppet-atomia.git.
  2. Navigate to files/certificates.
  3. Execute the following command:
    4.  mkdir -p /etc/puppet/atomiacerts/
  4. Invoke the script generate_certificates.rb with parameters <appdomain> <login> <order> <billing> <hcp> <environment>. This generates your new certificates to /etc/puppet/atomiacerts/atomia.
    • For example: 
      ruby generate_certificates.rb mydomain.com login order billing my atomia

      Where mydomain.com is the domain used for your Atomia applications and login, order, and billing, whereas my stands for the sub domains used for the respective applications.

  5. Copy the pfx certificates to your Windows servers that are running the Atomia applications.

Generating certificates during scheduled maintenance

The instructions below this point will disrupt the normal functionality of your Atomia applications and should only be performed during scheduled maintenance.

  1. On the Windows servers open the certificate manager and navigate to the Personal certificate store.
  2. Replace the old certificates one by one with the new certificates you generated previously. The replacement is done as follows:
    1. Click a certificate and press delete.
    2. Go to File > Import and import the new certificate with the same name.

Important!

Do not replace the encryption certificates (automationencrypt…, billingencrypt…) unless you have a good understanding of what you are doing, since these certificates will work even though their expiration dates have passed.

  1. When all the certificates in the list (except the encryption certificates) are replaced, change to the Trusted People certificate store and replace the two certificates available there as well.
  2. Finally go to the Trusted Root Certificate store and replace the Atomia Root Certificate with your newly generated root cert.
  3. If you did not perform the puppet run above you should now manually update the thumbprints of the certificates in the Atomia INI configuration file located in C:\Program Files (x86)\Atomia\Common\unattended.ini.
  4. Replace RootCertThumb with the thumbprint of the new root certificates. These can be found by double clicking the root certificate in the certificate manager and clicking Details and finding the value for the Thumbprint field.

Keep in mind

Make sure not to get any whitespace when copying the thumbprint value.

  1. Replace SigningCertThumb with the thumbprint of the stssigning certificate.
  2. Save the file.
  3. Go to C:\install and run the powershell script: 
    recreate_all_config_files.ps1
  4. Restart IIS.
  5. Make sure all the steps above are done on all servers running the Atomia applications.

Was this helpful?

Related Articles