Differences in certificate formats and conversion of formats in OpenSSL

The concepts related to certificates are really tricky because they haven't been exposed to certificate encryption before, because there's a whole new term coming up that looks like something else in another field, not something that we're familiar with in the programming world, at least personally, and I don't know much about it for a long time. The purpose of writing this article is to clarify these concepts, to understand their meaning and relevance, and to have some basic operations.

The PKCS full name is Public-key Cryptography standards, a series of standards developed by RSA Labs and other security system developers to promote the development of public key cryptography, which currently has 15 standards:

(1) PKCS#1:RSA Encryption Standard. PKCS#1 defines the basic format standard for RSA public key functions, especially digital signatures. It defines how a digital signature is computed, including the format of the data to be signed and the signature itself, and defines the syntax for the PSA public/private key.

(2) Pkcs#2: A message digest encryption involving RSA, which has been incorporated into the pkcs#1.

(3) Pkcs#3:diffie-hellman key protocol standard. Pkcs#3 describes a method of implementing Diffie-hellman key protocol.

(4) PKCS#4: Originally defined RSA key syntax, has now been included in the pkcs#1.

(5) Pkcs#5: password-based encryption standard. Pkcs#5 describes the method of encrypting a 8-bit string and generating an encrypted 8-bit string using a password-generated key. The pkcs#5 can be used to encrypt the private key for secure transfer of the key (as described in Pkcs#8).

(6) Pkcs#6: Extended certificate Syntax standard. PKCS#6 defines the syntax for the properties extension of the "+/-Certificate" that provides additional entity information (the extension is not supported for the first time Pkcs#6 is released.) These extensions are therefore included in the ".

(7) PKCS#7: Password message Syntax standard. PKCS#7 provides general syntax for data using cryptographic algorithms, such as digital signatures and digital envelopes. PKCS#7 provides a number of formatting options, including unencrypted or signed formatted messages, encapsulated (encrypted) messages, signed messages, and signed and encrypted messages.

(8) Pkcs#8: Private key information Syntax standard. Pkcs#8 defines the private key information syntax and the cryptographic private key syntax, where the private key encryption uses the PKCS#5 standard.

(9) pkcs#9: Optional attribute type. pkcs#9 defines pkcs#6 extension certificates, pkcs#7 digital signature messages, pkcs#8 private key information, and optional attribute types to be used in PKCS#10 certificate signing requests. The defined certificate properties include e-mail address, unformatted name, content type, message digest, signature time, Signature copy (counter signature), challenge password Word, and extended certificate properties.

