Certificate Lifecycle

From OpenSSLWiki
Revision as of 19:27, 24 May 2013 by Philippe lhardy (talk | contribs) (Cert if i cat e.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

X509 Certificates are convenient normalized way to use Public/Private schemes to prove identity of a software component or -by delegation- of a person.

Certificates are used in ANY https:// connection to ensure url of server you see connects to a server that is the one you expect. They are used in client authentication too for a Service to indicate what user you are. They are used in Software components to sign Code and prove that code was created by a trusted entity. They might be used to cipher mails or files. They are used in various secure protocols to provide authentication of parties ( LDAPS... ).

Certificates have a life like many other objects.

- Before giving birth to a certificate you need to create its DNA... which is Public / Private Key Pair.

- Once this DNA is created you need some Authority to certify this is THIS certificate ADN

By giving a proof you own DNA Private part of the public DNA part to Authority by providing a 'Certificate Request' Authority will decide to create a Certificate for you.

This Certificate will contain Public Key part and many other informations that describe Certificate ownership, purpose, and time to live and the most important part : he contains the proof from Authority that the Authority reviewed those informations and certify them. That's actualy why a Certificate is a certificate.

"All Certificates are equals but some are more than others !" Certificate are unequals since they can be from a well known family (Well known Authorities) or from more confidential ones (Dedicated ones). A Certificate has only the value of Trust that its Authority has. If the Authority is untrusted, so the certificate is. => Issuer , Certificate Authority

"Certificates can buy their graves early." Yes a Certificate from its early birth knows exactly when he will die. It is perhaps sad, but nobody told that life of certificate should be a piece of cake. And worse a Certificate can be revoked when it was compromised, then it can even die before his deadline. => Validity

"Ausweiss please" By detaining the private key of a certificate you can prove you own the certificate and then that information written on that Certificate applies to you. Distinguished Name is the name of the owner of private key. => DN

"A Certificate without private Key is just like glasses without eyes" A Certificate does not contains Private Key, if you have a Certificate and you can find your private key, then it is just like if you have nothing. Opposite is not true, since With private key you often have public key, and you can request a new certificate, but you will need to regenerate a new Certificate, and due to the public nature of a Certificate you can often find it copied somewhere, from your Authority by example.

"Copy me if you want !" A Certificate can be copied and distributed, it is fully public. Certificates don't contains Private Keys so they are usefull only to prove identity of parties who owns the private key. WARNING : wording "Client Certificates" might be misleading here, since in this specific case a "Client Certifcate" is more than a certificate, it is a file that contains the private key too.

"Certificates are NOT free" Obtaining a Certificate from a well known Certificate Authority requires that you pay a fee.

And a Certificate knows from his creation what job he will do, there is no way a Certificate issued for Authenticating a Server can be used in browser to identify a user. Certificates have a purpose.