[ssl certification, certificate] Basic concept of SSL certificate, certificate format, difference between openssl and keytool

Related articles:
//-----------Java SSL begin----------------------
【ssl authentication, certificate】SSL two-way authentication Difference with SSL one-way authentication (schematic diagram)
[ssl authentication, certificate] ssl syntax API description (SSLContext) in java, connection with keytool tool
[ssl authentication, certificate] SSL two-way authentication java actual combat, keytool create certificate
[ssl authentication , certificate] Wireshark packet capture analysis
[ssl certification, certificate] View the content of the keystore file
//------------Java SSL end---------------- ----------

//-----------The following is the knowledge related to CA certificate and openssl-------------
[ssl certification, certificate] TLS/SSL two-way certification concept, openssl genrsa example
[ssl certification, certificate] openssl genrsa command detailed explanation
[ssl certification, certificate] SSL certificate basic concept, certificate format, difference between openssl and keytool

1. keytool VS openssl

keytool and openssl are two certificate management 工具.

First of all, a premise must be confirmed. The certificate generated by keytool is strongly related to the ssl communication in Java language. The certificate generated by OpenSSL needs to be converted into a format that Java can recognize according to the corresponding format before it can be used.

• keytool is a certificate management tool that comes with java JDK. Using keytool can generate keys and create certificates. As long as the jdk is installed and the environment variables are set correctly, you can execute the keytool command through the command line to manage the certificate.

  keytool can only generate self-signed digital certificates. The so-called self-signed certificate is not issued by the CA issuing agency, but issued by itself. Since the CA root certificate cannot be used to judge the validity of the certificate, the certificate verification can only be performed in the form of a white list. For each server to be connected, A copy of the certificate must be copied in advance and placed in the trust key store (TKS for short). The certificate in TKS is the white list of trusted certificates, that is, compared with standard SSL in Java SSL communication, JAVA customizes the verification of certificates. TKS is designed to replace the CA_ROOT detection certificate. Therefore, Keytool has the disadvantage that it needs to be copied in advance and imported into TKS as a whitelist.

• openssl is an open source Secure Sockets Layer cryptographic library with more functions than keytool.

  OpenSSL is a standard SSL implementation that utilizes certificate chains for mutual or one-way authentication. The certificate chain means that the signature of the certificate has a pre-deployed and well-known signer signature, so that every time you need to verify the certificate, you only need to use the public key of the public signer (the root certificate is essentially this public key) for verification. OK. For example, the browser we use saves several commonly used CA_ROOT (that is, the root certificate that is often called). Every time you connect to a website, as long as you judge that the certificate of this website has been signed by these CA_ROOT, it will be recognized and verified.

  And the certificate is sent to the peer end through the network, there is no need to copy it to the peer end in advance, CA_ROOT is preset, and it is a well-known CA institution, which is very reliable.

  The shared CA_ROOT service is not free and expensive. If it is an internal communication within an enterprise, you can use the self-issued CA_ROOT to generate a self-signed certificate. At the same time, send the CA_ROOT to the peer in advance, then the follow-up process is the same as the standard The SSL flow is the same

2. X.509 VS PKCS

In the computer world, there are various cryptography standards, which represent how to calculate, store, transmit (etc.) various algorithms in computers, and these standards are written by standard organizations such as IEFT, ITU-T, and ISO.

Before discussing these things, here is a reminder that the private key mentioned in some places below is actually not a pure private key (such as in RSA
), but contains all the necessary information of the entire key pair The key (which naturally also includes the public key), which is why the public key can be extracted from the private key.

For example, the RSA public key is included in RSAPrivateKey, and the ECC public key is included in ECPrivateKey.

PKCS 协议组和 X.509 协议均采用 ASN.1 来定义密钥或证书的数据结构. are all ASN.1 协议concrete implementations.

Relationship overview:

2.1 PKCS

The full name of PKCS is Public-Key Cryptography Standards, that is, public key standards. PKCS has released 15 standards.

