I\'m quite new to this, so don\'t be too hard on me. I\'m currently using the Ci
ID: 661563 • Letter: I
Question
I'm quite new to this, so don't be too hard on me.
I'm currently using the CipherMail MTA to generate e-mail encryption certificates. I created an own CA and public and private keys for our contact mail adress.
I want to post the public key and the certificate on our website so that clients may encrypt mails toward us, but have difficulties understanding how it would be verified by our clients, seeing that the issuer of the certificate is our own CA. Should I post the Certification Authority as well? Is it safe to do so?
If I do so, then each client that wants to send us encrypted mails would have to install the CA in their e-mail client and then install the certificate. Is there an easier way?
Explanation / Answer
Public keys are meant to be public. The whole idea of public key infrastructures is that knowledge of the root CA public key is sufficient: once you know (with some certainty) that public key, then you can obtain some guarantee over the ownership of public keys by users by validating the certificates.
There is no problem for you in putting the CA certificate itself on a public Web site. This is considered good. In fact, certificates issued by a CA should contain a URL pointing to the CA certificate (this is the Authority Information Access extension).
The puzzle is on the side of the clients. PKI does not create trust ex nihilo; it transports it. The clients may obtain your CA certificate (presumably self-signed) but they somehow have to trust that they got the right one. The usual procedure is that the thumbprint (really, a hash) of the certificate is obtained through some unspecified but "secure" method (e.g. the clients phone your sysadmin, and he spells out the forty hexadecimal characters), and the clients verify that the thumprint they got matches that which they compute with the CA certificate they obtained.
Another problem, which is actually harder, is that most emailing software offer no way to restrict trust in root CA to, say, a specific subdomain. One of the client would like to configure his machine so that your CA certificate will be trusted, but only for verifying email certificates linked to emails in the @example.com domain. In other words, lack of segmentation options on the client side will mean that by importing your CA certificate, they will actually trust your CA for many things. They may refuse to do that.