You need a TLS certificate to transfer data over HTTPS. Using the HTTPS protocol with a certificate ensures that your customers’ data is securely transferred over the Internet, demonstrates the reliability of your website and the authenticity of your domain, and improves your website’s position in search engines like Google.
At Azion, you can rely on the following TLS certificate options for HTTPS traffic:
- Azion SAN: register your domain as a Subject Alternate Name (SAN) under Azion’s certificate.
- Custom certificate: add your personal TLS certificate obtained from a Certificate Authority (CA) or a Trusted CA.
- Let’s Encrypt certificate: request the issuance of a Let’s Encrypt™ certificate managed automatically by Azion.
You can also issue a Certificate Signing Request (CSR) via Azion to request a certificate from a CA.
ImplementationSection titled Implementation
Azion SAN certificateSection titled Azion SAN certificate
When using Azion Edge Application, our TLS certificate for HTTPS traffic is available at no additional cost. When you create a domain for an edge application in Real-Time Manager, your application is assigned an address in the
If you wish, you may use the assigned domain to deliver your static content over HTTPS, avoiding the costs of issuing TLS certificates for approval environments or URLs whose domain can be shared with other Azion customers. This way, your domain will be registered as a Subject Alternative Name (SAN) under Azion’s TLS certificate.
Custom certificateSection titled Custom certificate
If you want to use a custom domain, you can register your own TLS certificate (X.509) at no additional cost in Real-Time Manager. To use this feature, you’ll need to prove that the domain is really yours.
To use your Custom Certificate with Azion, the Server Name Indication (SNI) extension of the TLS protocol is used. Check the browser list with SNI support.
ValidationSection titled Validation
There are three types of validations that you can choose:
|Domain Validation (DV)||Organization Validation (OV)||Extended Validation (EV)|
|Validates your right to use the domain and it’s the simplest of the three options. This is the option recommended by Azion for most companies.||Validates your right to use the domain and some further validations about the requesting organization.||It’s an extended validation, which requires additional documentation to prove the physical, legal, and operational existence of the requesting organization and the most complex of the three options.|
Azion currently works with two types of certificates: RSA and ECC/ECDSA. Each certificate has its characteristics and its security level, and Azion allows you to choose the option that best fits your scenario.
RSA encryptionSection titled RSA encryption
Rivest-Shamir-Adleman (RSA) is one of the earliest public key cryptography systems and it is widely used for the secure transmission of data. In this encryption system, the encryption key is public and is different from the decryption key that is secret (private). Any message encrypted using a public key can only be decrypted using the respective private key.
RSA is a relatively slow algorithm and is therefore less used to directly encrypt user data. Most often, RSA passes shared encrypted keys to symmetric key encryption, which in turn can perform mass encryption-decryption operations at a much faster rate.
ECC/ECDSA encryptionSection titled ECC/ECDSA encryption
Elliptical Curve Cryptography (ECC), specifically Elliptic Curve Digital Signature Algorithm (ECDSA) for digital certificate encryption, is an approach to public key cryptography based on the algebraic structure of elliptical curves. Public key cryptography is based on creating mathematical puzzles that are difficult to solve, therefore it becomes much more secure than other types of certificates such as RSA.
Smaller keys are less computationally intensive to generate signatures because they involve smaller mathematical numbers. ECC is faster in generating signatures and has better performance than RSA.
Trusted CA certificateSection titled Trusted CA certificate
A Trusted CA is an entity that is authorized to issue digital certificates that can be used for the Mutual Transport Layer Security (mTLS) security protocol. You may upload Trusted CA certificates and intermediate certificates.
Let’s Encrypt certificateSection titled Let’s Encrypt certificate
Let’s Encrypt™ is a nonprofit global CA that allows people and organizations to obtain, renew, and manage TLS certificates for free. When creating a Domain with Azion, you may choose to obtain a TLS certificate signed by Let’s Encrypt. You can request Let’s Encrypt certificates for domains hosted in Intelligent DNS or in a third-party DNS provider.
Once you create a domain with Azion, you can choose the option Let’s Encrypt to automatically generate a Let’s Encrypt certificate. An entry for this certificate will be listed in the Digital Certificates page in Real-Time Manager. After the certificate undergoes DNS validation, issuance, and storage, it’ll become active.
See How to generate a Let’s Encrypt for your domain to know how to validate this type of certificate.
Active Let’s Encrypt certificates will be renewed automatically before the expiration date of 90 days, provided that you don’t bind a custom certificate to the domain or delete the associated domain. Certificates that were unbound from a domain can be rebound if they remain valid.
CNAME configurationSection titled CNAME configuration
When you create a domain with Azion Domains and select the Let’s Encrypt certificate option, you can list the CNAMEs that’ll be bound to the certificate. CNAMEs listed after a top-level domain are registered as Subject Alternative Names (SAN).
When you modify the CNAME list on the domain settings, Azion will create a new certificate based on the modified set of CNAMEs, and the old entry won’t be renewed by the certificate manager.
StatusSection titled Status
If any of the CNAMEs hosted in external providers fail the DNS-01 challenge, the certificate won’t be generated and will remain with the Pending status.
Wildcard usageSection titled Wildcard usage
You can use wildcard CNAMEs (
*.domain.com) or mix wildcard and non-wildcard CNAMEs in the same Domain. However, when using the wildcard notation, you don’t have to specify subdomains that are already covered by the wildcard. For instance, if you decide that the certificate should be applied to
*.domain.com, you don’t need to include
blog.domain.com in the CNAME list.
The hostname resolution follows Azion’s standard rules: specific domains have precedence over wildcard ones. For example, a Let’s Encrypt certificate for a Domain
blog.domain.com will take precedence over another certificate for the Domain
Certificate Signing RequestSection titled Certificate Signing Request
A Certificate Signing Request (CSR) is one of the first steps towards getting your own TLS certificate. You may submit a CSA to a CA to receive your certificate.
You’ll need to inform:
- CNAME: the main domain for the certificate. Must be in FQDN format; for example:
- Country/region: the country or region of your organization. Must be in ISO 3166 format.
- State/province: the state or province of your organization.
- City/locality: the city or locality of your organization.
- Organization: the name of your organization.
- Organizational unit: the person, department, or unit responsible for the certificate.
- Email: the email of the unit responsible for the certificate.
- Private Key Type: the type of private key desired.
- Subject Alternate Names (SAN): a list of other CNAMEs to be registered as alternate names.
For customers with contracted FIPS 140 support, the private key will be stored in an HSM that uses a cryptographic module certified in the FIPS-140 Level 3 standard.
LimitsSection titled Limits
You can list up to 50 CNAMEs for each domain you create.