I would like to know after approving the Certificate signing request, does the Certificate Authority send the Digital certificate to the applicant by converting the digital certificate to PEM format and sending it as a .crt file via email or does it send the digital certificate in some other way?


There is a standard for exchanging messages with CA, but it is rarely implemented in practice. Existing commercial CA that deal with many remote customers tend to organize the certificate issuance process through some custom interface (often Web-based) and the certificate-sending is part of that process. Various methods are used in practice, possibly combined:

  • Sending the certificate over email.
  • Make the certificate available to the user over HTTP (the URL being displayed in some Web page, or even sent by email).
  • A custom protocol between the CA and a CA-controlled component that runs on the user machine (Applet, ActiveX control, full-blown "management console" application...).
  • Any "manual transfer" protocol in some specific situations (e.g. when an offline root CA issues a certificate for an intermediate CA, the transfer must involve something like a USB key, since the root CA is offline).

The certificate itself is commonly encoded "as is" (X.509 DER, or PEM), or wrapped into a so-called PKCS#7 (CMS) object. CMS was never meant to convey certificates (it is an encryption and signature format) but it is traditional to use it to send a certificate and a set of "helper certificates" (intermediate CA for its validation).

Some CA generate the private key themselves (on the CA side), and, in that case, the private key must be sent to the requester; usually, a PKCS#12 (aka PFX) archive is used to contain both the certificate and the private key, with password protection (password-based encryption).

Since a certificate is signed and contains only public data, its integrity is readily verified upon reception, and it how it travels is unimportant for security. This is the main good thing about certificates.

  • "Some CA generate the private key themselves" - this should be avoided as of course negates the notion of private key. Even if say say so you cannot be sure that they don't keep it or forward it to NSA right away Jul 10 '15 at 17:27
  • 1
    CA-side private key generation makes sense for organization-specific CA, for encryption keys: encryption keys must be backupped (to avoid data loss when an employee becomes unavailable or when his machine crashes) and doing the key generation on the CA allows for a centralized unavoidable backup process. Jul 10 '15 at 17:29

Since certificates are tamper-proof by design, and only contain public information, they do not need to be delivered in a secure way. As you say, a PEM encoded certificate is just a file, so you can send it the same way you send any other file. Emailing it as an attachment would work, and I'm sure some CAs offer that as a delivery method.

Here we mainly use the Entrust CA, so that's the one I have the most experience with; with them you create an account on their site which gives you access to their shopping cart to order certs / upload CSRs. When the cert is ready they send you an email letting you know that you can log in again and pick it up (right-click "Save As" from the list of certs you've ordered).


CA is about evaluating data in the CRT and signing it, resulting in X.509 certificate of public key. Communication is not the major point. It could be email, http, directory (ldap) or whatever client would pick his certificate with. Format is not the point as well; binary DER-encoded and PEM are common solutions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy