Shulou(Shulou.com)06/01 Report--

Taking X.509 certificate as an example, this paper introduces in detail the concept and structure of X.509 certificate, as well as the use of X.509 certificate. I believe you have some understanding of X.509 certificate after reading the complete article.

1) Certificate

The X.509 standard is the format standard for public key certificates in cryptography. X.509 certificate has been used in many Internet protocols, including TLS/SSL (the cornerstone of secure browsing of WWW World wide Web). At the same time, it also has many off-line application scenarios, such as electronic signature services. The X.509 certificate contains a public key and identity (hostname, organization, or individual) and is signed (or self-signed) by a certification authority (CA). For a certificate signed by a trusted certificate issuer (or can be verified by other means), the certificate owner can use the certificate and the corresponding private key to create a secure communication and digitally sign the document.

History and usage

X.509 was first released with X.500 on July 3, 1988, and it assumes that the certification authority (CA) that issues the certificate has a strict hierarchy. This is in sharp contrast to Web trust models such as PGP, because the PGP scheme allows anyone to sign (not just a CA with a special status) to prove the validity of someone else's key certificate. The design of the X.509 V3 certificate is very flexible. In addition to the support for the bridge topology network, it can also support the Mesh network for the point-to-point approach, similar to the web trust mechanism like OpenPGP, but this approach was rarely used before 2004.

The X.500 system is implemented only by sovereign States for the purpose of implementing the national identity information sharing treaty, while the IETF Public key Infrastructure (X.509) or the PKIX working Group has adjusted the standard to adapt to a more flexible Internet organizational structure. In fact, X.509 authentication refers to the X.509 v3 defined in RFC5280, including the PKIX certificate and certificate revocation list (CRL Profile) for IETF, often referred to as the public key infrastructure.

In the X.509 system, a certificate applicant obtains a signed certificate by initiating a Certificate signing request (CSR). To do this, it needs to generate a key pair, and then use the private key to sign the CSR (the private key itself should be properly preserved and kept secret). The CSR contains the identity information of the applicant, the public key of the applicant used to verify the CSR, and the proper name of the requested certificate (DN). The CSR may also have other identification information required by CA, and then CA issues a certificate to the proper name and binds a public key.

Organizations can distribute trusted root certificates to all members so that they can use the company's PKI system. Browsers such as Firefox, IE, Opera, Safari, and Google Chrome come pre-installed with a set of CA root certificates, so you can use these SSL certificates issued by mainstream CA directly. The developer of the browser directly affects its users' trust in third parties. FireFox provides a list in csv/html format.

X.509 also includes the Certificate revocation list (CRL) implementation standard, which is often overlooked in PKI systems. The method approved by IETF to check the validity of a certificate is the online Certificate status Protocol (OCSP), and OCSP inspection is enabled by Firefox 3 by default, as is the higher version of Windows starting with Vista.

1-1) structure of certificates

The structure of the X.509 certificate is to use ASN.1 (Abstract Syntax Notation One: abstract syntax markup) to describe its data structure and to encode it using ASN1 syntax.

The structure of X.509 v3 digital certificate is as follows:

● Certificate certificate

● Version Number version number

● Serial Number Serial number

● ID Signature Algorithm ID signature algorithm

● Issuer Name issuer name

● Validity period validity period

● Not before start date

● Not after as of Dat

● Subject Name topic name

● Subject pbulic Key Info topic Public key Information

● Public Key Algorithm public key algorithm

● Subject Public Key subject Public key

● Issuer Unique Identifier (optional) issuer unique identifier (optional)

● Subject Unique Identifier (optional) subject unique identifier (optional)

Extensions to ● Extensions (optional) certificates (optional)

...

● Certificate Sigature Algorithm Certificate signature algorithm

Signature of ● Certificate Signature certificate

1-2) an extension that indicates the specific use of the certificate

All extensions have an ID, expressed by object identifier, which is a collection, and a tag indicating whether the extension is decisive or not. When using a certificate, if you find an extension with a decisive mark on it, and the system does not know the purpose of the extension, it will refuse to use it. However, for indecisive expansion, non-recognition can be ignored. RFC 1422 gives the certificate structure of v1, and ITU-T adds the issuer and subject unique identifier in v2 so that it can be reused over time. An example of reuse is when a CA goes bankrupt and its name is removed from the public list, and after a while another CA can be registered with the same name, even if it has nothing to do with the previous one. However, IETF does not recommend reusing registrations with the same name. In addition, v2 is not widely used in Internet. V3 introduces extensions, which CA uses to issue a certificate for a specific purpose (for example, for code signing only).

The serial number of the certificate issued by the same CA must be unique for all versions.

RFC 5280 (and later versions) defines digital certificate extensions to indicate how to use certificates. Most of them come from joint-iso-ccitt (2) ds (5) id-ce (29) OID. Some of the most common ones defined in section 4.2.1 are:

● Basic Constraints, {id ce 19}, used to indicate whether a certificate is an CA certificate.

● Key Usage, {id ce 15}, specifies the cryptographic operations that can be performed by the public key contained in this certificate, for example, it can only be used for signing, but not for encryption.

● Extended Key Usage {id ce 37}, which is typically used to specify the purpose for which the public key in a leaf certificate is used. It includes a series of OID, each of which specifies a purpose. For example, {id pkix 31} indicates a TLS/SSL connection for the server side, and {id pkix 34} indicates that the key can be used to protect e-mail messages.

In general, when a certificate has an extension of multiple restricted uses, all restrictions should be met before it can be used. RFC 5280 has an example where the certificate contains both keyUsage and extendedKeyUsage. Such a certificate can only be used for the purpose specified by the two extensions, for example, when the network security service determines the purpose of the certificate, the extension will be judged at the same time.

1-3) Certificate file extension

X.509 certificates have several commonly used file extensions, but be aware that some of these extensions have other uses, which means that files with this extension may not be certificates, for example, they may just hold a private key.

● .pem: (privacy enhanced email), the DER-encoded certificate is then Base64-encoded, and the data is stored between "- BEGIN CERTIFICATE -" and "- END CERTIFICATE--"

● .cer, .crt, .der: usually in the form of binary DER, but Base64 coding is also common

● .p7b, .p7c-PKC#7:SignedData structure, no data, only certificates or CRL

●. P12-PKCS#12: can contain either a certificate (public key) or a password-protected private key

● .pfx: the predecessor of PKCS#12 (usually in PKCS#12 format, such as PFX files generated by IIS)

PKCS#7 is the format standard for signing or encrypting data, officially called a container. Because the certificate is verifiable real signature data, it can be expressed in the SignedData structure. The .P7C file is a degenerate SignedData structure that does not include signed data.

PKCS#12 evolved from the personal Information Exchange (PFX) standard and is used to exchange public and private objects in a single file.

2) Certificate chain and cross-certification

A certificate chain (that is, the certificate path in RFC 5280) starts with a final entity certificate, followed by one or more CA certificates, usually the last one is a self-signed certificate, and has the following relationship:

1. Except for the last certificate on the chain, the issuer of each certificate is equal to the subject of the subsequent certificate (the subject is the consumer).

two。 Except for the last certificate on the chain, each certificate is signed by a subsequent certificate.

3. The last certificate is the trust anchor: because it is obtained through some credible process, you can trust it.

The certificate chain is used to check whether the public key and other data contained in the target certificate (the first certificate in the chain) belong to its subject. The check is done by verifying its signature with the public key of the next certificate in the certificate chain, all the way to the end of the certificate chain, and since the last certificate is a trust anchor, successful achievement of the certificate will prove that the target certificate can be trusted.

The description in the previous paragraph is a simplified process of authentication path verification based on the RFC5280 definition, which actually involves additional checks, such as verifying the validity date of the certificate, finding CRL, and so on.

When studying how certificate chains are built and verified, it is important to note that specific certificates can be part of different certificate chains (all certificates on the chain are valid). This is because multiple CA certificates can be generated for the same subject and public key, but signed with different private keys (from different CA or from the same CA). Therefore, although a single X.509 certificate can have only one issuer and one CA signature, it can effectively link to multiple certificates, creating a completely different certificate chain. This is critical for cross-authentication between PKI and other applications, as detailed in the following example.