• PKCS#1 is closer to X.509
• …
• PKCS#12 contains public and private keys in the form of certificates in binary format, with a .pfxcertificate file suffix. Other types of general public and private keys will not be put together and are generally non- .pfxformatted.

Although it is called a public key standard, it also contains a private key standard

standard	Version	name	Introduction
PKCS #1	2.2	RSA Cryptography Standard	Provides proposals for the implementation of public-key cryptography based on the RSA algorithm, including cryptographic primitives, encryption schemes, signature schemes with appendices, and the ASN.1 syntax for representing keys and identifying schemes. See RFC 8017.
PKCS #2	-	deprecate	The transformation that was originally intended to standardize RSA encrypted digests has been incorporated into PKCS #1.
PKCS #3	1.4	Diffie-Hellman protocol standard (Diffie-Hellman key agreement Standard)	Specifies the key agreement standard based on the Diffie-Hellman protocol. Its function allows two parties to draft a meeting key (Session key) through an agreement.
PKCS #4	-	deprecate	Originally used to standardize the process of converting RSA keys. Has been incorporated into PKCS #1.
PKCS #5	2.1	Password-based Encryption Standard	See RFC 8018.
PKCS #6	1.5	Extended-Certificate Syntax Standard	Extend the original X.509 certificate format standard.
PKCS #7	1.5	Cryptographic Message Syntax Standard	See RFC 2315. Specifies the format of the signature/ciphertext generated by the Public Key Infrastructure (PKI). The same purpose is to expand the application of digital certificates. Among them, S/MIME and CMS (English: Cryptographic Message Syntax) are included.
PKCS #8	1.2	Private-Key Information Syntax Standard	Standard syntax for storing private key information. See RFC 5208.
PKCS #9	2.0	Selected Attribute Types	Defines the select attribute format for PKCS #6, 7, 8, 10.
PKCS #10	1.7	Certificate Application Standard (Certification Request Standard)	See RFC 2986. Standardizes the format of the CSR (certificate signing request) for applying for a certificate from the certificate center.
PKCS #11	2.20	Cryptographic Token Interface (Cryptoki)	Defines the specification for the application programming interface (API) of cryptographic devices.
PKCS #12	1.0	Personal Information Exchange Syntax Standard	Defines a file format that contains private and public key certificates . The private key is password protected. The common PFX format implements PKCS #12.
PKCS #13	–	Elliptic curve cryptography Standard	under development. Standardize the application of cryptographic technology developed on the basis of elliptic curve cryptography. Elliptic curve cryptography is a new cryptographic technology, and its strength and efficiency are superior to the current cryptographic algorithms based on exponential operations. However, the application of this algorithm is not yet widespread.
PKCS #14	–	Pseudorandom number generator standard	under development. Regulates the use and design of pseudorandom number generators.
PKCS #15	1.1	Cryptographic Token Information Format Standard	Defines the organizational structure of the internal data of the cryptographic device.

2.2 X.509

X.509 is a format standard for public key certificates in cryptography. X.509 certificates have been used in many network protocols including TLS/SSL, and it is also used in many offline application scenarios, such as electronic signature services.X.509 证书里含有公钥、身份信息（比如网络主机名，组织的名称或个体名称等）和签名信息（可以是证书签发机构 CA 的签名，也可以是自签名）

Although it is called a public key standard, it also contains a private key standard

2.2.1 Certificate encoding format

DER and perm are protocols, the former is binary and the latter is text;

2.2.1.1 DER certificate encoding format binary

X.690 is an ITU-T standard that specifies several ASN.1 encoding formats:

• The encoding format of Basic Encoding Rules (BER, Basic Encoding Rules) 抽象, generally not actually used as a suffix
• Canonical Encoding Rules (CER, Canonical Encoding Rules) binary, often used as the actual suffix
• Distinguished Encoding Rules (DER, Distinguished Encoding Rules) binary, a subset of BER, often used as the actual suffix

BER 是 ASN.1 标准制定的用于将数据编码为二进制格式的原始规则. Collectively known in ASN.1 parlance as the transfer syntax, these rules specify the exact octets (8-bit bytes) used to encode data.