(PKCS#10): Certificate request Syntax standard. PKCS#10 defines the syntax for a certificate request. A certificate request contains a unique distinguished name, a public key, and an optional set of properties that are signed together by the entity that requested the certificate (the PKIX certificate request message in the Certificate Management Protocol is a pkcs#10).

(one) pkcs#11: Password token interface standard. Pkcs#11 or "Cryptoki" defines an application interface (API) for a single-user device that has password information (such as encryption keys and certificates) and performs cryptographic functions. A smart card is a typical device that implements Cryptoki. Note: Cryptoki defines the cryptographic function interface, but does not indicate how the device specifically implements these functions. And Cryptoki only describes the password interface, and does not define other interfaces that might be useful to the device, such as accessing the device's file system interface.

(PKCS#12): The standard of personal Information exchange grammar. PKCS#12 defines the format of personally identifiable information, including private keys, certificates, various secrets, and extended fields. PKCS#12 facilitates the transfer of certificates and their corresponding private keys, so that users can move their personally identifiable information between different devices.

PDCS#13: Elliptic curve cipher standard. The PKCS#13 standard is currently being perfected. It includes the generation and validation of elliptic curve parameters, key generation and validation, digital signatures and public key cryptography, as well as key contracts, and the ASN.1 syntax for parameters, keys, and scheme identities.

PKCS#14: Pseudo-random number generation standard. The PKCS#14 standard is currently being perfected. Why random number generation also needs to establish its own standards. Many of the basic cryptographic functions used in PKI, such as key generation and Diffie-hellman shared key negotiation, need to use random numbers. However, if the "random number" is not random, but is taken from a predictable collection of values, then the cryptographic function is no longer absolutely secure, because its value is limited to a narrowed range of values. Therefore, the generation of security pseudo-random number is very important for PKI security.

(pkcs#15): Password token information Syntax standard. PKCS#15 improves the interoperability of password tokens by defining a common format for password objects stored on tokens. The data stored on the device that implements PKCS#15 is the same for all applications that use the device, although it may actually be in a different format when implemented internally. The implementation of PKCS#15 plays the role of translator, which translates between the internal format of the card and the data formats supported by the application.

Pkcs#7 commonly used suffixes are:. p7b. p7c. Spc
Pkcs#12 commonly used suffixes are:. P12. PFX
The suffix of the DER encoded (ASCII) is:. DER. Cer. Crt
The suffix of the Base64 is:. Pem. Cer. Crt
The. CER/.CRT is used for storing certificates, which are stored in 2 binary form and do not contain private keys.
The difference between a. Pem and a crt/cer is that it is expressed in ASCII.
PFX/P12 is used to store personal certificates/private keys, he usually contains protection password, 2 binary mode
P10 is a certificate request
P7R is the CA's response to a certificate request and is used only for import
P7B Displays the certificate chain (certificate chain) in a tree form, and also supports a single certificate, without a private key.

1. Certificate Format PEM Format

The PEM format is typically used for digital certificate certification authorities (Certificate Authorities,ca) with a. PEM,. crt,. cer,. Keyextension. The content is BASE64 encoded ASCII code file, there are similar to "-–begin certificate-–" and "-–end certificate-–" of the kinsoku. Server Authentication certificate, intermediate certificate and private key can be stored in PEM format (the authentication certificate is actually the public key). Apache and similar servers use the PEM format certificate. DER Format

The DER format differs from PEM in that it uses binary rather than BASE64 encoded ASCII. The extension is . Der, but it is also often used as an extension, and all types of authentication certificates and private keys can be stored in der format. Java makes it a typical use of the platform. pkcs#7/p7b Format

The pkcs#7 or P7B format is typically stored in Base64 format, with a . p7b or. p7cextension, and a tail-and-kinsoku marker similar to begin pkcs7-– "and"-–end pkcs7-– ". Pkcs#7 or p7b can only store certificates in the certificate or certification path (that is, the storage certificate chain, this level, the superior, to the root level are stored in a file). The private key cannot be stored, and both Windows and Tomcat support this format. pkcs#12/pfx Format

The PKCS#12 or PFX format is the storage server certificate, intermediate certificate, and private key in encrypted binary form. With the extension . pfx and. P12, PXF is typically used for import and export authentication certificates and private keys in Windows.

2. Conversion Mode You can use the OpenSSL command-line tool to convert between different certificate formats

PEM to DER

OpenSSL x509-outform der-in certificate.pem-out Certificate.der

PEM to p7b

OpenSSL crl2pkcs7-nocrl-certfile certificate.cer-out certificate.p7b-certfile cacert.cer

PEM to PFX

OpenSSL pkcs12-export-out certificate.pfx-inkey privatekey.key-in certificate.crt-certfile CACert.crt

DER to PEM

OpenSSL x509-inform der-in certificate.cer-out Certificate.pem

p7b to PEM

OpenSSL pkcs7-print_certs-in certificate.p7b-out certificate.cer

PFX to PEM

OpenSSL pkcs12-in certificate.pfx-out certificate.cer-nodes

PXF to PEM The Certificate.cer file contains the authentication certificate and the private key, which need to be stored separately for use.

X509

The most common common certificate format is the. All certificates conform to the ITU-T X509 International Standard established for public Key Infrastructure (PKI). The International Telecommunication Union-Telecommunication (ITU-T) standard and the ISO certificate format standard are the most. As part of the Itu-iso directory service family Standard, the primary standard for defining the structure of a public key certificate is. 1988 first release, 1993 and 1996 two revisions. The currently used version is the V3, which adds extended field support, which greatly improves the flexibility of the certificate. The V3 certificate includes a set of mandatory fields in a predefined order, as well as an optional extension field, even in the mandatory field, which allows for a great degree of flexibility, because it provides multiple coding schemes for most fields.