Each box in the following figure represents a certificate, the subject is shown in bold, A → B means "An is signed by B" (or, more accurately, An is signed by B containing the private key corresponding to the public key), and certificates of the same color (non-white / transparent) contain the same public key.

Example 1: cross-certification between two PKI at the root certificate authority (CA) level

In order for the user certificate of PKI 2 to be trusted by PKI 1, CA1 signs the certificate cert2.1 containing the CA2 public key. When cert2 and cert2.1 have the same subject and public key, cert2.2 (User 2) has two legal certificate chains: "cert2.2 → cert2" and "cert2.2 → cert2.1 → cert1".

CA2 can also generate a similar certificate cert1.1 that contains a CA1 public key, so that the certificate of a user of PKI 1, such as User 1, can be authenticated in PKI 2.

Example 2:CA certificate update

Read this article: learn about Certification path Construction (PDF,PKI Forum, 2002)

In order to smoothly transfer from the old private key to the new private key, the certificate issuer can issue two certificates, one is the signature of the new private key to the old public key, and the other is the signature of the old private key to the new public key. Both certificates are self-issued, but neither is self-signed. Note: there are also two new and old self-signed certificates.

Assuming that cert1 and cert3 contain the same public key (the old public key), there are two legal certificate chains for cert5, cert5 → cert1 and cert5 → cert3 → cert2, and the case of cert6 is similar. This allows the old user certificate to be transferred smoothly between the new and old root certificates.

3) examples of X.509 certificates

The following is an example of X.509 certificate decoding from Wikipedia Wikipedia.org and several other Wikipedia sites, published by GlobalSign, whose issuer field (Subject) describes Wikipedia as an organization, and the Subject Alternative Name field describes the hostnames that can be used. The Subject Public Key Info field contains an ECDSA public key, and the signature at the bottom is generated by the RSA private key of the GlobalSign.

3-1) final entity certificate

Net extract: the final entity certificate is commonly referred to as the user certificate, which is different from the CA certificate. The certificate subject in the final entity certificate cannot use the private key corresponding to the certificate to issue the certificate. The final entity and CA are two relative concepts: CA can use its private key to issue certificates, while the final entity cannot. Although the final entity certificate is not clearly defined in the X.509 standard, the concept of "final entity Public key Certificate revocation list (End-entity public-key certificate revocation list)" is defined, which shows that the final entity certificate refers to the user certificate. The final entity can be various types of entities, such as natural persons, organizations, equipment, Web servers, and so on.

Certificate: Data: Version: 3 (0x2) Serial Number: 10:e6:fc:62:b7:41:8a:d5:00:5e:45:b6 Signature Algorithm: sha256WithRSAEncryption Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA-SHA256-G2 Validity Not Before: Nov 21 08:00:00 2016 GMT Not After: Nov 22 07:59:59 2017 GMT Subject: C=US, ST=California, L=San Francisco, O=Wikimedia Foundation Inc. CN=*.wikipedia.org Subject PublicKey Info: PublicKey Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:c9:22:69:31:8a:d6:6c:ea:da:c3:7f:2c:ac:a5: af:c0:02:ea:81:cb:65:b9:fd : 0c:6d:46:5b:c9:1e: ed:b2:ac:2a:1b:4a:ec:80:7b:e7:1a:51:e0:df:f7: c7:4a:20:7b:91:4b:20:07:21:ce:cf:68:65:8c:c6: 9d:3b:ef:d5:c1 ASN1 OID: prime256v1 NIST CURVE: Pmur256 X509v3 extensions: X509v3 Key Usage: critical Digital Signature Key Agreement Authority Information Access: CA Issuers-URI: http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt OCSP-URI: http://ocsp2.globalsign.com/gsorganizationvalsha2g2 X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.4146.1.20 CPS: https://www.globalsign.com/repository/ Policy: 2.23.140.1.2.2 X509v3 Basic Constraints: CA:FALSE X509v3 CRL Distribution Points: Full Name: URI: http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl X509v3 Subject Alternative Name: DNS:*.wikipedia.org DNS:*.m.mediawiki.org, DNS:*.m.wikibooks.org, DNS:*.m.wikidata.org, DNS:*.m.wikimedia.org, DNS:*.m.wikimediafoundation.org, DNS:*.m.wikinews.org, DNS:*.m.wikipedia.org, DNS:*.m.wikiquote.org, DNS:*.m.wikisource.org, DNS:*.m.wikiversity.org, DNS:*.m.wikivoyage.org, DNS:*.m.wiktionary.org, DNS:*.mediawiki.org DNS:*.planet.wikimedia.org, DNS:*.wikibooks.org, DNS:*.wikidata.org, DNS:*.wikimedia.org, DNS:*.wikimediafoundation.org, DNS:*.wikinews.org, DNS:*.wikiquote.org, DNS:*.wikisource.org, DNS:*.wikiversity.org, DNS:*.wikivoyage.org, DNS:*.wiktionary.org, DNS:*.wmfusercontent.org, DNS:*.zero.wikipedia.org, DNS:mediawiki.org, DNS:w.wiki, DNS:wikibooks.org, DNS:wikidata.org DNS:wikimedia.org, DNS:wikimediafoundation.org, DNS:wikinews.org, DNS:wikiquote.org, DNS:wikisource.org, DNS:wikiversity.org, DNS:wikivoyage.org, DNS:wiktionary.org, DNS:wmfusercontent.org, DNS:wikipedia.org X509v3 Extended Key Usage: TLS Web Server Authentication TLS Web Client Authentication X509v3 Subject Key Identifier: 28:2A:26:2A:57:8B:3B:CE:B4:D6:AB:54:EF:D7:38:21:2C:49:5C:36 X509v3 Authority Key Identifier: keyid:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C Signature Algorithm: sha256WithRSAEncryption 8b:c3:ed:d1:9d:39:6f:af:40:72:bd:1e:18:5e:30:54:23:35:...

To verify this final entity certificate, you need an intermediate certificate that matches its issuer and authority key identifier (Authority Key Identifier):

Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA-SHA256-G2 X509v3 Authority Key Identifier: keyid:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C

In a TLS connection, the properly configured server will provide this intermediate layer as part of the handshake process, but the intermediate certificate can also be retrieved by extracting the "CA Issuers" URL from the final entity certificate.

3-2) Intermediate Certificate

Net pick: what is an intermediate certificate?

The intermediate certificate is used as an alternative to the root certificate. We use the intermediate certificate as the proxy because we have to save the root certificate behind many security layers to ensure that its key is absolutely inaccessible. Because the root certificate signs the intermediate certificate, the intermediate certificate can be used to sign the SSL "chain of trust" installed and maintained by the customer.

Note: if you do not install an intermediate certificate using an issued SSL certificate, you may not be able to establish a trusted chain certificate. This means that when visitors try to visit your website, they may receive a "security alert" error indicating that "the security certificate is issued by a company you have not chosen to trust." Faced with such warnings, potential customers are likely to move their business elsewhere.

The following is an example of an intermediate certificate signed by the CA root certificate and signed with the final entity certificate above.

Note: the subject field of this intermediate certificate is the same as the issuer field of the final entity certificate it signed, and the subject key identifier (subject key identifier) field of the intermediate certificate is the same as the authority key identifier (issuer's key identifier) field of the final entity certificate.

Certificate: Data: Version: 3 (0x2) Serial Number: 04:00:00:00:00:01:44:4e:f0:42:47 Signature Algorithm: sha256WithRSAEncryption Issuer: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA Validity Not Before: Feb 20 10:00:00 2014 GMT Not After: Feb 20 10:00:00 2024 GMT Subject: C=BE, O=GlobalSign nv-sa CN=GlobalSign Organization Validation CA-SHA256-G2 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:c7:0e:6c:3f:23:93:7f:cc:70:a5:9d:20:c3:0e:... Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Basic Constraints: critical CA:TRUE Pathlen:0 X509v3 Subject Key Identifier: 96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C X509v3 Certificate Policies: Policy: X509v3 Any Policy CPS: https://www.globalsign.com/repository/ X509v3 CRL Distribution Points: Full Name: URI: http://crl.globalsign.net/root.crl Authority Information Access: OCSP-URI: http://ocsp.globalsign.com/rootr1 X509v3 Authority Key Identifier: keyid:60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC: FD:4B Signature Algorithm: sha256WithRSAEncryption 46:2a:ee:5e:bd:ae:01:60:37:31:11:86:71:74:b6:46:49:c8:...

3-3) Root certificate

