Certificate Lifecycle
X509 Certificates are a convenient and standardised way to use PKI (Public Key Infrastructure) schemes to prove the identity of a software component or (by proxy) a person.
Some examples of where certificates are used include:
- in ANY HTTPS connection to ensure that the server you connect to is actually operated by the person or organisation that owns the domain;
- in HTTPS client authentication for a server to identify of a user;
- in software components to sign code and prove that code was created by a trusted entity;
- to digitally sign e-mails or files;
- in various secure protocols to provide authentication of parties (e.g LDAPS).
Certificates have a life like many other objects.
- Before giving birth to a certificate you need to create its DNA... a public/private key pair.
- Once this DNA is created you need some Certificate Authority to certify that you are the owner of this DNA.
By providing proof of identify; proof of ownership that you own the private DNA part; and the public DNA part contained in a 'Certificate Signing Request', a Certificate Authority will create a certificate for you.
This certificate will contain the public key and other information that describe the certificate ownership, purpose, and time to live. It also contains the most important part: proof that the Certificate Authority reviewed that information and certified it.
"All certificates are equal but some are more equal than others!" Certificates are unequal since they can be from a well known family (well known Certificate Authorities) or from private ones. A certificate only has the value of trust that its Certificate Authority has. If the Certificate Authority is untrusted, so is the certificate. The Issuer field of a certificate identifies the Certificate Authority
"Certificates can go to their graves early." A certificate from its birth knows exactly when it will die. A certificate can be revoked before this deadline if it is compromised. The Validity field of a certificate identifies the start and expiry date of a certificate.
"ID please" Through the private key you can prove you own the certificate and therefore that the information written on that certificate applies to you. The Subject field of a certificate is the name of the owner of a private key.
"A Certificate without a private key is like glasses without eyes" A certificate does not contain the private key. If you have a certificate and you lose your private key, then the certificate is unusable to prove your current identity. A certificate without a private key can still be used to verify existing signed data (or code signing), but no new data can be issued with it.
"Copy me if you want!" A certificate can be copied and distributed, it is fully public. Certificates do not contain private keys so they are useful only to prove the identity of the party that owns the private key.
"Certificates are NOT necessarily free" Obtaining a certificate from a well known Certificate Authority typically requires that you pay a fee.
A certificate knows from its creation what job it will do. There is no way a certificate issued for authenticating a server can be used in a browser to identify a user. Certificates have a purpose.