Webcertificates

Certificate basics

Most webapplications are nowadays secured using public key-cryptography. For example HTTPS and IMAPS (or IMAP with TLS) are typically secured.

Technically, the following actions happen after a client connects to a server:

1. The client requests secure communication.
2. The server identifies itself using a certificate, trusted by the client.
3. The server and client establish a shared secret.
4. The communication is encrypted using the established secret.

The second step is important.

• The server presents it's public certificate to the client, signed by trusted parties.
• The server proves that it really is the owner of this public certificate, by encrypting some challenge that the client send, using the server private key.

The 'signed by trusted parties' is crucial for actual security, because it establishes trust.

There are generally three ways to create trust:

Prior trust

Basically, you check if the certificate is the same as last time. SSH uses this trust model. Extra attention should be paid when the server is connected for the first time (typically, the certificate's fingerprint is communicate by different means).

Hierarchical trust

There is an trusted authority that vouches for the trustworthiness of the server, and it's certificate. HTTPS, IMAPS (or IMAP over TLS), and S/Mime Mail all use X509 certificates, which uses this trust model. DNS also uses a hierarchical trust model, albeit not with X509 certificates.

Web-of-trust

You trust someone because many other people have vouched that this is indeed the person he claims to be. This trust model is used with PGP mail.

Certificate Hierarchy

Hierarchical Trust Model

Services like HTTPS and IMAPS use X509 certificates, which uses a hierarchical trust model.

For example, the trust hierarchy for the certificate used by the SURFsara website is:

DigiCert High Assurance EV Root CA

Terena SSL High Assurance CA 3

SURFsara, surfsara.nl

Here, DigiCert is the root certification authority (CA). DigiCert has declared that Terena is really who the claim they are, by signing its certificate. Terena has declared that SURFsara is really SURFsara, by signing its certificate. Such a list of trust represents a chain of trust.

Technically, a chain of trust consists of three certificates. Each certificate has a "subject" and a "issuer" value. The subject describes who the certificate belongs to, and the issuer describes who issued the certificate.

 Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert High Assurance EV Root CA
 Subject: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert High Assurance EV Root CA

 Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert High Assurance EV Root CA
 Subject: C=NL, ST=Noord-Holland, L=Amsterdam, O=TERENA, CN=TERENA SSL High Assurance CA 3

 Issuer: C=NL, ST=Noord-Holland, L=Amsterdam, O=TERENA, CN=TERENA SSL High Assurance CA 3
 Subject: C=NL, ST=Noord-Holland, L=Amsterdam, O=SURFsara B.V., OU=IA, CN=www1.osd.surfsara.nl

The root of the chain is a self-signed certificate, which is also referred to as a root certificate or X509 anchor certificates. Self-signed means that the subject and the issuer have the same value.

Full Chain of Trust

Further up the chain, webbrowsers (or operating systems) come with a set of build-in root certificates of certification authorities. DigiCert is one of them. So the webbrowser tells the user to trust Digicert. So the full chain of trust is:

Person browsing the web (you)

Webbrowser

DigiCert High Assurance EV Root CA

Terena SSL High Assurance CA 3

SURFsara, surfsara.nl

Self-Signed Certificates

It is also possible to create a self-signed certificate yourself, and present that to a user. E.g. "SURFsara declares that I'm really SURFsara". While this used to be popular (and perhaps has a liberal touch, that entices some old-school Internet hippies, like myself), it is no longer considered secure at all.

A notable exception is when you use OpenVPN, in which case you must use self-signed certificate.

Using DNS as trust hierarchy

Unfortunately, in the 2010-2015 period, getting a signed certificate was expensive, about $50 per domain per year. (while registering a domain only cost about $10 per domain per year).

Nowadays, there is a technology push to use the DNS hierarchy for certification. This is mode possible with the avant of DNSSEC (adding cryptograph signed records to DNS). DANE is the technology to push this to webapplications.

Another project to push out cheap and easy certificates is https://letsencrypt.org/, a free certification authority.

LDAP parameters

X509 uses LDAP parameters:

C

country

ST

State or Province

L

Locality

O

Organization

OU

Organisational Unit

emailAddress

Email Address

CN

Common Name, typically the hostname

DN

Distinguished Name, name uniquely defining an object, composed of the local name (relative distinguished name) and the location in the LDAP hierarchy

DC

Domain Context, a label of a domain name (e.g. DC=example, DC=org)

SN

Surname

LDAP typically uses one of these schemas to define a root:

• dc=example, dc=org
• o="Example Inc.",c=NL
• o=example.org

See also: http://www.ldapman.org/articles/intro_to_ldap.html

The DN for a HTTPS (web server) certificate often looks like:

O="Example Inc",c=NL,CN="www.example.org"

The DN for a IMAPS (mail server) certificate may still contain an email address:

O="Example Inc",c=NL,CN="www.example.org", emailAddress="hostmaster@example.org"

However, the recommendation is to store an email address in the subjectAltName, no longer in the DN.

Further Reading

• Getting a X509 Certificate
• Install CA Certificates