The following is an example of a self-signed root certificate for a certificate authority. Issuer (issuer field) and Subject (subject, consumer field) are the same and can use their own public key to verify the signature, and the verification of the trust chain must end here. If the verifier has this root certificate in its trust store, the final entity certificate used in the TLS connection can be considered trusted. Otherwise, the final entity certificate is considered untrusted.

Certificate: Data: Version: 3 (0x2) Serial Number: 04:00:00:00:00:01:15:4b:5a:c3:94 Signature Algorithm: sha1WithRSAEncryption Issuer: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA Validity Not Before: Sep 1 12:00:00 1998 GMT Not After: Jan 28 12:00:00 2028 GMT Subject: C=BE, O=GlobalSign nv-sa, OU=Root CA CN=GlobalSign Root CA Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:da:0e:e6:99:8d:ce:a3:e3:4f:8a:7e:fb:f1:8b:... Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Certificate Sign CRL Sign X509v3 Basic Constraints: critical CA:TRUE X509v3 Subject Key Identifier: 60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B Signature Algorithm: sha1WithRSAEncryption d6:73:e7:7c:4f:76:d0:8d:bf:ec:ba:a2:be:34:c5:28:32:b5:4) Security

Bruce Schneier,Peter Gutmann and other security experts have published many publications on PKI issues.

4-1) Architectural defects

Blacklist invalid certificates (using CRL and OCSP).

One of the charms of PKI is the offline function, but if the client only uses CRL to judge the validity of the certificate, there will be misjudgment when the client is offline, because when CRL is not available, most clients will trust the certificate. The witness can disable CRL by cutting off the channel. Google's Adam Langley has said that CRL soft fault checking is like a seat belt that only works in the event of an accident.

● CRL is not a good choice because of its large size and complex distribution pattern.

● OCSP semantic ambiguity, lack of historical revocation state

● did not solve the problem of root certificate revocation

● aggregation issues: identity claims (authenticated by identifiers), attribute statements (submitting a package of audited attributes), and policy statements are combined in one container, which raises privacy, policy mapping, and maintenance issues.

● delegation issues: technically, CA cannot restrict subordinate CA from issuing certificates outside a limited namespace or property set; this feature of X.509 is not used. Therefore, there are a large number of CA on the Internet, and it is an impossible task to classify and strategy them. Authorization within an organization cannot be dealt with like general business practices.

● federated authentication problem: the certificate chain is the result of subordinate CA, bridged CA, and cross-signature, which makes verification complex and expensive in processing time, and path verification semantics may be ambiguous. A hierarchy with third-party trusted parties is the only model. If a bilateral trust relationship has been established, it will be very inconvenient.

Issuing extended Authentication (EV) certificates for hostnames does not prevent the issuance of lower authentication certificates for the same hostname, which means that higher EV authentication levels cannot resist man-in-the-middle attacks. Hit.

4-2) problems with certification authorities

If the subject rather than the relying party buys the certificate, the cheapest issuer is usually used. For cost reasons, the issuer often uses the extended authentication certificate to solve the problem, but in the view of security experts, the value of trust is declining.

The ● certification authority denies almost all warranties to the user, including the subject or relying party.

The ● validity period is considered sufficient to limit the key strength, and this parameter is abused by the certification authority to charge the client an extension fee. This places an unnecessary burden on users who use key scrolling. (I don't understand what it means)

● "users use an undefined authentication request protocol to obtain a certificate, which is issued in an ambiguous location in a directory that does not exist, so there is no effective means to revoke it."

Like all businesses, CA is governed by the law of its operating sites and may be forced to harm the interests of its customers and users. Intelligence agencies also used fake certificates issued through CA's extrajudicial compromises, such as DigiNotar, to carry out man-in-the-middle attacks. Hit. Another example is the withdrawal of the request by the Government of the Netherlands, CA, which gives new powers to the Dutch intelligence and security services as the new Dutch law entered into force on January 1, 2018.

4-3) implementation issues

There are design flaws, errors, different interpretations of standards, and interoperability problems with different standards in X.509 implementations, some of which are:

Many ● implementations turn off revocation checking:

The ● policy is seen as an obstacle and is not implemented

If ● opens it in all browsers (including code signatures) by default, it may damage the infrastructure

● DN is complex and difficult to understand (lack of standardization, internationalization issues... )

There are two representations for ● RFC822 names

● hardly supports name and policy constraints

● keyUsage is ignored, using the first certificate in the list

It is difficult to implement ● custom oid.

● should not set the property to be mandatory because it crashes the client

Unspecified attribute lengths in ● result in product-specific restrictions

There are implementation errors in ● X.509, such as allowing a string ending with a null value in a certificate or attacking through code injection. Click to forge the user name.

● fills sub-identifiers with 0x80 of object identifiers, implemented incorrectly or by using integer overflows of client browsers. The witness can include an unknown attribute in the CSR, which is signed by CA and mistakenly interpreted by the client as "CN" (OID = 2.5.4.3)

4-4) vulnerabilities in encryption

Digital signature system depends on the security of cryptographic hash function (hash function). If the public key infrastructure (PKI) uses hash functions that are no longer secure, attack. Witnesses can take advantage of weaknesses in the hash function to forge certificates. Specifically, if you attack. Witnesses can achieve a "hash collision". They can first persuade CA to sign the certificate with seemingly harmless content, but the hash and attack of that content. The witness creates another set of malicious certificates with the same hash content, and then attacks. An attacker can attach a signature provided by CA to his or her malicious certificate, resulting in a malicious certificate that "appears to be signed by CA". Due to malicious certificate content by attack. Witnesses are customized, so their valid dates or hostnames may be different from harmless certificates; malicious certificates can even contain the "CA:true" field, enabling them to issue other trusted certificates.

● MD2-based certificates have been used for a long time and are vulnerable to pre-image attacks. Hit. Because the root certificate already has a self-signed, attack. The witness can use this signature and use it as an intermediate certificate.

● in 2005, Arjen Lenstra and Benne de Weger demonstrated how to use hash collisions to construct two X.509 certificates that contain the same signature and differ only on the public key, through a collision attack on the MD5 hash function. Hit it.

● in 2008, Alexander Sotirov and Marc Stevens presented a practical attack on Chaos Communication Congress. Well, based on the fact that RapidSSL is still issuing MD5-based X.509 certificates, they have created a rogue certificate authority accepted by all ordinary browsers.

● in April 2009, at the European Cryptography Conference, Australian researchers at Macquarie University (Macquarie University) proposed "automatic differential path search SHA-1". The researchers were able to deduce a method that increases the probability of collision by several orders of magnitude.

● in February 2017, a team of researchers led by Marc Stevens created a SHA-1 collision that proved SHA-1 's weakness.

4-4-1) Mitigation measures for encryption vulnerabilities

The premise of using hash collision to forge X.509 signature is attack. The witness can predict the data that the certification authority will sign. This situation can be alleviated to some extent by generating a random factor (usually a serial number) in a certificate signed by CA. Since 2011, the CA / browser Forum has required serial number entropy in section 7.1 of its benchmark requirements.

Therefore, the serial number exists as a random source of interference, it is confidential and cannot be disclosed until the certificate is signed.

As of January 1, 2016, the baseline requirement forbids the use of SHA-1 to issue certificates. As of early 2017, Chrome and Firefox refused to use SHA-1 's certificate. As of May 2017, both Edge and Safari were rejecting SHA-1 certificates, and non-browser X.509 verifiers had not yet rejected SHA-1 certificates.

