Upload a digital certificate
Upload a server certificate, or create a CSR for your certificate authority to sign, and bind the certificate to a workload.
You can add a certificate that a certificate authority (CA) issued for your domain to Certificate Manager and bind it to a workload, from Azion Console, the Azion CLI, or the API. For a certificate that Azion requests from Let’s Encrypt and renews, refer to Request a Let’s Encrypt certificate. For the Trusted CA certificate that checks client certificates, refer to Configure mTLS on a workload.
A server certificate covers the hostnames a workload serves over HTTPS. You get one in either of two ways: you upload a certificate with its private key, or Certificate Manager creates a certificate signing request (CSR) and keeps the private key while your CA signs the certificate. Either way, a workload uses the certificate only once its tls.certificate field names it, and the certificate reads inactive until then.
An account that runs on API v3 with Domains selects the certificate on each domain instead. For more information, refer to Domains.
Select an interface. The prerequisites and the steps of each task follow your choice.
Prerequisites
- A workload that lists your domain in its domains. To add the domain, refer to Add a custom domain to a workload.
- To upload a certificate: the certificate in PEM format and its private key, with no passphrase. RSA 2048 keys and P-256 keys are accepted.
- To create a CSR: a domain your account has permission to use.
- Access to Azion Console. For more information, refer to How to access Azion Console.
Upload a server certificate
Certificate Manager stores the certificate with its private key, and it never returns the private key afterward. Intermediate certificates are accepted with the certificate.
To upload the certificate with the Azion CLI, pass the certificate file and the private key file:
The command prints the ID of the new certificate:
To confirm the upload, list your certificates:
This excerpt of the output shows the certificate as inactive, because no workload uses it yet:
A private key the API cannot read is refused with The provided private key is invalid. Please check the key and try again. Send the key that matches the certificate, in PEM format and without a passphrase.
Create a certificate signing request
A CSR lets your own CA sign the certificate while Certificate Manager generates and keeps the private key. Name the hostnames the workload lists in its domains. The API accepts a certificate whose names do not match those domains, so it does not catch the mismatch for you.
To create the CSR with the Azion CLI, pass the hostnames and the details of your organization. --alternative-names takes a comma-separated list, and --key-algorithm takes rsa_2048, rsa_4096, or ecc_384:
The command creates a certificate entry that holds the request in its csr field. The entry reads pending until you add the certificate your CA signs.
To read the request, find the entry’s ID with azion list digital-certificate --details, then describe the entry:
The csr field of the output holds the request, with each line break written as \n. Convert those to line feeds before you submit the request to your CA.
A request that names a hostname in a domain your account has no permission for is refused with This account cannot use certain common or alternative names because it does not have permission for their domain names. For the meaning of each CSR field, refer to Certificates.
Submit the request to the CA of your choice, such as DigiCert, GlobalSign, or IdenTrust. The CA validates the details in the request and, once it approves them, issues the signed certificate.
Add the signed certificate to the CSR entry
The certificate your CA signs completes the entry that the certificate signing request (CSR) created. Add it in Azion Console or with the API, in PEM format, including its -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines.
To add the signed certificate with the API, send a PATCH request to the entry, with the certificate in certificate. Write every line break as \n:
The API answers 200. The entry holds the signed certificate, and you can bind it to a workload.
Bind the certificate to the workload
A workload uses a server certificate once its tls.certificate field holds the certificate’s ID. From that update on, the certificate reads active. Make sure the certificate covers the hostnames the workload lists in its domains: the API accepts a certificate whose names do not match them.
To bind the certificate with the Azion CLI, save a JSON file with the workload ID and the tls object, here as tls.json. Keep ciphers and minimum_version at the values the workload already holds. This example shows the defaults of a new workload:
Update the workload with the file:
The command prints the ID of the workload it updated:
To confirm the binding, list your certificates:
This excerpt of the output shows the certificate as active:
A Trusted CA certificate in tls.certificate is refused with Invalid certificate type, MUST be an Edge Certificate. To go back to Azion’s own certificate, select Azion (SAN) in Digital Certificate, or send null in tls.certificate.
Binding a certificate is a workload change, which takes several minutes to reach all of Azion’s distributed infrastructure. Requests can receive the old or the new configuration meanwhile. For certificate errors and their fixes, refer to Troubleshoot Workloads.
Replace a certificate before it expires
A certificate you upload does not renew itself, and once its validity date passes, it no longer protects traffic. To replace it, upload the new certificate as Upload a server certificate describes, then bind it as Bind the certificate to the workload describes. The old entry reads inactive once no workload names it. Delete it after the new certificate is active and the change has propagated.
For why to switch while the old certificate is still valid, refer to Workloads best practices.