How to monitor and manage SSL certificates (x.509)
Every webmaster probably knows the problem: the amount of SSL certificates that need to be managed that keeps growing. This can be an annoying and thankless job because the SSL / TLS (X.509) certificates have an expiration date. We all know what happens after the expiration date: visitors are only shown an irritating security warning.
Not only do you have to think about the extensions, but the SSL certificate management includes a lot more that needs to be considered. And that is the challenge i-Vertix Monitoring can help you with.
Things you should always keep an eye on
- Do you have an overview of all expiration dates ?
- Is the certificate still valid or has it been revoked ?
- Are the certificates correctly configured on the web server?
- Did the certification authority issue the certificate ?
- Is the certificate chain complete or broken ?
- Has the mail server (pop3, smtp, imap) also configured a valid certificate ?
- What about the FTP server certificate ?
What is an x.509 certificate?
An X.509 is a standard for a public key infrastructure. An SSL / TLS X.509 certificate is a digital file that can be used for SSL or TLS. It is used to authenticate and verify the identity of a host or a website or to encrypt information that are exchanged via website.
X.509 certificates contain a public key and information about the identity of a host. Some of these certificates are self-signed. When a certificate is signed by a CA or verified by another entity, its owner can use the public key to establish secure connections to another party or to validate documents that have been digitally signed with the corresponding private key.
An x.509 certificate contains:
- Version Number
- Serial Number
- Validity (not Before – Not After)
- Signature Algorithm (SHA 256 with RSA Encryption
- Issuer Name + Attributes
- Subject Name + Attributes
- Issuer Signature
- Subject’s Public Key
Browser communication and SSL handshake
- The communication flow of the HTTPS connection starts with the browser’s request for a secure page.
- The web server responds with its public key and certificate.
- Then the browser checks whether this digital file was issued by a trusted entity or CA.
- Using the web server’s public key, the browser encrypts a random symmetric session key and sends it to the server with an encrypted URL and other encrypted HTTP data.
- If the public key is valid, the web server uses its private key to decrypt the symmetric session key, URL, and HTTP data.
- From now on, everything is encrypted with the symmetric key.
- Then the web server transmits the requested HTML document and HTTP data.
- In return, this symmetric key allows the browser to decrypt the HTTP data and display it to the user.
The chain of trust relates to your TLS / SSL certificate and how it is chained to a trusted certificate authority. For a TLS certificate to be trustworthy, it must be traceable back to the root of trust that signed it. This means, all certificates in the chain – server certificate, intermediate certificate (s) and root certificate – must be trusted.
The chain of trust consists of three parts:
- Root – CA: digital certificate saved in Trust Store. The root certificates are strictly monitored by the CAs
- Intermediate CA: Mediator between the protected root certificates and the publicly issued server certificates. There will always be at least one intermediate certificate in a chain, but there can also be several
- Server CA: The server certificate is the certificate that is issued to the specific domain
i-Vertix SSL validity check
If you are asking yourself how can i-Vertix help you with all this, here’s the answer: i-Vertix provides you with all the commands and templates out of the box to simplify these complex issues.
Check certificates and files:
- PEM / DER
- The Issuer Name is the expected
- The Subject Name is the expected
- The alternative subject names are the expected
- The certificate expires in X days and sends a push alert to the webmaster as a reminder.