5) Overview of PKCS standard

In cryptography, PKCS stands for the Public key Cryptography Standard. This is a group of RSA Security Inc. The design and publication of public key cryptographic standards began in the early 1990s to promote the use of their patented cryptographic technologies, such as RSA algorithm, Schnorr signature algorithm and other algorithms. Although not industry standards (because the company retains control over them), in recent years some standards have begun to enter the "standards tracking" process of relevant standardization organizations such as IETF and PKIX working groups.

See RFC8017 for the ● PKCS#1 2.2 RSA encryption standard. The mathematical properties and formats of RSA public key and private key (ASN.1 encoded in clear text) are defined, as well as the basic algorithm and coding / filling scheme for performing RSA encryption, decryption and signature generation and verification.

● PKCS#2- has been withdrawn and is no longer valid since 2010, covering the encryption of message digests by RSA and then merged into PKCS#1.

● PKCS#3 1.4 Diffie-Hellman key agreement standard, an encryption protocol that allows parties who do not have prior knowledge of each other to jointly establish shared secret keys over insecure communication channels.

● PKCS#4- has been withdrawn since 2010, covering RSA key syntax, and then merged into PKCS#1.

● PKCS#5 2.1 is based on Password's encryption standard, see RFC 8018 and PBKDF2.

● PKCS#6 1.5 extends the certificate syntax standard, defining an extension to the old v1 X.509 certificate specification, which is eliminated by v3.

For the ● PKCS#7 1.5 encrypted message syntax standard, see RFC2315. Used to sign and / or encrypt messages under PKI. It is also used for certificate distribution (for example, as a response to PKCS#10 messages), forming the basis for S / MIME, which was established in 2010 based on RFC 5652, an updated encrypted message syntax standard (CMS), and is commonly used for single sign-on.

For the syntax standard for ● PKCS#8 1.2 private key information, see RFC5958. Used to carry private key certificate key pairs (encrypted or unencrypted).

● PKCS#9 2.0 selected attribute type [, see RFC2985. Defines the selected attribute type for use in PKCS#6 extension certificates, PKCS#7 digital signature messages, PKCS#8 private key information, and PKCS#10 certificate signing requests.

● PKCS#10 1.7 Certification request Standard, see RFC2986. For a message format sent to a certification authority to request a public key certificate, see Certificate signing request.

● PKCS#11 2.40 password token interface, also known as "Cryptoki". Define the API of the password token generic interface (see also the hardware security module). Commonly used in single sign-on, public key encryption and disk encryption [10] systems. RSA Security has handed over further development of the PKCS#11 standard to the OASIS PKCS 11 Technical Committee.

For the syntax standard for ● PKCS#12 1.1 personal information exchange, see RFC7292. Define a file format, personal information exchange syntax standard [11] see RFC 7292. Defines a file format that is typically used to store private keys and accompanying public key certificates and protected with Password-based symmetric keys. PFX is the predecessor of PKCS#12.

This container format can contain multiple embedded objects, such as multiple certificates. It is usually protected / encrypted with a password. Can be used as a format for Java key stores and establish client authentication certificates in Mozilla Firefox for Apache Tomcat to use.

In a nutshell, PKCS#12 can contain either a certificate (public key) or a password-protected private key

● PKCS#13 Elliptic Curve Cryptography Technical Standard (obsolete, the only reference is the proposal of 1998)

● PKCS#14 pseudorandom number generation (obsolete, no documentation)

● PKCS#15 1.1 encrypted token information format standard, which defines a standard that allows users of encrypted tokens to identify themselves to the application, regardless of the application's Cryptoki implementation (PKCS#11) or other API. RSA abandoned the IC card-related part of the standard and changed it to ISO / IEC 7816-15.

6) OpenSSL Certificate Authority

This guide demonstrates how to use the OpenSSL command line tool to act as your own certification authority (CA). This is useful in many cases, such as issuing a server certificate to protect an intranet Web site, or issuing a certificate to a client to allow the client to authenticate to the server.

6-1) introduction

OpenSSL is a free open source encryption library that provides command-line tools for dealing with digital certificates, some of which (that is, commands) can act as certificate authorities.

A certification authority is an entity that signs digital certificates. Many websites need to let their customers know that the connection is secure, so they pay a fee to the International Certification Authority (CA) to sign certificates for their domains.

In some cases, it makes more sense to do your own CA (rather than paying a CA like DigiCert), such as securing an intranet site or issuing a certificate to the client to allow the client to authenticate to the server.

6-2) create a root pair

Acting as a certificate authority means dealing with private keys and public key certificates in a key pair.

The first key pair we are going to create is the root pair. This includes the root key (ca.key.pem) and the root certificate (ca.cert.pem). This "root pair" constitutes your CA identity.

Typically, the root CA does not directly sign the server or client certificate, the root CA is only used to create one or more intermediate CA that are trusted by the root CA and sign the certificate on behalf of the root CA, which is a best practice, which allows the root key to remain offline and to minimize the number of times it is used, because any threat to the root is catastrophic.

Note:

The best practice is to create root pairs in a secure environment. Ideally, the computer should be completely encrypted and air-isolated (meaning a machine without any network interface, that is, it cannot be connected through an external network), consider uninstalling the wireless card and filling the Ethernet port with glue.

6-2-1) prepare the catalog

Mkdir / root/ca creates the directory structure. The index.txt and serial files act as flat file databases to track signed certificates. Cd / root/camkdir certs crl newcerts privatechmod 700 privatetouch index.txtecho 1000 > serial6-2-2) prepare the configuration file

You must create a configuration file for use by OpenSSL.

Copy the root CA configuration file from Appendix to / root/CA/openssl.cnf, where the [ca] section is required, and tell OpenSSL to use the options in the [CA_default] section.