DER 是 BER 的子集, which provides a way to encode ASN.1 values. DER is suitable for situations where unique encodings are required, such as in cryptography, and ensures that data structures requiring digital signatures result in unique serialized representations. DER can be thought of as the canonical form of BER.

In terms of cryptography, it can be simply understood that the DER 就是 ASN.1 的二进制表达commonly used suffix .derkey/certificate files store the binary of DER rules, which can be parsed into the abstract structure of ASN.1.

.derAs an example, this is the byte content of an actual X.509 public key file:

30 82 01 22 30 0D 06 09 2A 86 48 86 F7 0D 01 01
01 05 00 03 82 01 0F 00 30 82 01 0A 02 82 01 01
00 B5 42 F1 89 F0 7D 0D 70 44 D3 CA 3D 6A 94 A8
D8 5A A7 C9 CC 02 8A 23 F7 AB F8 87 A7 3A 60 FC
EC DE 1D 25 8C 27 8D 19 C3 21 84 5C D4 D7 8A 2E
32 BF 66 C1 51 8A 94 B3 72 06 BE D5 B8 41 15 DF
7F C4 1B 55 F4 4A 60 CC 54 0B B8 AD 3F AF AF 71
FC 17 42 78 72 AC 8D 5E BE C3 29 D8 98 6B AA DB
90 86 AB 08 A7 19 FE 33 FB FB 56 23 EE 33 3E F3
95 98 09 38 6C B9 A1 F9 F5 18 94 1B 8E CF D2 F0
27 4B BC 24 52 0C 70 E4 A6 B9 EB 96 60 14 09 BB
7C B7 FF E4 B0 17 A4 28 68 55 D5 1E 5E 84 57 CD
9C E0 FC 35 31 A7 53 80 BE 30 82 94 34 15 C0 75
DB EF A4 BB 01 D7 E6 17 83 52 8B 2E 0E B1 DA C5
32 2D B6 F7 EB 2F AE 3A ED DE 3B FA 3A F8 F2 5D
BC 84 BC E3 F8 BB 1B 5D 85 06 AB C2 B8 8A 82 8E
9D 38 71 79 54 7E 91 FA 7A 14 CF 20 AF 5E 54 22
F1 B6 D3 D2 89 21 43 75 65 3D 74 4B D7 2E 78 52
03 02 03 01 00 01

Its corresponding ASN.1 is:

