Original address: http://blog.csdn.net/mycoolx/article/details/6730435 Thanks to the blogger
Although PEM is used as the basic file encoding format in OpenSSL, because the encapsulation of different objects is not the same as the standard format, it often leads to confusion for readers.
1. Data encoding format
First introduce the ASN.1 (Abstract Syntax Notation One) standard, which is a method and standard for describing digital objects. ASN1 is a structured digital object description language, which consists of two parts: data description language (ISO 8824) and data encoding rules (ISO 8825). The data description language of ASN.1 allows users to customize basic data types, and can compose more complex data types from simple data types. For example: a complex data object, such as an X.509 certificate, is defined on some other data type, and other data types are built on more basic data types, until back to the most basic data type defined .
ASN.1 provides a variety of data encoding methods. Including BER, DER, PER and XER, etc. These encoding methods specify a set of rules for converting digital objects into a binary-encoded form that applications can process, store, and transmit over the network. At present, BER (Basic Encode Rules) encoding is often used, but BER encoding has the property of non-unique encoding, that is, the same object may generate several different encoded data through BER encoding. Therefore, a sub-DER (Distinguished Encoding Rules) of BER is often used in OpenSSL and other cryptography-related software. For each ASN.1 object, the binary code data obtained using DER encoding is unique.
The full name of PEM encoding is Privacy Enhanced Mail, which is an encoding standard for confidential mail. Generally speaking, the encoding process of information is basically as follows.
- The information is converted to ASCII code or other encoding methods, such as DER encoding.
- Encrypts encoded information using a symmetric encryption algorithm.
- The encrypted information is encoded using BASE64.
- Use some header definitions to encapsulate the information, mainly including the information needed for correct decoding. The format of the header definition is as follows:
Proc-Type: 4, ENCRYPTED
DEK-Info: cipher-name, ivec
Among them, the first header information indicates whether the file is encrypted. The possible values of the header information include ENCRYPTED (information has been encrypted and signed), MIC- ONLY (information is digitally signed but not encrypted), MIC-CLEAR (information is digitally signed but not encrypted or encoded, and can be read in non-PEM format), and CLEAR; the second header information indicates the encryption algorithm and symmetry The initial vector used by the encryption block algorithm. - Add the following header annotation information in front of these messages:
---BEGIN PRIVACY-ENHANCED MESSAGE---
Add the following tail annotation information after these messages:
---END PRIVACY-ENHANCED MESSAGE---
OpenSSL PEM encoding is basically based on DER encoding, that is to say, it uses DER encoding in the first step above, so, in essence, OpenSSL's PEM encoding is BASE64 encoding based on DER encoding, and then Add some header and tail information.
2. Certificate Standards
The data encoding format provides a basic way to encapsulate data, but for specific data objects, such as certificates, there are more specific expressions depending on what they contain.
1. X.509 certificate
At present, there are three commonly used certificate encoding formats: X.509 certificate, PKCS#12 certificate and PKCS#7 certificate. X.509 certificate is the most frequently used certificate. It only contains public key information but no private key information, and can be published publicly, so X.509 certificate objects generally do not need to be encrypted.
The format of an X.509 certificate is usually as follows:
...relevant human-readable interpretation information (omitted)...
---BEGIN CERTIFICATE---
...PEM-encoded X.509 certificate content (omitted)...
---END CERTIFICATE ---
In addition to the "---BEGIN CERTIFICATE---" and "---END CERTIFICATE---" header and tail formats, there may be such different identifiers: "---BEGIN X.509 CERTIFICATE-- -", "---END X.509 CERTIFICATE---" or "---BEGIN TRUSTED CERTIFICATE---", "---END TRUSTED CERTIFICATE---"
Many readable certificate plaintext explanations at the front of the certificate file actually issued by OpenSSL are only to increase the readability of the certificate file and do not represent real data. In other software, such as Windows software, these additional plaintext information may not be supported, so first remove all readable information before "---BEGIN CERTIFICATE---". It can be deleted manually, or you can use PEM-to-PEM certificate format conversion to remove these plaintext readable information.
On the Windows platform, the suffixes of X.509 certificate files are often der, cer or crt, which can be automatically recognized. For OpenSSL, the suffix is meaningless.
2. Netscape certificate standard
Netscape provides a format called Netscape Certificate Sequence (Netscape Cerificate Sequence) to encapsulate a series of certificates (in fact, a PKCS#7 format is used to encapsulate certificates). In order to be able to download or transfer multiple digital certificates at one time. So, in some cases, the Netscape certificate sequence can replace the role of PKCS#7, used to package a series of certificates.
Although the Netscape certificate sequence is not necessarily supported by Microsoft, it is widely supported in some other open source software and Linux software.
3. Certificate encapsulation
1. PKCS#12 certificate
PKCS#12 certificate is different from X.509 certificate, it can contain one or more certificates, and can also contain the private key corresponding to the certificate. The private key of PKCS#12 is encrypted, and the key is generated by the password provided by the user. Therefore, regardless of the use of PKCS#12 certificates, the user is generally required to enter the key password.
PKCS#12 certificate file supports p12 or pfx in the Windwos platform and Mozzila. If you want to use your own certificate correctly in IE or Mozzila, you generally need to convert it into PKCS# containing public key and private key. 12 The certificate is integrated into the relevant software.
2、PKCS#7
PKCS#7 can encapsulate one or more X.509 certificates or PKCS#6 certificates (PKCS#6 is a certificate format, but not often used), CA certificates on the associated certificate chain, and can contain CRL information. PKCS#7 does not contain private key information. PKCS#7 can include all the certificates on the entire certificate required to verify the certificate, so as to facilitate the issuance and correct use of the certificate. In this way, the PKCS#7 certificate can be directly sent to the verifier for verification, eliminating the tediousness of sending the above verification contents to the receiver one by one.
The legal extension for PKCS#7 files on Windows is p7b.
3、PKCS#8
The PKCS#8 standard is a very simple standard, which is mainly used to encapsulate private key and other related attribute information. Generally speaking, the private key in PKCS#8 format is encrypted and supports the algorithms defined by the PKCS#5 and PKCS#12 standards . Of course, the private key may not be encrypted. On the one hand, the PKCS#8 standard can enhance the security of the private key, and on the other hand, it also provides a simple way for users to establish a trust relationship, which is mainly based on the special name of the private key and the authoritative public key of the highest-level trusted person, etc. property information.
The PEM-encoded PKCS#8 standard files provided by OpenSSL are divided into two types: encrypted and non-encrypted. The encrypted PKCS#8 key is identified as follows:
——BEGIN ENCRYPTED PRIVATE KEY——
——END ENCRYPTED PRIVATE KEY——
Unencrypted PKCS#8 keys are identified as follows:
——BEGIN PRIVATE KEY——
——END PRIVATE KEY——
Fourth, the key encoding
There are many forms of keys, and in many cases, these keys need to be saved. The keys to be saved are usually encoded using both PEM and DER encodings.
The key file stored in DER encoding is unreadable, if you open it with a text editor you will see some incomprehensible symbols because this is a binary encoded file. PEM is different, it is much friendlier because PEM is BASE64 encoded. Open the PEM-encoded key file with a text editor, and you can see that, similar to certificates, their real encodings are contained in pairs of symbols like: ---BEGIN XXXXXX--- and ---END XXXXXX--- Inside.
Generally speaking, there are two kinds of keys, one can be disclosed (such as the public key of a public key pair), and the other cannot be disclosed (such as the private key of a public key pair). Reflected in the encoding, some key files need to be encrypted, and some do not. An encrypted PEM-encoded key file will add some header information to the above symbols. These header information is mainly to provide useful information for key decryption, including marking the encryption state of the key, the encryption algorithm used and the initial amount of bribes. (for block encryption algorithms). E.g:
---BEGIN RSA PRIVATE KEY---
Proc-Type: 4, ENCRYPTED
DEK-Info: DES-ED3-CBC, 86B0167E005535D2
……(Encrypted content key part)……
---END RSA PRIVATE KEY---
The above PEM encodes the RSA (RSA PRIVATE KEY) private key, which is encrypted (ENCRYPTED), uses the CBC mode of 3DES (DES-EDE3-CBC), and uses the IV vector "86B0167E005535D2".
5. Other standards
The Certificate Revocation List (CRL) is an important reference for users to verify certificates. It mainly contains a list of invalid certificates and tells users which certificates have been revoked or invalid. If you don't have a CRL, you can choose another verification method, which is to use the Online Certificate Services Protocol (OCSP). OCSP is not always available, for example your network may not be able to reach the OCSP server sometimes. CRL is a solution used by the opposite party and independent. As long as the CRL provided by the CA center within the validity period is obtained, the validity of the certificate can basically be verified. The CRL encoded in PEM format is generally contained in a pair of symbols: "---BEGIN X.509 CRL---" and "---END X.509 CRL---". CRLs can also be saved in DER format.