[ca] default_ca = CA_defaulthe [CA_default] section contains a range of defaults. The Make sure you declare the directory you chose earlier (/ root/ca). [CA_default] section contains a series of default values The value of the dir field must be selected just now. / root/ca: [CA_defalut] # directory and file location dir = / root/cacerts = $dir/certscrl_dir = $dir/crlnew_certs_dir = $dir/newcertsdatabase = $dir/index.txtserial = $dir/serialRANDFILE = $dir/private/.rand # Root key and root certificate private_key = $dir/private/ca.key.pemcertificate = $dir/certs/ca.cert.pem # Certificate revocation List crlnumber = $dir/crlnumbercrl = $dir/crl/ca.crl.pemcrl_extension = crl_extdefault_crl_days = 30 # HA-1 deprecated So use SHA-2defualt_md = sha256 name_opt = ca_defaultcert_opt = ca_defaultdefault_days = 375preserve = nopolicy = plicy_strict instead we will apply policy_strict to all root CA signatures, because the root CA is only used to create an intermediate CA. [policy_strict] # Root CA only signs matching intermediate certificates # see the policy format section of "man ca". CountryName = matchstateOrProvinceName = matchorganizationName = matchorganizationalUnitName = optionalcommonName = suppliedemailAddress = optional if the value is "match", it means that the value of this field in the request file must be exactly the same as the corresponding field of the CA certificate entered at the time of signature; if the value is "supplied", it must exist. If the value is "optional", it is optional (left blank); so we will apply policy_loose instead of policy_strict to all intermediate CA signatures, because the intermediate CA is signing server and client certificates that may come from various third parties. [policy_loose] # allow intermediate CA to sign more certificates # see the "Policy format" section of the `ca` manual page countryName = optionalstateOrProvinceName = optionallocalityName = optionalorganizationalUnitName = optionalcommonName = suppliedemailAddress = optional when creating a certificate or certificate signing request, the options in the [req] section will be applied. The option for the [req] # req tool ("man req") default_bits = 2048distinguished_name = utf8only # HA-1 has been deprecated, so use the extension to be added when SHA-2default_md = sha256 # uses the-x509 option instead. X509_extensions = v3_ca [req_distinguished_name] declares the information typically required in a certificate signing request, and you can choose to specify some default values. [req_distinguished_name] # see .SecretyName = Country Name (2 letter code) stateOrProvinceName = State or Province NamelocalityName = Locality Name0.organizationName = Organization NameorganizationalUnitName = Organizational Unit NamecommonName = Common NameemailAddress = Email Address # Optionally, specify some defaults.countryName_default = GBstateOrProvinceName_default = EnglandlocalityName_default = 0.organizationName_default = Alice Ltd#organizationalUnitName_default = # emailAddress_default = the following sections are extensions that can be applied when signing a certificate For example, the-extensions v3_ca command line argument applies the options set in [v3_ca]. We will apply the [v3_ca] extension when creating the root certificate: [v3_ca] # typical CA extension (`View x509v3_config manual `). SubjectKeyIdentifier = hashautorityKeyIdentifier = keyid:always,issuerbasicConstraints = critical, CA:truekeyUsage = critical, digitalSignature, cRLsign, keyCertSign We will apply v3_ca_intermediate extension (intermediate extension) when creating intermediate certificates Pathlen:0 guarantees that there can be no other certification authorities under the intermediate CA: [v3_intermediate_ca] # typical extension of intermediate CA (`View x509v3_config manual `). SubjectKeyIdentifier = hashauthorityKeyIdentifier = keyid:always,issuerbasicConstraints = critical, CA:true, pathlen:0keyUsage = critical, digitalSignature, cRLSign, keyCertSign We will sign server_cert (server certificate) For example, when applying the server certificate extension for web server certificates: [server_cert] # Extensions for server certificates (`View x509v3_config manual`) .basicConstraints = CA:FALSEnsCertType = servernsComment = "OpenSSL Generated Server Certificate" subjectKeyIdentifier = hashauthorityKeyIdentifier = keyid,issuer:alwayskeyUsage = critical, digitalSignature, keyEnciphermentextendedKeyUsage = serverAuth when creating a certificate revocation list The crl_ext extension: [crl_ext] # CRL extension (`View x509v3_config manual `). When authorityKeyIdentifier=keyid:always signs an online Certificate status Agreement (OCSP) certificate, we will use the ocsp extension: [ocsp] # OCSP signing certificate extension (`man ocsp`). BasicConstraints = CA:FALSEsubjectKeyIdentifier = hashauthorityKeyIdentifier = keyid,issuerkeyUsage = critical, digitalSignatureextendedKeyUsage = critical, OCSPSigning6-2-3) to create the root private key

Create a root private key (ca.key.pem) and ensure its absolute security, because anyone who owns the root private key can issue a "trusted certificate". It is recommended to use the AES 256algorithm and a complex strong password to encrypt the root private key.

Note: for security reasons, use the 4096-bit private key for all root CA and intermediate CA.

Cd / root/caopenssl genrsa-aes256-out private/ca.key.pem 4096 Enter pass phrase for ca.key.pem: secretpasswordVerifying-Enter pass phrase for ca.key.pem: secretpassword chmod 400 private/ca.key.pem6-2-4) create a root certificate

Use the root key (ca.key.pem) to create a root certificate (ca.cert.pem) that gives the root certificate a long validity period of, say, 20 years. After the root certificate expires, all certificates signed by the root CA will be invalid.

Warning: whenever you use the req tool, you must specify a configuration file to use with the-config option, otherwise OpenSSL will default to / etc/pki/tls/OpenSSL.cnf

Cd / root/caopenssl req-config openssl.cnf-key private/ca.key.pem-new-x509-days 7300-sha256-extensions v3_ca-out certs/ca.cert.pem Enter pass phrase for ca.key.pem: secretpasswordYou are about to be asked to enter information that will be incorporatedinto your certificate request.-Country Name (2 letter code) [XX]: GBState or Province Name []: EnglandLocality Name []: Organization Name []: Alice LtdOrganizational Unit Name []: Alice Ltd Certificate AuthorityCommon Name []: Alice Ltd Root CAEmail Address []: 6-2-5) verify the root certificate

Openssl x509-noout-text-in certs/ca.cert.pem

The output of this line of command includes:

Signature algorithm used by ●

Validity period of ● certificate

● public key bit length

● issuer, that is, the entity that signed the certificate

● principal, which refers to the certificate itself

Because the certificate is self-signed, the issuer and the subject are the same.

Note that all root certificates are self-signed.

Note: the following yellow Chinese characters are notes Not part of the certificate Signature Algorithm: signature algorithm used by sha256WithRSAEncryption # Issuer: C=GB, ST=England, O=Alice Ltd, OU=Alice Ltd Certificate Authority, CN=Alice Ltd Root CA # issuer Validity # Certificate validity Not Before: Apr 11 12:22:58 2015 GMT Not After: Apr 6 12:22:58 2035 GMT Subject: C=GB, ST=England, O=Alice Ltd, OU=Alice Ltd Certificate Authority CN=Alice Ltd Root CA # Principal Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) # Public key bit length 6-3) create an intermediate certificate key pair

Intermediate Certificate Authorization (CA) is an entity that can sign a certificate on behalf of the root CA, and the root CA signs an intermediate certificate, which forms a chain of trust.

The main purpose of using intermediate certificates is that the root key can be kept offline and used as infrequently as possible. If the intermediate key is compromised, the root CA can revoke the intermediate certificate and create a new intermediate key pair.

6-3-1) prepare the catalog

The root CA file is saved in / root/ca, and select a different directory (/ root/ca/intermediate) to store the intermediate CA file.

Cd / root/ca/intermediatemkdir certs crl csr newcerts privatechmod 700 privatetouch index.txtecho 1000 > serial adds the crlnumber file to the intermediate CA directory tree, and crlnumber is used to track the certificate revocation list: echo 1000 > / root/ca/intermediate/crlnumber copies the intermediate CA configuration file from Appendix to / root/CA/intermediate/openssl.cnf. Note that the following five options have changed compared to the root CA configuration file: [CA_default] dir = / root/ca/intermediateprivate_key = $dir/private/intermediate.key.pemcertificate = $dir/certs/intermediate.cert.pemcrl = $dir/crl/intermediate.crl.pempolicy = policy_loose

6-3-2) create an intermediate key

Create an intermediate key (intermediate.key.pem) and encrypt it using the AES 256algorithm and complex strong passwords.

# cd / root/ca# openssl genrsa-aes256-out intermediate/private/intermediate.key.pem 4096 Enter pass phrase for intermediate.key.pem: secretpasswordVerifying-Enter pass phrase for intermediate.key.pem: secretpassword # chmod 400 intermediate/private/intermediate.key.pem

6-3-3) create an intermediate certificate

Create a certificate signing request (CSR) with an intermediate certificate, and the details should usually be the same as the root CA. However, the Common Name (Certificate Holder Common name / FQDN) must be different:

Warning: make sure that the intermediate CA configuration file specified by the command line exists (intermediate/openssl.cnf).

# cd / root/ca# openssl req-config intermediate/openssl.cnf-new-sha256-key intermediate/private/intermediate.key.pem-out intermediate/csr/intermediate.csr.pem Enter pass phrase for intermediate.key.pem: secretpasswordYou are about to be asked to enter information that will be incorporatedinto your certificate request.-Country Name (2 letter code) [XX]: GBState or Province Name []: Organization Name []: Alice LtdOrganizational Unit Name []: Alice Ltd Certificate AuthorityCommon Name []: Alice Ltd Intermediate CAEmail Address []:

To create an intermediate certificate, use the root CA with the v3_intermediate_CA extension to sign the intermediate CSR. The period of validity of the intermediate certificate should be shorter than that of the root certificate. Ten years is reasonable.

Warning: specify the root CA configuration file / root/ca/openssl.cnf.

# cd / root/ca# openssl ca-config openssl.cnf-extensions v3_intermediate_ca-days 3650-notext-md sha256-in intermediate/csr/intermediate.csr.pem-out intermediate/certs/intermediate.cert.pemEnter pass phrase for ca.key.pem: secretpasswordSign the certificate? [yplan]: the y# chmod 444 intermediate/certs/intermediate.cert.pemindex.txt file is the location where the OpenSSL CA tool stores the certificate database. Do not delete or edit this file manually. It should now contain the intermediate certificate you just created: v 250408122707Z 1000 unknown. / CN=Alice Ltd Intermediate CA

