Wildcard SSL Standard certificate, issued by Gandi
This type of certificate costs around €120/year.
It enables you to protect all the sub-domains (top-level) of a main domain name with a single certificate.
It is issued automatically and fairly quickly (less than 1 hour).
You can also opt for a Pro SSL certificate (wildcard or not).
It's more expensive, requires verification of documents, but gives you a financial guarantee.
The procedure described here concerns Standard SSL Certificates, but works with Pro SSL Certificates.
¶ Certificate Order
To verify the authenticity of certificates, customers rely on a set of root certificates.
All certificates are signed from these root certificates or from certificates descending from these root certificates:
intermediate ceritificates.
The latter are generally used to sign our final certificates.
If you have imported your certificate in zip or pfx format, it may be imported in a disorganized manner.
This is because Artica cannot tell which certificate has been generated for your site, and which certificate has been generated by the supplier.
In our example, the certificate field contains the Gandi certificate instead of the certificate generated for your site (it's in the Bundle section).
In many cases, this works on the reverse-proxy, but if you want the SSL flow to be compatible for all, you need to reorganize the certificates as follows:
- the Root (0)
AddTrust External Rootinside the “Certificate section”
Inside the Certificate Chain in this order:
- branch (1)
USERTrust RSA AddTrust CA - branch (2)
Gandi Standard SSL CA2 - leaf (3)
*.example.com( Your generated certificate )
¶ Stapled certificate file (stapling)
Most clients connecting to the web server will want to check that the certificate has not been revoked.
There are two ways of doing this: via a CRL (Certificate Revocation List) file, but given the number of certificates in circulation this is impractical, or via an OCSP (Online Certificate Status Protocol) query.
To save the client having to make an additional request, the server can cache the result of this verification and serve it directly to the client.
To do this, The reverse-proxy needs to be provided with a list of certificates.
The certificates must be in hierarchical order, starting with the one that signed your certificate (in this case GandiStandardSSLCA2) and working up to the root.
On the Certificate center, click on “Provider's CA Bundle” link
Copy the content, which will contain, in order :
- Gandi's intermediate certificate (branch 2) ;
- the cross-signed certificate (branch 1);
- the root certificate (root 0).
¶ Activate the Stapling OCSP
On the reverse-proxy section, go to your Web sites rules and select the SSL parameters.
Activate the OSCP Stapling and Verifies the obtained OSCP response option
- The OCSP Stapling option, Aka Online Certificate Status Protocol improves the performance of SSL/TLS certificate verification by enabling the server to provide a pre-validated OCSP response to the client, thus avoiding the need for the client to query the certification authority (CA) directly.
- The Verifies the obtained OCSP response Tells the reverse-proxy to verify the OCSP response that it staples to the SSL/TLS handshake.
This verification ensures that the OCSP response is valid and trustworthy, providing an additional layer of security