Digital certificates are electronic credentials that are used to certify the online identities of individuals, organizations, and computers. Certificates are issued and certified by CAs(Certification Authorities).
Digital certificates are issued by CAs to provide proof for verifying the identity of online entities. However, instead of containing a photograph and the signature of the certificate\’s owner, a certificate binds the owner\’s public key to the owner\’s private key.
These certificates are issued for limited period after that they were replaced with new public/private key pair to insure security.
A CA uses its private key to digitally sign each certificate it issues. To create the digital signature, the CA generates a message digest from the certificate, encrypts the digest with its private key, and includes the digital signature as part of the certificate. Anyone can use the message digest function and the CA\’s public key to verify the certificate\’s integrity. If a certificate becomes corrupted or someone tampers with it, the message digest for the altered certificate does not match the digest in the CA\’s digital signature.
Now days digital certificates are distributed PKIX-compliant public key infrastructures support industry standard X.509 version 3 certificates and file extension is .cer .
Standard X.509 certificate format
Certificate Field |
Description |
Version |
Version of the certificate format; for example, version 3. |
Certificate Serial Number |
The unique serial number that is assigned by the issuing CA. The CA maintains an audit history for each certificate so that certificates can be traced by their serial numbers. Revoked certificates also can be traced by their serial numbers. |
Certificate Algorithm Identifier |
The public key cryptography and message digest algorithms that are used by the issuing CA to digitally sign the certificate. |
Issuer |
The name of the issuing CA. The name can be listed in one or more of the following formats: X.500 directory name, Internet e-mail address, fully qualified domain name (FQDN), X.400 e-mail address, and URL. |
Validity Period |
The certificate\’s start and expiration dates. These define the interval during which the certificate is valid, although the certificate can be revoked before the designated expiration date. |
Subject |
The name of the subject (owner) of the certificate. The name can be listed in one or more of the following formats: X.500 directory name, Internet e-mail address, fully qualified domain name (FQDN), X.400 e-mail address, and URL. |
Subject Public-Key Information |
The public key and a list of the public key cryptography algorithms. The algorithms are for the tasks for which the public key set can be used, such as digital signing, secret key encryption, and authentication. |
Issuer Unique Identifier |
Optional information for uniquely identifying the issuer, when necessary. |
Subject Unique Identifier |
Optional information for uniquely identifying the subject, when necessary. |
Extensions |
Additional information that can be specified for optional use by public key infrastructures. Common extensions include a list of specific uses for certificates (for example, S/MIME secure mail or IPSec authentication), CA trust relationship and hierarchy information, a list of publication points for revocation lists, and a list of additional attributes for the issuer and subject. |
Certification Authority\’s Digital Signature |
The CA\’s digital signature |
So where is private key?
Private key is always with owner of digital certificate. It is stored on some detachable storage or on computer’s hard disk in a secured location. On windows it is stored under users profile which is encrypted by windows it self. If user’s profile is roaming in nature then certificates are stored on domain controller and they are downloaded on every logon of user and deleted after logoff.
If you are generating certificate using some tool then certificate private key is stored on secured key store. Obviously you can export your private key with certificate using windows certmgr.exe into PKCS #12 files which extension is “.p12
” or “.pfx
” in these exported files private keys are encrypted with a password which ware asked from exporter at the time of export. When you will import this certificate on other computer then import toll with varify your password.
These files can be created, parsed and read out with the OpenSSL pkcs12
command.
PKCS #12 is the successor to Microsoft\’s “PFX”, however, the terms “PKCS #12 file” and “PFX file” are sometimes used interchangeably.
If some CA is issuing certificate with private key then you will receive PKCS12 file which has private key also so never share this file to any unauthorised party. Private key issued by CAs are encrypted with CAs private key. If you have generated your own key then they are encrypted with password given by you.
If you obtained a certificate and its private key in PEM or another format, you must convert it to PKCS#12 (PFX) format before you can import the certificate into a Windows certificate store on a View server host.
You might obtain a certificate keystore file from a CA, or your organization might provide you with certificate files, in various formats. For example, your certificates might be in PEM format, which is often used in a Linux environment. Your files might have a certificate file, key file, and CSR file with the following extensions:
server.crt
server.csr
server.key
The CRT file contains the SSL certificate that was returned by the CA. The CSR file is the original certificate signing request file and is not needed. The KEY file contains the private key.
Using these files you can generate PKCS file using openssl tool
openssl pkcs12 -export -out server.p12 -inkey server.key -in server.crt -certfile CACert.crt
In this example, CACert.crt is the name of the root certificate that was returned by the certificate authority.
You can also generate a keystore with a PFX extension.
For example: -out server.pfx