ishenwei/nexus
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b40abbcd473a7093d8261e212e3d6de97c1e516a
nexus/knowledgebase/csd-wiki/ICSD/Renew-customer-certificates-in-Nginx_688996480.md

4.4 KiB
Raw Blame History

Renew-customer-certificates-in-Nginx_688996480

Renew certificates for customer managed SMAX/CMS/OO FQDNs

Customer is responsible to monitor certificate validity and should open PCS tickets when it's time to perform renewals.

Note

Please follow the SaaS Ops procedure to work with the customer to create the customer-managed FQDNs and generate publicly signed certificates.

Renewal Steps Overview

  1. Customer opens PCS ticket asking to renew certificates.
  2. SaaS Ops uses normal procedure to generate certificate/key and send the crt's to the customer for signing by their CA.
  3. Customer sends back the signed certificates.
  4. SaaS Ops installs the new crt/key files into Nginx instance - and performs Nginx reload to pull in the renewed certs.
  5. SaaS Ops test and validates certs have been renewed.

Typical Certificates Example

Typically for each customer tenant a set of 3 FQDNs will be required, with examples shown for the certificate naming convention:

DNS name (customer) CNAME (SaaS-managed) Certificate/key
smax.esm-api.acme.com smax.api..esm-saas.com smax-acme.crt, smax-acme.key
cms.esm-api.acme.com cms.api..esm-saas.com cms-acme.crt, cms-acme.key
oo.esm-api.acme.com oo.api..esm-saas.com oo-acme.crt, oo-acme.key

If a customer has multiple tenants that need to be enabled for zero trust, use a prefix for the DNS name. For example for a test tenant:

DNS name (customer) CNAME (SaaS-managed) Certificate/key
tst.smax.esm-api.acme.com tst.smax.api..esm-saas.com tst-smax-acme.crt, tst-smax-acme.key
tst.cms.esm-api.acme.com tst.cms.api..esm-saas.com tst-cms-acme.crt, tst-cms-acme.key
tst.oo.esm-api.acme.com tst.oo.api..esm-saas.com tst-oo-acme.crt, tst-oo-acme.key

The customer will also need to provide the SaaS team with publicly signed certificates for their FQDNs - these will be required by nginx as described below.

There is also a Client "Intermediate" certificate, as specified in the nginx.conf file. On some occasions, if customer changes it then it will need to be updated on our side as well:

ssl_client_certificate ssl/ clientCA.crt;

Note

Public certificates have to be generated by the customer. We cannot use AWS-generated certificates in this case.

Install Renewed Certificates/Keys

  1. Open SSH session to the Nginx instance.
  2. Check the Nginx config file: /etc/nginx.conf and confirm the location and names for the certificates. You should see section like the following for each of the API endpoints listed in the table above. Here is the example for SMAX:
    ssl_certificate ssl/tst.smax.crt; # the location of the server certificate generated for the server specified in server_name;
    ssl_certificate_key ssl/tst.smax.key; # the location of the private key of the generated for the server specified in server_name;
  3. Notice the folder and name of each file. To avoid having to change the nginx.conf file it's advised to use the same folder and names.
  4. Backup the previous crt/key files. And then replace them with the new ones.
  5. Reload the Nginx configuration with: systemctl reload nginx
  6. Confirm Nginx status with: systemctl status nginx
  7. Test and verify the renewed certificates.

Related pages

Reference in New Issue View Git Blame Copy Permalink