SSL certificate: why you need one, how to check it and avoid HTTPS errors

We start from the public address: compare the expiry, the domain names and the chain of trust, then test that renewal works. In one project an intermediate certificate was missing after a manual install. In another, a change to network rules stopped a new certificate being issued.

What is an SSL certificate, and why does a website need one?

A certificate lets a client check the server’s name and set up a protected connection. A certificate authority signs it; the client checks the signature, the validity dates and whether the name matches the address it is connecting to.

The name “SSL certificate” survives in interfaces and everyday speech, although today’s HTTPS connections run on TLS, the successor to SSL. TLS protects data in transit between client and server: it encrypts the data, lets each side detect tampering and lets each prove who it is. That matters for sign-in, for sending contact details and for every other action on the site.

Domain validation and organisation validation are different levels of assurance. A domain-validated (DV) certificate shows control of the name; OV and EV certificates add checks on the organisation, and the encryption is the same at every level. Separately, you choose the coverage: one domain, several names in the SAN list, or all suitable subdomains with a wildcard. The level of vetting and the list of protected names solve different problems.

A trusted certificate does not vouch for the seller’s honesty, for the absence of vulnerabilities or for a lead reaching your team. A browser can set up a protected connection while the form handler behind it returns an error. So check HTTPS as a stage of the site’s work in its own right.

How do you check an SSL certificate: expiry, domain name and chain of trust?

Check the certificate on the address your visitors actually use. The file in a hosting panel and the certificate a public server really presents can differ. Start from the outside connection, then move to the configuration.

1. Open the exact HTTPS address

   If the site answers on several names that matter, check each of them: the main domain, www, the sign-in page, a separate subdomain for the app. A redirect does not cancel the check of the first HTTPS address, because the connection is made before any HTTP redirect arrives.

2. Read the dates

   Look at Not Before and Not After. The real validity is in the version the server presents, which a browser shows in its site information panel. From a terminal, one openssl line prints the subject, the issuer and both dates as notBefore and notAfter. If you see an unexpected date error, check the device’s clock too.

   TerminalCopy

   echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates

3. Match the names to the address

   A certificate for another domain does not fit just because it is valid. When one IP address serves several sites, the server has to pick the certificate for the requested name using SNI, the name the client sends while the connection is being set up. Nginx explains why: the secure connection is made before the browser sends an HTTP request, so without SNI the server does not know which name was asked for.

4. Check the chain

   A site’s certificate normally links to a trusted root through an intermediate certificate. The server has to send the intermediates it needs; the client takes the trusted root from its own store. openssl s_client with -showcerts lists every certificate the server sends, and a missing intermediate typically ends in unable to verify the first certificate.

5. Keep the result of an outside test

   The SSL Labs Server Test shows the chain, details of the TLS configuration and compatibility. Open the specific warnings in the report and match them to the client that fails.

If the site is served through a CDN or a load balancer, check which node ends the visitor’s TLS connection. Replacing the certificate on the application server may change nothing about the certificate the public address shows. Choose the next checks by the real connection path of your project.

SSL certificate errors: which check matches which symptom?

A browser warning helps you pick a check but does not establish the cause. Check the expiry, the name and the trust separately, so that you fix one specific part of the configuration without giving up the check of the secure connection.

A trust error and an insecure HTTP address are different situations. Turning off certificate checks in a client hides the problem and removes the proof that you are talking to the right server. Keep the full error text and the result of the chain check: they are more useful for the fix.

Case: the site opened on a desktop, but some clients lost the connection

cat domain.crt intermediate.crt > fullchain.crt

ssl_certificate     /etc/nginx/ssl/fullchain.crt;
ssl_certificate_key /etc/nginx/ssl/domain.key;

The incomplete-chain report tied the clients’ failures to the file Nginx served. So after replacing a certificate we recommend reading the chain from outside and repeating the request from the client that failed. The check then ends on the connection that used to fail.

Case: auto-renewal failed after port 80 was closed

The choice depends on your infrastructure. For HTTP-01, check from outside that the challenge path is reachable, and check the network rules. For DNS-01, set up the automatic creation of the TXT record under _acme-challenge for your domain. It only makes sense for automated renewal if your DNS provider has an API, but unlike HTTP-01 it can also issue wildcard certificates. Publishing a record by hand is fine for a single issue; the next one has to run by a configured process. After the setup, run a renewal test.

What should you check after issuing or renewing a certificate?

After issuing, check the certificate the client receives and repeat the actions that matter on the site. A successful Certbot job and a new certificate actually being served are two different checks.

Compare the new expiry on the public domain, the completeness of the chain and the name. Make sure the web server’s configuration has been tested and loaded. If several nodes end TLS, the check has to match that setup: one local file may not be enough.

To test the renewal process itself, Certbot has a dry run:

certbot renew --dry-run

It is a test run against Let’s Encrypt’s staging server, and the test certificates it obtains are not saved, so it checks the configured process without a real issue. Then watch the results of the actual renewals, not only the presence of a schedule. A change to a firewall, to DNS, a site move or a configuration change can affect the next one.

Once HTTPS is back, open an important page and check the form, the sign-in or the payment: the action the visitor came for. A certificate can be valid while another stage of the site has stopped working.

Set up issuing and renewal in your own infrastructure, and watch what visitors receive from outside. Add the site to SENRIKO and its SSL check looks at the certificate on the public address: it warns before the expiry and flags an expired certificate, a name that does not match the site, an incomplete chain and a change of issuer. When something fails you have observations to work from; how often it checks depends on your plan.

Frequently asked questions about SSL certificates