On a hostile network like in an airport or an hotel, how does one make sure that she is indeed connecting to our departmental servers? For SSL/TLS enabled server, all you need to do is install the following certificate and its revocation list.
(Mozilla/Firefox/Thunderbird users please note that although one can import the PEM encoded certificates, for revocation lists one needs to use the DER encoded version. Clearly this is one among the many such "features" of these clients. Thanks to Siddharth Agarwal for point it out to me.)
The link above provide a self signed certificate of our Server Certifying Authority (Server CA). All the SSL/TLS certificates of our servers will be signed using the above self signed certificate. An SSL/TLS capable client --- most browsers, mail clients these days are SSL/TLS aware --- can uses this certificate to verify the authenticity of the server that it is talking to.
Most SSL/TLS capable clients have a way of importing and using CA certificates. We have given the procedure for some of the clients at the url http://www.cse.iitk.ac.in/users/ca/apps/index.html
As far as servers of this department are concerned, at the top of the trust hierarchy is the Server Certifying Authority, Server CA for sort. This CA is managed by the main system administrator and the faculty in-charge of the the departmental Lab. As of now the certificate of this CA is self signed. One cannot really trust a self signed certificate. However, if you have ensured that the certificate has been obtained from a trusted source, you can start using it to verify other server certificates. The two main things to make sure of are the following:
The certificate of the Server CA has been obtained from a trusted source.
Regularly update the revocation list to make sure that compromised keys are not trusted.
One way to check whether the self signed certificate is authentic is to directly verify with the signing authority in person. This is not possible if you are away from the department so we suggest you follow these steps:
Make sure that you are with in the department when you are downloading this certificate.
Obtain its finger print and verify directly with the certifying authority (the person responsible for signing) via phone or by barging into their office and asking them directly. It would be desirable if you can confirm the fingerprint through more than one source.
A fingerprint is a small string that uniquely identifies the certificate. To get the finger print of a certificate you can use the following openssl command.
$ openssl x509 -fingerprint -noout -in certificate.crt
$ openssl x509 -md5 -fingerprint -noout -in certificate.crt
# md5 finger print
$ openssl x509 -sha1 -fingerprint -noout -in certificate.crt
# sha1 finger print
For other details one can type the following commands.
$ openssl x509 -text -noout -in certificate.crt
When importing certificates in applications like firefox, the application itself displays these information and ask you for confirmation. Instead of just clicking on the OK button, choose to examine the certificate and verify the details with the CA in person.
If you have ensured that the self signed certificate of the Server CA is authentic, then you do not need to verify/trust the authenticity of each and every server certificate of our department as those are signed by the Server CA and your application will verify those signatures using a copy of the Server CA certificate that is available to it.
If a certified private key falls into wrong hands, we will be revoking such a certificates before their expiry (provided we realise it). Although this event might be rare, you would like to keep and eye on the revocation list. To view the details you can use the following commands.
$ openssl crl -in current.crl -text -noout | less
It is a good habit to import these revocation lists regularly into your browsers, email clients etc so that they do not trust a revoked key.
These certification services are meant to be used by the members of the department to trust secure services like imaps, secure smtp etc. Hence it is provided WITHOUT ANY WARRANTIES either direct or implied. Although every effort has been made to keep the certification procedure secure, as well as transparent, the department DOES NOT GUARANTEE that the certificates are not compromised. We therefore assume no responsibility for any consequence, either direct or indirect, that might be caused due to inadvertently trusting these certificates. In particular, if you find any server not belonging to this department with a key certified by this CA, please do not trust it and report the matter to us for corrective action.
Last modified on 13 April, 2010 (Tuesday)