6-3-4) verify the intermediate certificate

As we did for the root certificate, check that the details of the intermediate certificate are correct:

# openssl x509-noout-text-in intermediate/certs/intermediate.cert.pem

Intermediate.cert.pem: OK

6-3-5) create a certificate chain file

When an application, such as a web browser, attempts to verify a certificate signed by an intermediate CA, it must verify the intermediate certificate against the root certificate. To complete the trust chain, create a CA certificate chain to present to the application.

To create a CA certificate chain, connect the intermediate certificate to the root certificate, which we will use later to verify the certificate signed by the intermediate CA.

# cat intermediate/certs/intermediate.cert.pem certs/ca.cert.pem > intermediate/certs/ca-chain.cert.pem# chmod 444 intermediate/certs/ca-chain.cert.pem

Note: the certificate chain file must contain the root certificate because it needs to be found by the client application. A better option, especially in the case of managing Intranet, is to install the root certificate on each client that needs to connect, in which case the certificate chain file needs to contain only your intermediate certificate.

6-4) sign server and client certificates

We will use the intermediate CA to sign the certificate. You can use these certificates in a variety of situations, such as securing connections to the Web server or authenticating clients connected to the server.

Note: the following step is for CA to create a private key and signature request (CSR) for the applicant, but for security reasons, the applicant can also create his own private key and request, in which the private key is properly stored locally, and give the CSR to CA,CA and give it a signed certificate. In this case, skip the genrsa and req commands.

6-4-1) create a private key

Our root key pair and intermediate key pair are 4096 bits, and server and client certificates usually expire after a year, so we can safely use 2048 bits.

Note: although 4096 bits are more secure than 2048 bits it slows down the TLS handshake and significantly increases the processor load during the handshake. As a result, most websites use 2048-bit key pairs.

Translator's note: 2048 is no longer safe, it is recommended to use 4096 or 8192.

If you want to create a key pair for a network server, you need to enter a protection password every time you restart the server, and if it's troublesome, you don't have to use the-aes256 option to create a private key without a password.

# cd / root/ca# openssl genrsa-aes256-out intermediate/private/www.example.com.key.pem 204 chmod 400 intermediate/private/www.example.com.key.pem

6-4-2) create a certificate

Create a certificate signing request (CSR) with the private key, and the details of the CSR do not need to match the intermediate CA. For a server certificate, the Common Name (common name) must be FQDN (a fully qualified domain name, for example, www.example.com), while for a client certificate, Common Name can be any unique identifier (such as an email address). Note that the Common Name of the client certificate is different from the Common Name of the root certificate or intermediate certificate.

# cd / root/ca#openssl req-config intermediate/openssl.cnf-key intermediate/private/www.example.com.key.pem-new-sha256-out intermediate/csr/www.example.com.csr.pem Enter pass phrase for www.example.com.key.pem: secretpasswordYou are about to be asked to enter information that will be incorporatedinto your certificate request.-Country Name (2 letter code) [XX]: USState or Province Name []: CaliforniaLocality Name []: Mountain ViewOrganization Name []: Alice LtdOrganizational Unit Name []: Alice Ltd Web ServicesCommon Name []: www.example.comEmail Address []:

To create a certificate, use the intermediate CA to sign the CSR. Use the server_cert extension if you want to use the certificate on the server, or the usr_cert extension if the certificate will be used for user authentication. Certificates are usually valid for one year, but for convenience, CA usually gives you a few more days.

# cd / root/ca#openssl ca-config intermediate/openssl.cnf-extensions server_cert-days 375-notext-md sha256-in intermediate/csr/www.example.com.csr.pem-out intermediate/certs/www.example.com.cert.pem# chmod 444intermediate/certs/www.example.com.cert.pem intermediate/index.txt should appear the line containing the certificate: v 160420124233Z 1000 unknown... / CN=www.example.com

6-4-3) verify the certificate

# openssl x509-noout-text-in intermediate/certs/www.example.com.cert.pem

Issuer (issuer) is the intermediate CA Subject (subject) refers to the certificate itself: Signature Algorithm: sha256WithRSAEncryption Issuer: C=GB, ST=England,O=Alice Ltd, OU=Alice Ltd Certificate Authority,CN=Alice Ltd Intermediate CA Validity Not Before: Apr 11 12:42:33 2015 GMT Not After: Apr 20 12:42:33 2016 GMT Subject: C=US, ST=California, L=Mountain View,O=Alice Ltd, OU=Alice Ltd Web Services,CN=www.example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) the output will also show X509v3 extensions. When creating the certificate, you used the server_cert or usr_cert extension The options in the corresponding configuration section will be reflected in the output: X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Server Netscape Comment: OpenSSL Generated Server Certificate X509v3 Subject Key Identifier: B1:B8:88:48:64:B7:45:52:21:CC:35:37:9E:24:50:EE:AD:58:02:B5 X509v3 Authority Key Identifier: keyid:69: E8:EC:54:7F:25:23:60:E5:B6:E7:72:61:F1:D4:B9:21:D4:45:E9 DirName:/C=GB/ST=England/O=Alice Ltd/OU=Alice Ltd Certificate Authority/CN=Alice Ltd Root CA serial:10:00 X509v3 Key Usage: critical Digital Signature Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication uses the CA certificate chain file (ca-chain.cert.pem) we created earlier to verify that the new certificate has a valid trust chain. # openssl verify-CAfile intermediate/certs/ca-chain.cert.pem intermediate/certs/www.example.com.cert.pem www.example.com.cert.pem: OK

6-4-4) deployment certificate

You can now deploy the new certificate to the server or distribute the certificate to the client. When deploying to a server application, such as Apache, ensure that the following files are available:

Ca-chain.cert.com

Www.example.com.key.pem

Www.example.com.cert.pem

If you obtained CSR from a third party, you don't need to use its private key, so just send the certificate chain file (ca-chain.cert.pem) and certificate (www.example.com.cert.pem) back to them.

6-5) Certificate revocation list

The certificate revocation list (CRL, see RFC5280) provides a list of revoked certificates. Client applications, such as Web browsers, can use CRL to check the authenticity of the server. Server applications, such as Apache or OpenV.P.N, can use CRL to deny access to clients that are no longer trusted.

Publish a CRL in a publicly accessible location, such as http://example.com/intermediate.crl.pem, from which third parties can obtain the CRL to check whether the certificate they rely on has been revoked.

Note: some application vendors have abandoned CRL and instead used the online Certificate status Protocol (OCSP, Baidu RFC2560, available in Chinese).

6-5-1) prepare the configuration file

When signing a certificate, the certification authority usually encodes the CRL location into the certificate, adding crlDistributionPoints to the appropriate section, and in this case, to the [server_cert] section.

[server_cert]

#... Snipped...

CrlDistributionPoints = URI: http://example.com/intermediate.crl.pem

6-5-2) create CRL

# cd / root/ca

# openssl ca-config intermediate/openssl.cnf-gencrl-out intermediate/crl/intermediate.crl.pem

Note: the CRL OPTIONS section of the ca man page contains more information about how to create a CRL.

You can use the crl tool to check the contents of CRL:

Openssl crl-in intermediate/crl/intermediate.crl.pem-noout-text

No certificates have been revoked, so the output will display "No revocation Certificate"

You should recreate the CRL periodically. By default, CRL expires after 30 days. This is controlled by the default_crl_days option in the [CA_default] section.

6-5-3) revocation of certificate

Let's look at an example. Alice is running an Apache server and has a private folder with pictures of cute kittens on it. Alice wants to grant her friend Bob access to the collection.

① Bob creates a private key and certificate signing request (CSR):

