You probably all know about the "https" prefix on a website, right? And it's somehow obvious to you that it represents secured and encrypted communication between your browser and the website that you are visiting. Well, in order to form a secure connection, your computer and the website that you are visiting establish a TLS connection. TLS has been a standard security mechanism over the Internet for many years now. It has replaced SSL, which has existed for many decades, but is hardly used anymore due to weaknesses found in the algorithm over the past years.
You are also mostly confident that the website that you are visiting is actually the company's real website.
When you visit the website of your bank, thanks to the "https" prefix "in green" in your browser, you are confident that it's the real website, and not a fake one from a hacker...
The bank's server is configured to send a "certificate" to your computer during the TLS connection establishment. This certificate represents the bank's "digital identity". In addition to the connection being secured, you are now also confident about the identity of the company running the website...
Even though you use it everyday, managing X509 certificates and related key pairs, and validating certificates is not always trivial... How can we make it a bit clearer ?
Key pairs
A key pair is the beginning of the story. It is composed of two parts: a public key and a private key. It’s always possible to extract the public key from the private key, but not reverse. Thankfully. 😁
Key pairs can use different algorithm, including RSA & EC (Elliptic Curve). We’ll focus on good old RSA in this article.
We’ll start by generating an RSA key pair with 2048 bits key size, using OpenSSL command line.
Less than 2048 is not sufficiently secured nowadays (it's too easy to crack).
Longer keys (eg: 4096) are possible too, but the most common key size on the "standard" Internet is 2048.
A private key is extremely sensitive. Therefore, we’ll use the openssl option "-aes256" so that the generated private key will be encrypted with a password referred to as a “passphrase”.
You should store this private key somewhere very secure, and never share it with anyone.
The best option is putting this private key in a vault, or HSM (Hardware Security Module).
If you think that your private key was compromised, you should immediately replace it, and make sure that the systems who know about it, immediately revoke the corresponding certificate(s).
Let's start with a key pair generation:
openssl genrsa -aes256 -out private_key.pem 2048
You can always remove the passphrase from the private key (you'll be requested to provide the passphrase to decode the key):
openssl rsa -in private_key.pem -out private_key_without_pass.pem
You can also (re)add a passphrase (you'll be requested to provide a new passphrase to encode the key):
openssl rsa -aes256 -in private_key.pem -out private_key_with_pass.pem
Public keys
You can now extract the public part using:
openssl rsa -pubout -in private_key.pem -out public_key.pem
Public keys are not that much used as such, but most of the time included in a X509 Certificate. Let’s see why.
Public keys & X509 certificates
Key pairs are used to secure communication between two applications. If the public keys are manually exchanged, each application will trust the public key of the other and the communication will be secure. But we don’t want to manually setup & maintain all those keys, right?
Here comes X509 Certificates.
X509 certificates
An X509 Certificate includes a public key but also many other attributes. For example, an X509 certificate has validity dates (not before, not after), includes an application/website name (Common Name), the related organisation to which it belongs, the organisation's country, a contact person etc.
The X509 certificate contains the public key and attributes in a kind of envelop. This envelope will be issued (signed) by a Certificate Authority. A Certificate Authority signs X509 Certificates requests on-demand. It is maintained by a company in that business, so it's usually not free 😅. Those companies are trusted worldwide. Examples of well-known Certificate Authorities include VeriSign, GlobalSign, DigiCert, Let's Encrypt etc.
It's also possible to have your own Certificate Authority and issue/sign certificates, as long as the client is able to trust it. This would be a manual operation. There is no way to make a client trust your CA automatically... of course 😉
The security of the certificates makes it impossible to modify the content without altering the signature. Therefore, any modification would make the certificate invalid.
Certificate Signing Request
If you want to request an X509 certificate signed by a Certificate Authority, you will need a Certificate Signing Request.
Here's how to generate it:
openssl req -new -key private_key.pem -out certificate.csr -sha256
The resulting file should be sent to the Certificate Authority for signature. In return, they will provide your X509 Certificate, signed and valid for one or more years.
Computer based trust
Why does my browser automatically trust the issuer of the certificate?
Your computer Operating System comes with a pre-defined/pre-installed list of Trusted issuers, so that when you navigate to a website with a certificate issued by (eg) VeriSign, your browser will automatically trust this source. This doesn't mean that the website is safe, but that communication with the website is secure.
If your browser uses the Operating System trust list, it usually works the same when you run your own application.
An example using curl can tell you if the communication is not secured
curl https://www.mywebsite.com
curl: (60) SSL: certificate subject name 'www.fake-website.com' does not match target host name 'www.mywebsite.com'
More details here: https://curl.haxx.se/docs/sslcerts.html
There still could be breaches in the system though. Eg: an attacker could inject an alternate issuer certificate in your system via a trojan or virus, and your computer would trust this source, like a valid one.
More on the legal part, there's also a possibility that your company installs its own issuing certificate in your system, so that you can navigate the internet via a company outgoing proxy, and this proxy would be able to decrypt & analyse the traffic. This is usually for company network security reasons, including detection of viruses.
Formats and information about X509 certificates
You may receive a binary (DER) or text format (PEM) for a certificate. It's always possible to convert one to the other using -inform & -outform OpenSSL options:
Convert certificate between DER and PEM formats:
openssl x509 -in certificate.pem -inform pem -outform der -out certificate.der
openssl x509 -in certificate.der -inform der -outform pem -out certificate.pem
As explained earlier, the certificate contains a lot of information. OpenSSL command line makes it possible to extract/display that information:
Full content:
openssl x509 -in certificate.pem -noout -text
Certicate subject (Distinghished Name):
openssl x509 -in certificate.pem -noout -subject
Issuer (who created it):
openssl x509 -in certificate.pem -noout -issuer
Not familiar with command line or OpenSSL? You can always use UI tool like https://keystore-explorer.org/
Now that you know the basics, we'll see how we can go further with X509 certificates ... in our next article 😎
