This blog post covers
- Why use certificates?
- What is a certificate?
- Information about the owner
- Meta information.
- How do you trust a certificate?
- Intermediate CAs and certificate chains.
- Is the certificate still valid?
- Do I trust the sender?
Why use certificates?
Certificates can be used as an authentication mechanism. It allows identity information to be sent over a network, and the remote end to validate the information before using it. For this to work, we need a “Certificate Authority” who can validate the certificate. When the remote end gets the “certified certificate” it checks the certification and validity and if successful can use this. Checking can involve sending an electronic request to the Certificate Authority asking if the certificate is still valid.
What is a certificate?
A certificate has several components (conceptually I think of a certificate as an envelope with several bits of paper within it).
- A public key. See One minute explanation of public keys and private keys.
- Information about the owner, such as name and address or organization
- Meta information – such as it can be used for document signing (but not certificate signing), and validity dates.
- Signing information.
Information about the owner
A certificate has information about the “owner”. Common attributes include
- Common Name CN=Colin Paice
- Organisation O=My Org
- Organisational Unit OU=TEST
- Country C=GB
Meta information.
The certificate contains information on how it should be used. For example
- This certificate can be used as a server’s certificate – but not as a client certificate.
- This certificate can be used for signature but not encryption.
- This certificate can be used to sign other certificate (see below).
A server (or client) could decide to ignore some of these attributes. A proper server will honour the information, and if the client’s certificate does not have the “can be used by a client” attribute set, it will reject the certificate.
How do you trust a certificate?
If you have been sent a certificate – how do you tell if it is genuine? This was one of the problems in the early days of secure communications.
This problem was solved by having an organisation we both trust, and having this organisation “sign” a certificate.
Imagine there is a UK Certificate Authority (UKCA). To get your certificate approved…
- you take your certificate, your passport, and proof of address to the Certificate Authority (UKCA).
- A clerk in the CA, checks that the name in your certificate matches your passport, and the address in the certificate matches the proof of address your provided.
- The clerk can check “the permissions” within your certificate, such as this certificate can/cannot be used as a certificate authority, or can/cannot be used as a server. The CA may not care!
- The CA take an electronic copy of your certificate and perform a checksum calculation on the contents. If the certificate is changed in any way, the checksum calculation will be a different number.
- The CA then encrypts the checksum calculation, prints it out, and staples the encrypted value and a copy of the CA’s public certificate to the back of your certificate.
- The certificate has now been signed by the CA.
You send me a copy of your certificate and attachement created by the CA.
When I get a copy of your certificate (and attachment),
- I check the CA’s public certificate that you sent me is the same as the copy I already have.
- I do the same check sum calculation as the CA authority did.
- I use the CA’s public certificate to decrypt the CA’s encrypted checksum.
- The two checksum values should match!
If the checksum values match, then I can trust that the information in the certificate is the same as the information you showed to the CA when getting you certificate “signed”. Of course if you provided a fake passport, all I know is that what I see is what the CA saw.
Intermediate CAs and certificate chains
Of course it costs you money to get your certificate signed by a CA. To reduce this cost you can set up your own enterprise Certificate Authority. You create a certificate called CN=MYORGCA, and set the attribute set to allow it to sign other certificates. You take this the the UKCA and get it signed.
When Joe wants his personal certificate signed, he come to you,
- you check Joe’s corporate ID badge has the same name as in Joe’s certificate
- you check any other data fits within your enterprise standards, such as expiry date.
- you use your enterprise CA certificate(CN=MYORGCA) to sign Joe’ certificate.
- Joe get a package with
- Joe’s certificate,
- the checksum from the enterprise signing, and the enterprise public certificate.
- a copy of the UKCA’s certificate and encrypted checksum for your enterprise’s CA.
When I get Joe’s certificate and attachments.
- I can see if I have a copy of your enterprise public certificate.
- No I do not, but I do have a copy of the UKCA public certificate,
- I validate the your enterprise’s public certificate, using the UKCA certificate
- If your enterprises public certificate validates successfully, I can then use it to validate Joe’s certificate.
This means I can validate certificates sent to me, as long as I have at least one of the certificates in the chain.
You could take this further and have a departmental CA authority.
Is the certificate still valid?
If someone leaves your organisation you want to ensure that any certificates issued to that person cannot be used.
You can have an expiry date in the certificate, so within a year or two the certificate will expire. This is not good enough, and you want to make the invalidate the certificate as soon as possible. This can be done through an Online Certificate Status Protocol (OCSP) attribute in the certificate. Basically this says go and ask the URL if this certificate if it is still valid.
How do you know who to ask? A certificate has url information within in it Authority Information Access: OCSP – URI:http://ColinsCert.Checker.com/ . The back end serving the URL is typically an LDAP server.
If you think about this for a few minutes this may not seem a good idea. For every secure connection handshake, you have to issue a query to a remote server somewhere to see if the certificate is still valid. This will seriously affect performance. This was solved by having a “OCSP response valid time”, sent as part of the response from the OCSP server. This known as stapling (I picture this as stapling a valid-until ticket to a certificate). The OCSP server can say “This certificate is valid, and assume it is valid for n hours”. The first time the client uses the certificate it may take longer because of the OCSP checks. For successive requests , the client can then use the certificate without doing any OCSP checks – until the time period has expired.
Do I trust the sender?
A bad actor could have copied the certificate from a valid server, and presented it to the client. The client checks it, and it looks ok, but in reality it came from a bad server.
You can include Subject Alternate Name (or SAN) in the certificate. This is the URL or IP address of the server. When the certificate is sent from the server, the client checks that the IP address of the server is in the list of SANs in the certificate. If it does not match then the certificate is rejected. Example SANs DNS:www.example.com, IP:10.1.1.2
If the DNS:name is used, this will also require a connection to a DNS to get back the IP address, which will add time to TLS hand shake to the server.
You should use SAN for the server, but not for the client. A Server will have a fixed, or limited choice of values. A client can get a random IP address and so is unlikely to match a value in the certificate.