Cd / home/bobopenssl genrsa-out bob@example.com.key.pem 2048openssl req-new-key bob@example.com.key.pem-out bob@example.com.csr.pem You are about to be asked to enter information that will be incorporatedinto your certificate request.-Country Name [XX]: USState or Province Name []: CaliforniaLocality Name []: Bob LtdOrganizational Unit Name []: Common Name []: bob@example.comEmail Address []:

② Bob sends her CSR to Alice, who then signs it:

Cd / root/caopenssl ca-config intermediate/openssl.cnf-extension usr_cert-notext-md sha256-in intermediate/csr/bob@example.com.csr.pem-out intermediate/certs/bob@example.com.cert.pem

③ Alice verifies that the certificate is valid:

Openssl verify-CAfile intermediate/certs/ca-chain.cert.pem intermediate/certs/bob@example.com.cert.pem bob@example.com.cert.pem: OK

The index.txt file should now contain a new entry:

V 160420124740Z 1001 unknown... / CN=bob@example.com

Alice sends a signed certificate to Bob, and Bob installs the certificate in his web browser. Now you can access Alice's kitten picture. Cheer!

④ sadly, Bob turned out to be misbehaving. Bob posted a picture of Alice's kitten on the * News, claiming to be his own photo and was very popular. Alice found out and needed to revoke his access right immediately:

Cd / root/caopenssl ca-config intermediate/openssl.cnf-revoke intermediate/certs/bob@example.com.cert.pem Enter pass phrase for intermediate.key.pem: secretpasswordRevoking Certificate 1001.Data Base Updated

Now the line corresponding to Bob's certificate in index.txt begins with the character R, which indicates that the certificate has been revoked:

R 160420124740Z 150411125310Z 1001 unknown... / CN=bob@example.com

After revoking Bob's certificate, Alice must recreate the CRL.

6-5-4) use CRL on the server side

For client-side certificates, it is usually a server-side application, such as Apache, that validates. This application requires local access to CRL.

For Alice, she can add the SSLCARevocationPath directive to the Apache configuration, then copy the CRL to her Web server, and the next time Bob connects to the Web server, Apache will check its client certificate and deny access against CRL.

Similarly, OpenV.P.N has a crl-verfiy directive, so it can prevent clients whose certificates have been revoked.

6-5-5) CRL is used for client server

For server certificates, it is usually verified by a server-side application (such as a web browser). The Web browser should be a client program. This application must have delete access to CRL.

If the certificate is signed with an extension that contains crlDistributionPoints, the client application can read this information and obtain the CRL from the specified location.

The CRL distribution point is visible in the certificate X509v3 details.

Opnessl x509-in cute-kitten-pictures.example.com.cert.pem-noout-textX509v3 CRL Distribution Points: Full Name: URI: http://example.com/intermediate.crl.pem

6-6) online Certificate status Protocol OCSP

Baidu RFC2560 has a Chinese version.

The online Certificate status Protocol (OCSP) is an alternative to Certificate revocation list (CRL). Similar to CRL, OCSP allows a requestor, such as a web browser, to determine the revocation status of a certificate.

When CA signs a certificate, they usually include the OCSP server address in the certificate. This is functionally similar to crlDistributionPoints for CRL.

For example, when the server provides a certificate to the web browser, the browser sends a query to the OCSP server address specified in the certificate, where the OCSP responder listens for the query and responds with the revocation status of the certificate.

Note: it is recommended to use OCSP where possible. In fact, you only need OCSP to obtain the website certificate, because some web browsers no longer support CRL.

6-6-1) prepare the configuration file

To use OCSP,CA, you must encode the OCSP server location into the certificate it signed. Use the authorityInfoAccess option in the appropriate section, in this case the [server_cert] section.

[server_cert]

#... Snipped...

AuthorityInfoAccess = OCSP;URI: http://ocsp.example.com

6-6-2) create an OCSP key pair

The OCSP responder needs a key pair to sign the response sent back to the requester. The OCSP key pair must be signed by the same CA of the certificate currently being checked.

Create a private key and encrypt it with AES-256:

# cd / root/ca# openssl genrsa-aes256-out intermediate/private/ocsp.example.com.key.pem 4096

Create a certificate signing request (CSR), and the details should usually match the details of the signing CA. However, the public name must be a fully qualified domain name:

# cd / root/ca# openssl req-config intermediate/openssl.cnf-new-sha256-key intermediate/private/ocsp.example.com.key.pem-out intermediate/csr/ocsp.example.com.csr.pem Enter pass phrase for intermediate.key.pem: secretpasswordYou are about to be asked to enter information that will be incorporatedinto your certificate request.-Country Name (2 letter code) [XX]: GBState or Province Name []: EnglandLocality Name []: Organization Name []: Alice LtdOrganizational Unit Name []: Alice Ltd Certificate AuthorityCommon Name []: ocsp.example.comEmail Address []: use intermediate CA to sign CSR:# openssl ca-config intermediate/openssl.cnf-extensions ocsp-days 375-notext-md sha256-in intermediate/csr/ocsp.example.com.csr.pem-out intermediate/certs/ocsp.example.com.cert.pem to verify that the certificate has the correct X509v3 extension: # openssl x509-noout-text\-in intermediate/certs/ocsp.example.com.cert.pem X509v3 Key Usage: Critical Digital Signature X509v3 Extended Key Usage: critical OCSP Signing

6-6-3) revocation of certificate

The OpenSSL ocsp tool can act as an OCSP responder, but only for testing. There are OCSP responders available for production, but these responses are beyond the scope of this guide.

Create a server certificate to test:

# cd / root/ca# openssl genrsa-out intermediate/private/test.example.com.key.pem 204 openssl req-config intermediate/openssl.cnf-key intermediate/private/test.example.com.key.pem-new-sha256-out intermediate/csr/test.example.com.csr.pem# openssl ca-config intermediate/openssl.cnf-extensions server_cert-days 375-notext-md sha256-in intermediate/csr/test.example.com.csr.pem-out intermediate/certs/test.example.com.cert.pem

Run the OCSP responder on the local host. Instead of storing the revocation status in a separate CRL file, the OCSP responder reads the index.txt directly. The response is signed with the OCSP private key pair (using the-rkey and-rsigner options):

Openssl ocsp-port 127.0.0.1 text-sha256-index intermediate/index.txt-CA intermediate/certs/ca-chain.cert.pem-rkey intermediate/private/ocsp.example.com.key.pem-rsigner intermediate/certs/ocsp.example.com.cert.pem-nrequest 1

Another terminal sends a query to the OCSP responder. The-cert option specifies the certificate to query:

# openssl ocsp-CAfile intermediate/certs/ca-chain.cert.pem-url http://127.0.0.1:2560-resp_text-issuer intermediate/certs/intermediate.cert.pem-cert intermediate/certs/test.example.com.cert.pem

The beginning of the output shows:

Whether ● received a successful response (OCSP response status: OCSP Response Status)

● followed by the identity of the responder (transponder ID:Responder Id)

Revocation status of ● certificate (certificate status: Cert Status)

OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id:... CN = ocsp.example.com Produced At: Apr 11 12:59:51 2015 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: E35979B6D0A973EBE8AEDED75D8C27D67D2A0334 Issuer Key Hash: 69E8EC547F252360E5B6E77261F1D4B921D445E9 Serial Number: 1003 Cert Status: good This Update: Apr 11 12:59:51 2015 GMT

Revoke the certificate:

# openssl ca-config intermediate/openssl.cnf-revoke intermediate/certs/test.example.com.cert.pem Enter pass phrase for intermediate.key.pem: secretpasswordRevoking Certificate 1003.Data Base Updated

As mentioned earlier, the native runs the OCSP response program, and the other terminal sends the query. This output shows that the certificate status has changed: revoked and revoked time:

OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id:... CN = ocsp.example.com Produced At: Apr 11 13:03:00 2015 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: E35979B6D0A973EBE8AEDED75D8C27D67D2A0334 Issuer Key Hash: 69E8EC547F252360E5B6E77261F1D4B921D445E9 Serial Number: 1003 Cert Status: revoked Revocation Time: Apr 11 13:01:09 2015 GMT This Update: Apr 11 13:03:00 2015 GMT