SEQUENCE {
    
    
  SEQUENCE {
    
    
    OBJECT IDENTIFIER 1.2.840.113549.1.1.1 rsaEncryption (PKCS #1)
    NULL
  }
  BIT STRING {
    
    
    SEQUENCE {
    
    
      INTEGER 228821442744892501318627381803596567786967739438082404228277133253533…
      INTEGER 65537
    }
  }
}

2.2.1.2 text format pem

Several security-related standards used on the Internet define ASN.1 data formats, which are usually encoded using Basic Encoding Rules (BER) or Distinguished Encoding Rules (DER), which are binary encodings. A disadvantage of the binary data format is that it cannot be exchanged in text transmissions such as email or text documents. An advantage of text-based encodings is that they are easy to modify using common text editors; for example, users can concatenate multiple certificates to form a certificate chain with copy and paste operations.

Privacy Enhanced Mail (PEM, Privacy Enhanced Mail) can be traced back to RFC 1421, which is based on Marshall Rose's proposal in Message Encapsulation (RFC 934). Originally known as "PEM Encapsulation Mechanism", "Encapsulated PEM Message", or "PEM Printable Encoding", today the format is sometimes referred to as "PEM Encoding". It specifies the standard form of the grammar and declares end-of-line characters as carriage return/line feed pairs.

In simple terms, it actually is 二进制内容用 Base64 编码一下，然后加上-----BEGIN label-----形式的头部和-----END label-----形式的尾部.

However, RFCs are written by looking at existing implementations and documenting what they do. RFCs were not written in the first place, nor were they based on some existing authoritative document. Therefore, if you want to interoperate with certain implementations, you may have to look at the implementation's source code to determine what they support.

For example, OpenSSL defines these BEGINand ENDflags in crypto/pem/pem.h. Below is an excerpt of the header file with all the BEGIN and END tags they support.

# define PEM_STRING_X509_OLD     "X509 CERTIFICATE"
# define PEM_STRING_X509         "CERTIFICATE"
# define PEM_STRING_X509_TRUSTED "TRUSTED CERTIFICATE"
# define PEM_STRING_X509_REQ_OLD "NEW CERTIFICATE REQUEST"
# define PEM_STRING_X509_REQ     "CERTIFICATE REQUEST"
# define PEM_STRING_X509_CRL     "X509 CRL"
# define PEM_STRING_EVP_PKEY     "ANY PRIVATE KEY"
# define PEM_STRING_PUBLIC       "PUBLIC KEY"
# define PEM_STRING_RSA          "RSA PRIVATE KEY"
# define PEM_STRING_RSA_PUBLIC   "RSA PUBLIC KEY"
# define PEM_STRING_DSA          "DSA PRIVATE KEY"
# define PEM_STRING_DSA_PUBLIC   "DSA PUBLIC KEY"
# define PEM_STRING_PKCS7        "PKCS7"
# define PEM_STRING_PKCS7_SIGNED "PKCS #7 SIGNED DATA"
# define PEM_STRING_PKCS8        "ENCRYPTED PRIVATE KEY"
# define PEM_STRING_PKCS8INF     "PRIVATE KEY"
# define PEM_STRING_DHPARAMS     "DH PARAMETERS"
# define PEM_STRING_DHXPARAMS    "X9.42 DH PARAMETERS"
# define PEM_STRING_SSL_SESSION  "SSL SESSION PARAMETERS"
# define PEM_STRING_DSAPARAMS    "DSA PARAMETERS"
# define PEM_STRING_ECDSA_PUBLIC "ECDSA PUBLIC KEY"
# define PEM_STRING_ECPARAMETERS "EC PARAMETERS"
# define PEM_STRING_ECPRIVATEKEY "EC PRIVATE KEY"
# define PEM_STRING_PARAMETERS   "PARAMETERS"
# define PEM_STRING_CMS          "CMS"

The file format of the PEM file:

-----BEGIN (label)-----
/*　　data　　*/
-----END (label)-----

The label determines the type of encoded message, usually these types are as follows:
"CERTIFICATE", "CERTIFICATE REQUEST", "PRIVATE KEY", "ENCRYPTED PRIVATE KEY" and "X509 CRL".

For example, X.509 公钥the markup is:

-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----

X.509 证书is marked as:

---- BEGIN CERTIFICATE----
/* 证书 */
----END CERTIFICATE----

X.509 证书请求is marked as:

-----BEGIN CERTIFICATE REQUEST-----
/*    CSR    */
-----END CERTIFICATE REQUEST-----

PKCS #1 公钥is marked as:

-----BEGIN RSA PUBLIC KEY-----
-----END RSA PUBLIC KEY-----

PKCS #1 加密私钥is marked as:

-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

PKCS #8 未加密私钥is marked as:

-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----

The signature of the private key after PKCS #8 encryption is:

-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----

2.2.2 File extension

We have known the format of the certificate in binary and text form before, so in order to facilitate the user to identify the protocol and other information of the certificate, some suffixes are agreed. Through the suffix, the user probably knows some information about the certificate

File extension	file type	illustrate
*.CRT	binary or text format	The abbreviation of Certificate, which means the certificate file, and only contains the certificate information, not the private key. Mostly used in linux systems
*.CER	binary or text format	Almost the same as the crt above, it means a certificate file, mostly used in windows
*.PEM	text format	It is both a protocol and a suffix; the text format is IDE encoded, and generally stores certificates or private keys, or both certificates and private keys. If the .PEM file only contains the private key, it is generally replaced by the .KEY file.
*.THE	binary format	It is both a protocol and a suffix; binary format IDE code, generally storing certificates or private keys, or containing both certificates and private keys.
.PFX or .P12	binary format	Contains both the certificate and the private key, and is generally password-protected.
.JKS	binary format	Contains both the certificate and the private key, usually password-protected.

From the table above it can be seen that:

• CER or CRT is synonymous with certificate and does not contain private key.

• der and pem are protocols, and they can be directly used as suffixes to let users know whether they are stored in binary or text, but the specific content can be a certificate or a key

• The pem format can be viewed directly through the cat command, starting with "—–BEGIN…” and ending with “—–END…”

• 二进制格式无法直接查看，可以通过 openssl x509 -text -in server.cert 进行查看，此时会转换为以”—–BEGIN…”开头, “—–END…”结尾

• 二进制 和 文本之间PEM可以互相转换 ，因为只是 编码格式的转换 ，你也可以把pem转换为二进制格式

• PFX和JKS 是包含证书和私钥的，其他的一定都不含。

  • 利用Java的一个叫”keytool”的工具,可以将PFX转为JKS,当然了,keytool也能直接生成JKS
  • 此外，证书含有私钥，那么别人获取证书时，要是导出私钥怎么办？很简单，在创建pfx时，有参数可以禁止导出私钥；即使允许导出私钥，你需要提供导出私钥的密码，这个密码保证了不是任何人都能随意导出私钥

• BER是编码的基础规范，一般不作为文件的具体后缀名

• .csr 是证书请求文件，由客户生成，然后提供给CA签发机构，是由 RFC 2986定义的PKCS10格式，包含部分/全部的请求证书的信息，比如，主题, 机构，国家等，并且包含了请求证书的公玥，这些被CA签发机构中心签名后返回一张证书。返回的证书是公钥证书（只包含公玥不含私钥）。

  也就是说公司名称等这些参数是放在请求文件中的，并且含有公钥，一并交给CA机构，公钥怎么来的？是利用私钥生成的，因此这个步骤入参需要私钥。虽然用到了私钥，但是产出的请求文件中，一定不含私钥。

  证书签名请求是申请人向证书颁发机构发送的一条消息，用于申请数字身份证书。

  有 CSR 必定有 KEY，是成对的，CSR 最终变成为证书 crt，和私钥 key 配对使用。证书下发后，CSR 就没有用了，只是在交时候需要。

3. 常见Web服务软件及证书格式

证书的使用分为2种场景，一种是web服务器，就是我们通过浏览器访问web网站时，由网站侧开启Https，通过443端口进行安全通信，背后实际上是web服务器在起作用，而web服务器能只能识别指定的证书格式；另一个场景就是端到端通信，就是socket编码，此时需要根据不同的语言，来实现具体的证书格式。

Common Web service software is usually based on two basic cryptographic libraries, OpenSSL and Java.

• Web service software such as Tomcat, Weblogic, and JBoss generally use the password library provided by Java. Use the Keytool tool in the Java Development Kit (JDK) toolkit to generate certificate files in Java Keystore (JKS) and keystore formats.

  Both .keystore and .jks are files used by java to store keys. It enables users to manage their own public/private key pairs and associated certificates for (via digital signatures) self-authentication (users authenticating themselves to other users/services) or data integrity and authentication services. It also allows users to store the public keys (in the form of certificates) of their communicating peers.

• Web service software such as Apache and Nginx generally use the cryptographic library provided by the OpenSSL tool to generate certificate files in formats such as PEM, KEY, and CRT.

• IBM's Web service products, such as Websphere, IBM Http Server (IHS), etc., generally use the iKeyman tool that comes with IBM products to generate certificate files in KDB format.

• The Internet Information Services (IIS) service in Microsoft Windows Server uses the certificate library that comes with Windows to generate a certificate file in PFX format.

reference

Basic concepts of SSL certificate Literacy
Cryptography (2): Cryptography Standards - X.509 and PKCS Series
SSL/TLS Digital Certificate Various Formats Explanation
Detailed Explanation of Various Formats of SSL Certificates