6-7) Appendix

6-7-1) Root CA profile # OpenSSL root CA profile. # Copy to `/ root/ca/ openssl.cnf`. [ca] # `man ca`default _ ca = CA_default [CA_default] # directory and file location. Dir = / root/cacerts = $dir/certscrl_dir = $dir/crlnew_certs_dir = $dir/newcertsdatabase = $dir/index.txtserial = $dir/serialRANDFILE = $dir/private/.rand # root private key and root certificate. Private_key = $dir/private/ca.key.pemcertificate = $dir/certs/ca.cert.pem # is used for certificate revocation lists. Crlnumber = $dir/crlnumbercrl = $dir/crl/ca.crl.pemcrl_extensions = crl_extdefault_crl_days = 30 # SHA-1 is not recommended, so use SHA-2 instead. Default_md = sha256name_opt = ca_defaultcert_opt = ca_defaultdefault_days = 375preserve = nopolicy = policy_strict [policy_strict] # Root CA only signs the intermediate certificate of match (matching). # Please see the POLICY FORMAT section of `man ca`. CountryName = matchstateOrProvinceName = matchorganizationName = matchorganizationalUnitName = optionalcommonName = suppliedemailAddress = optional [policy_loose] # allows intermediate CA to sign more kinds of certificates. # Please refer to the "Policy format" section of the ca manual page. CountryName = optionalstateOrProvinceName = optionallocalityName = optionalorganizationName = optionalorganizationalUnitName = optionalcommonName = suppliedemailAddress = optional [req] # `req` tool option (`req`). Default_bits = 2048distinguished_name = req_distinguished_namestring_mask = utf8only # SHA-1 is not recommended, please use SHA-2 instead. Default_md = sha256 # the extension to add when using the-x509 option. X509_extensions = v3_ca [req_distinguished_name] # See. NormalyName = Country Name (2 letter code) stateOrProvinceName = State or Province NamelocalityName = Locality Name0.organizationName = Organization NameorganizationalUnitName = Common NameemailAddress = Email Address # specify some default values (optional). CountryName_default = GBstateOrProvinceName_default = EnglandlocalityName_default = 0.organizationName_default = Alice LtdorganizationalUnitName_default = emailAddress_default = [v3_ca] # extension of a typical CA (`man x509v3config`). SubjectKeyIdentifier = hashauthorityKeyIdentifier = keyid:always,issuerbasicConstraints = critical, CA:truekeyUsage = critical, digitalSignature, cRLSign, keyCertSign [v3_intermediate_ca] # extension of typical intermediate CA (`man x509v3 _ config`). SubjectKeyIdentifier = hashauthorityKeyIdentifier = keyid:always,issuerbasicConstraints = critical, CA:true, pathlen:0keyUsage = critical, digitalSignature, cRLSign, keyCertSign [usr_cert] # extension of client certificate (`man x509v3 _ config`). BasicConstraints = CA:FALSEnsCertType = client, emailnsComment = "OpenSSL Generated Client Certificate" subjectKeyIdentifier = hashauthorityKeyIdentifier = keyid,issuerkeyUsage = critical, nonRepudiation, digitalSignature, keyEnciphermentextendedKeyUsage = clientAuth, emailProtection [server_cert] # extensions to the server certificate (`man x509v3 _ config`). BasicConstraints = CA:FALSEnsCertType = servernsComment = "OpenSSL Generated Server Certificate" subjectKeyIdentifier = hashauthorityKeyIdentifier = keyid,issuer:alwayskeyUsage = critical, digitalSignature KeyEnciphermentextendedKeyUsage = serverAuth [crl_ext] # CRL extension (`man x509v3 _ config`). AuthorityKeyIdentifier=keyid:always [ocsp] # extension to the OCSP signing certificate (`man ocsp`). BasicConstraints = CA:FALSEsubjectKeyIdentifier = hashauthorityKeyIdentifier = keyid,issuerkeyUsage = critical, digitalSignatureextendedKeyUsage = critical, OCSPSigning6-7-2) Intermediate CA configuration File

# OpenSSL intermediate CA configuration file. # Copy to `/ root/ca/intermediate/ openssl.cnf`. [ca] # `man ca`default _ ca = CA_default [CA_default] # directory and file location. Dir = / root/ca/intermediatecerts = $dir/certscrl_dir = $dir/crlnew_certs_dir = $dir/newcertsdatabase = $dir/index.txtserial = $dir/serialRANDFILE = $dir/private/.rand # root private key and root certificate. Private_key = $dir/private/intermediate.key.pemcertificate = $dir/certs/intermediate.cert.pem # is used for certificate revocation lists. Crlnumber = $dir/crlnumbercrl = $dir/crl/intermediate.crl.pemcrl_extensions = crl_extdefault_crl_days = 30 # SHA-1 is not recommended, please use SHA-2 instead. Default_md = sha256name_opt = ca_defaultcert_opt = ca_defaultdefault_days = 375preserve = nopolicy = policy_loose [policy_strict] # Root CA only signs the intermediate certificate of match (matching). # Please see the POLICY FORMAT section of `man ca`. CountryName = matchstateOrProvinceName = matchorganizationName = matchorganizationalUnitName = optionalcommonName = suppliedemailAddress = optional [policy_loose] # allows intermediate CA to sign more kinds of certificates. # Please refer to the "Policy format" section of the ca manual page. CountryName = optionalstateOrProvinceName = optionallocalityName = optionalorganizationName = optionalorganizationalUnitName = optionalcommonName = suppliedemailAddress = optional [req] # `req` tool option (`req`). Default_bits = 2048distinguished_name = req_distinguished_namestring_mask = utf8only # SHA-1 is not recommended, please use SHA-2 instead. Default_md = sha256 # the extension to add when using the-x509 option. X509_extensions = v3_ca [req_distinguished_name] # See. NormalyName = Country Name (2 letter code) stateOrProvinceName = State or Province NamelocalityName = Locality Name0.organizationName = Organization NameorganizationalUnitName = Common NameemailAddress = Email Address # specify some default values (optional). CountryName_default = GBstateOrProvinceName_default = EnglandlocalityName_default = 0.organizationName_default = Alice LtdorganizationalUnitName_default = emailAddress_default = [v3_ca] # extension of a typical CA (`man x509v3config`). SubjectKeyIdentifier = hashauthorityKeyIdentifier = keyid:always,issuerbasicConstraints = critical, CA:truekeyUsage = critical, digitalSignature, cRLSign, keyCertSign [v3_intermediate_ca] # extension of typical intermediate CA (`man x509v3 _ config`). SubjectKeyIdentifier = hashauthorityKeyIdentifier = keyid:always,issuerbasicConstraints = critical, CA:true, pathlen:0keyUsage = critical, digitalSignature, cRLSign, keyCertSign [usr_cert] # extension of client certificate (`man x509v3 _ config`). BasicConstraints = CA:FALSEnsCertType = client, emailnsComment = "OpenSSL Generated Client Certificate" subjectKeyIdentifier = hashauthorityKeyIdentifier = keyid,issuerkeyUsage = critical, nonRepudiation, digitalSignature, keyEnciphermentextendedKeyUsage = clientAuth, emailProtection [server_cert] # extension of server certificate (`man x509v3 _ config`). BasicConstraints = CA:FALSEnsCertType = servernsComment = "OpenSSL Generated Server Certificate" subjectKeyIdentifier = hashauthorityKeyIdentifier = keyid,issuer:alwayskeyUsage = critical, digitalSignature, keyEnciphermentextendedKeyUsage = serverAuth [crl_ext] # CRL extension (`man x509v3config`). Extension of authorityKeyIdentifier=keyid:always [ocsp] # OCSP signing certificate (`man ocsp`) basicConstraints = CA:FALSEsubjectKeyIdentifier = hashauthorityKeyIdentifier = keyid,issuerkeyUsage = critical, digitalSignatureextendedKeyUsage = critical, OCSPSigning

After reading the above, do you have any further understanding of the X.509 certificate? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel. Thank you for reading.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.