一声令下表达,过期的证书

2019-05-03 22:42 来源:未知

须求:验证过期的证书在系统中不可能运用。

Using OpenSSL Utilities

自然整理了1份实践脚本,不过尚未找到附属类小部件功能。只可以平素贴当时和煦看过的链接了。

标题:怎么样生成过期的证件吗?


小说标题:Openssl Certificate Authority

消除措施:1.调动系统时间

An openssl command line takes the following form:

openssl utility arguments 

For example:

openssl x509 -in OrbixCA -text 

Each command is individually described in this appendix. To get a list of the arguments associated with a particular command, use the -help option as follows:

openssl utility -help 

For example:

openssl x509 -help 

转发链接:

                  二.生成证书

The x509 Utility

In Orbix 2000 SSL/TLS the x509 utility is mainly used for:

  • Printing text details of certificates you wish to examine.

  • Converting certificates to different formats.

The options supported by the openssl x509 utility are as follows:

-inform arg

- input format - default PEM
(one of DER, NET or PEM)

-outform arg

- output format - default PEM
(one of DER, NET or PEM

-keyform arg

- private key format - default PEM

-CAform arg

- CA format - default PEM

-CAkeyform arg

- CA key format - default PEM

-in arg

- input file - default stdin

-out arg

- output file - default stdout

-serial

- print serial number value

-hash

- print serial number value

-subject

- print subject DN

-issuer

- print issuer DN

-startdate

- notBefore field

-enddate

- notAfter field

-dates

- both Before and After dates

-modulus

- print the RSA key modulus

-fingerprint

- print the certificate fingerprint

-noout

- no certificate output

-days arg

- How long till expiry of a signed certificate
- def 30 days

-signkey arg

- self sign cert with arg

-x509toreq

- output a certification request object

-req

- input is a certificate request, sign and output

-CA arg

- set the CA certificate, must be PEM format

-CAkey arg

- set the CA key, must be PEM format. If missing it is assumed to be in the CA file

-CAcreateserial

- create serial number file if it does not exist

-CAserial

- serial file

-text

- print the certificate in text form

-C

- print out C code forms

-md2/-md5/-sha1/
-mdc2

- digest to do an RSA sign with

 

Using the x509 Utility

To print the text details of an existing PEM-format X.509 certificate, use the x509 utility as follows:

openssl x509 -in MyCert.pem -inform PEM -text 

To print the text details of an existing DER-format X.509 certificate, use the x509 utility as follows:

openssl x509 -in MyCert.der -inform DER -text 

To change a certificate from PEM format to DER format, use the x509 utility as follows:

openssl x509 -in MyCert.pem -inform PEM -outform DER -out MyCert.der 

亟需注意:

                  三.认证证书startdate 和 enddate 是还是不是合乎您的意料

The req Utility

The req utility is used to generate a self-signed certificate or a certificate signing request (CSR). A CSR contains details of a certificate to be issued by a CA. When creating a CSR, the req command prompts you for the necessary information from which a certificate request file and an encrypted private key file are produced. The certificate request is then submitted to a CA for signing.

If the -nodes (no DES) parameter is not supplied to req, you are prompted for a pass phrase which will be used to protect the private key.

Note:
It is important to specify a validity period (using the -days parameter). If the certificate expires, applications that are using that certificate will not be authenticated successfully.

The options supported by the openssl req utility are as follows:

-inform arg 

input format - one of DER TXT PEM

-outform 
arg output format - one of DER TXT PEM 
-in arg 
inout file 
-out arg 
output file 

-text

text form of request

-noout 
do not output REQ 
-verify 
verify signature on REQ 
-modulus 
RSA modulus 

-nodes

do not encrypt the output key

-key file

use the private key contained in file 

-keyform arg

key file format 

-keyout arg

file to send the key to

-newkey rsa:bits

generate a new RSA key of `bits' in size 

-newkey dsa:file

generate a new DSA key, parameters taken from CA in `file'

-[digest]

Digest to sign with (md5, sha1, md2, mdc2) 

-config file

request template file

-new

new request

-x509

output an x509 structure instead of a certificate req. (Used for creating self signed certificates)

-days

number of days an x509 generated by -x509 is valid for

-asn1-kludge

Output the `request' in a format that is wrong but some CA's have been reported as requiring [It is now always turned on but can be turned off with -no-asn1-kludge] 

 

Using the req Utility

To create a self-signed certificate with an expiry date a year from now, the req utility can be used as follows to create the certificate CA_cert.pem and the corresponding encrypted private key file CA_pk.pem:

openssl req -config ssl_conf_path_name -days 365  
-out CA_cert.pem -new -x509 -keyout CA_pk.pem 

This following command creates the certificate request MyReq.pem and the corresponding encrypted private key file MyEncryptedKey.pem:

openssl req -config ssl_conf_path_name -days 365 
-out MyReq.pem -new -keyout MyEncryptedKey.pem 

一)serial和crlnumber文件必须非空,只保留三个用来记录注脚序号的数字,那么些数字必需是0一、10、一千的格式

1.调解系统时间

The rsa Utility

The rsa command is a useful utility for examining and modifying RSA private key files. Generally RSA keys are stored encrypted with a symmetric algorithm using a user-supplied pass phrase. The OpenSSL req command prompts the user for a pass phrase in order to encrypt the private key. By default, req uses the triple DES algorithm. The rsa command can be used to change the password that protects the private key and to convert the format of the private key. Any rsa command that involves reading an encrypted rsa private key will prompt for the PEM pass phrase used to encrypt it.

The options supported by the openssl rsa utility are as follows:

-inform arg

input format - one of DER NET PEM

-outform arg

output format - one of DER NET PEM

-in arg

inout file

-out arg

output file

-des

encrypt PEM output with cbc des

-des3

encrypt PEM output with ede cbc des using 168 bit key

-text

print the key in text

-noout

do not print key out

-modulus

print the RSA key modulus

 

Using the rsa Utility

Converting a private key to PEM format from DER format involves using the rsa utility as follows:

openssl rsa -inform DER -in MyKey.der -outform PEM -out MyKey.pem 

Changing the pass phrase which is used to encrypt the private key involves using the rsa utility as follows:

openssl rsa -inform PEM -in MyKey.pem -outform PEM -out MyKey.pem -des3 

Removing encryption from the private key (which is not recommended) involves using the rsa command utility as follows:

openssl rsa -inform PEM -in MyKey.pem -outform PEM -out MyKey2.pem 

Note:
Do not specify the same file for the -in and -out parameters, because this can corrupt the file.

    在Windows下不补助touch命令,能够手动成立那七个公文,并填好剧情

          1.Set date from the command line:

The ca Utility

You can use the ca utility create X.509 certificates by signing existing signing requests. It is imperative that you check the details of a certificate request before signing. Your organization should have a policy with respect to the issuing of certificates. Before implementing CAs, refer to Managing Certificates for more information.

The ca utility is used to sign certificate requests thereby creating a valid X.509 certificate which can be returned to the request submitter. It can also be used to generate Certificate Revocation Lists (CRLS). For information on the ca -policy and -name options, refer to "The OpenSSL Configuration File" on page?117.

To create a new CA using the openssl ca utility, two files (serial and index.txt) need to be created in the location specified by the openssl configuration file that you are using.

The options supported by the openssl ca utility are as follows:

-verbose

- Talk alot while doing things

-config file

- A config file

-name arg

- The particular CA definition to use

-gencrl

- Generate a new CRL

-crldays days

- Days is when the next CRL is due

-crlhours hours

- Hours is when the next CRL is due

-days arg

- number of days to certify the certificate for

-md arg

- md to use, one of md2, md5, sha or sha1

-policy arg

- The CA `policy' to support

-keyfile arg

- PEM private key file

-key arg

- key to decode the private key if it is encrypted

-cert

- The CA certificate

-in file

- The input PEM encoded certificate request(s)

-out file

- Where to put the output file(s)

-outdir dir

- Where to put output certificates 

-infiles....

- The last argument, requests to process

-spkac file

- File contains DN and signed public key and challenge

-preserveDN

- Do not re-order the DN

-batch

- Do not ask questions

-msie_hack

- msie modifications to handle all thos universal strings 

 

Note:
Most of the above parameters have default values as defined in openssl.cnf.

Using the ca Utility

Converting a private key to PEM format from DER format involves using the ca utility as shown in the following example. To sign the supplied CSR MyReq.pem to be valid for 365 days and create a new X.509 certificate in PEM format, use the ca utility as follows:

openssl ca -config ssl_conf_path_name -days 365 
-in MyReq.pem -out MyNewCert.pem 

2)颁发服务器证书时,common name必需是服务器U昂CoraL

 1 date  %Y%m%d -s "20120418" 

三)颁发帮助OCSP成效的注解,要求在中间证书的openssl.conf

          2.Set time from the command line:

authorityInfoAccess = OCSP;URI:http://ocsp.example.com
 1 date  %T -s "11:14:00" 

四)若希望在Firefox少校验OCSP成效,要求在劳务器端开启OCSP Stapling作用(Nginx或Apache都已帮助)。

  1. 转换证书

5)根CA及中间CA的布局文件在结尾,能够拷贝使用。

       参考连接:

OpenSSL Certificate Authority

This guide demonstrates how to act as your own certificate authority (CA) using the OpenSSL command-line tools. This is useful in a number of situations, such as issuing server certificates to secure an intranet website, or for issuing certificates to clients to allow them to authenticate to a server.

 

  • Introduction
  • Create the root pair
  • Create the intermediate pair
  • Sign server and client certificates
  • Certificate revocation lists
  • Online Certificate Status Protocol
  • Appendix

Generate a Self-Signed Certificate

Introduction

OpenSSL is a free and open-source cryptographic library that provides several command-line tools for handling digital certificates. Some of these tools can be used to act as a certificate authority.

A certificate authority (CA) is an entity that signs digital certificates. Many websites need to let their customers know that the connection is secure, so they pay an internationally trusted CA (eg, VeriSign, DigiCert) to sign a certificate for their domain.

In some cases it may make more sense to act as your own CA, rather than paying a CA like DigiCert. Common cases include securing an intranet website, or for issuing certificates to clients to allow them to authenticate to a server (eg, Apache, OpenVPN).

Use this method if you want to use HTTPS (HTTP over TLS) to secure your Apache HTTP or Nginx web server, and you do not require that your certificate is signed by a CA.

Create the root pair

Acting as a certificate authority (CA) means dealing with cryptographic pairs of private keys and public certificates. The very first cryptographic pair we’ll create is the root pair. This consists of the root key (ca.key.pem) and root certificate (ca.cert.pem). This pair forms the identity of your CA.

Typically, the root CA does not sign server or client certificates directly. The root CA is only ever used to create one or more intermediate CAs, which are trusted by the root CA to sign certificates on their behalf. This is best practice. It allows the root key to be kept offline and unused as much as possible, as any compromise of the root key is disastrous.

Note

It’s best practice to create the root pair in a secure environment. Ideally, this should be on a fully encrypted, air gapped computer that is permanently isolated from the Internet. Remove the wireless card and fill the ethernet port with glue.

This command creates a 2048-bit private key (domain.key) and a self-signed certificate (domain.crt) from scratch:

Prepare the directory

Choose a directory (/root/ca) to store all keys and certificates.

# mkdir /root/ca

Create the directory structure. The index.txt and serial files act as a flat file database to keep track of signed certificates.

# cd /root/ca
# mkdir certs crl newcerts private
# chmod 700 private
# touch index.txt
# echo 1000 > serial
1 openssl req 
2        -newkey rsa:2048 -nodes -keyout domain.key 
3        -x509 -days 365 -out domain.crt

Prepare the configuration file

You must create a configuration file for OpenSSL to use. Copy the root CA configuration file from the Appendix to /root/ca/openssl.cnf.

The [ ca ] section is mandatory. Here we tell OpenSSL to use the options from the [ CA_default ] section.

[ ca ]
# `man ca`
default_ca = CA_default

The [ CA_default ] section contains a range of defaults. Make sure you declare the directory you chose earlier (/root/ca).

[ CA_default ]
# Directory and file locations.
dir               = /root/ca
certs             = $dir/certs
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand

# The root key and root certificate.
private_key       = $dir/private/ca.key.pem
certificate       = $dir/certs/ca.cert.pem

# For certificate revocation lists.
crlnumber         = $dir/crlnumber
crl               = $dir/crl/ca.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30

# SHA-1 is deprecated, so use SHA-2 instead.
default_md        = sha256

name_opt          = ca_default
cert_opt          = ca_default
default_days      = 375
preserve          = no
policy            = policy_strict

We’ll apply policy_strict for all root CA signatures, as the root CA is only being used to create intermediate CAs.

[ policy_strict ]
# The root CA should only sign intermediate certificates that match.
# See the POLICY FORMAT section of `man ca`.
countryName             = match
stateOrProvinceName     = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

We’ll apply policy_loose for all intermediate CA signatures, as the intermediate CA is signing server and client certificates that may come from a variety of third-parties.

[ policy_loose ]
# Allow the intermediate CA to sign a more diverse range of certificates.
# See the POLICY FORMAT section of the `ca` man page.
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

Options from the [ req ] section are applied when creating certificates or certificate signing requests.

[ req ]
# Options for the `req` tool (`man req`).
default_bits        = 2048
distinguished_name  = req_distinguished_name
string_mask         = utf8only

# SHA-1 is deprecated, so use SHA-2 instead.
default_md          = sha256

# Extension to add when the -x509 option is used.
x509_extensions     = v3_ca

The [ req_distinguished_name ] section declares the information normally required in a certificate signing request. You can optionally specify some defaults.

[ req_distinguished_name ]
# See <https://en.wikipedia.org/wiki/Certificate_signing_request>.
countryName                     = Country Name (2 letter code)
stateOrProvinceName             = State or Province Name
localityName                    = Locality Name
0.organizationName              = Organization Name
organizationalUnitName          = Organizational Unit Name
commonName                      = Common Name
emailAddress                    = Email Address

# Optionally, specify some defaults.
countryName_default             = GB
stateOrProvinceName_default     = England
localityName_default            =
0.organizationName_default      = Alice Ltd
#organizationalUnitName_default =
#emailAddress_default           =

The next few sections are extensions that can be applied when signing certificates. For example, passing the -extensions v3_ca command-line argument will apply the options set in [ v3_ca ].

We’ll apply the v3_ca extension when we create the root certificate.

[ v3_ca ]
# Extensions for a typical CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

We’ll apply the v3_ca_intermediate extension when we create the intermediate certificate. pathlen:0 ensures that there can be no further certificate authorities below the intermediate CA.

[ v3_intermediate_ca ]
# Extensions for a typical intermediate CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

We’ll apply the usr_cert extension when signing client certificates, such as those used for remote user authentication.

[ usr_cert ]
# Extensions for client certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, emailProtection

We’ll apply the server_cert extension when signing server certificates, such as those used for web servers.

[ server_cert ]
# Extensions for server certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

The crl_ext extension is automatically applied when creating certificate revocation lists.

[ crl_ext ]
# Extension for CRLs (`man x509v3_config`).
authorityKeyIdentifier=keyid:always

We’ll apply the ocsp extension when signing the Online Certificate Status Protocol (OCSP) certificate.

[ ocsp ]
# Extension for OCSP signing certificates (`man ocsp`).
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning

Answer the CSR information prompt to complete the process.

Create the root key

Create the root key (ca.key.pem) and keep it absolutely secure. Anyone in possession of the root key can issue trusted certificates. Encrypt the root key with AES 256-bit encryption and a strong password.

Note

Use 4096 bits for all root and intermediate certificate authority keys. You’ll still be able to sign server and client certificates of a shorter length.

# cd /root/ca
# openssl genrsa -aes256 -out private/ca.key.pem 4096

Enter pass phrase for ca.key.pem: secretpassword
Verifying - Enter pass phrase for ca.key.pem: secretpassword

# chmod 400 private/ca.key.pem

The -x509 option tells req to create a self-signed cerificate. The -days 365 option specifies that the certificate will be valid for 365 days. A temporary CSR is generated to gather information to associate with the certificate.

Create the root certificate

Use the root key (ca.key.pem) to create a root certificate (ca.cert.pem). Give the root certificate a long expiry date, such as twenty years. Once the root certificate expires, all certificates signed by the CA become 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/ca
# openssl 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: secretpassword
You are about to be asked to enter information that will be incorporated
into your certificate request.
-----
Country Name (2 letter code) [XX]:GB
State or Province Name []:England
Locality Name []:
Organization Name []:Alice Ltd
Organizational Unit Name []:Alice Ltd Certificate Authority
Common Name []:Alice Ltd Root CA
Email Address []:

# chmod 444 certs/ca.cert.pem

 生成证书以往,把 domain.key 和 domain.crt 的剧情 复制到 cert.pem 中 上边为 private key,上边为 certificate 部分。

Verify the root certificate

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

The output shows:

  • the Signature Algorithm used
  • the dates of certificate Validity
  • the Public-Key bit length
  • the Issuer, which is the entity that signed the certificate
  • the Subject, which refers to the certificate itself

The Issuer and Subject are identical as the certificate is self-signed. Note that all root certificates are self-signed.

Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=GB, ST=England,
            O=Alice Ltd, OU=Alice Ltd Certificate Authority,
            CN=Alice Ltd Root CA
    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
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (4096 bit)

The output also shows the X509v3 extensions. We applied the v3_caextension, so the options from [ v3_ca ] should be reflected in the output.

X509v3 extensions:
    X509v3 Subject Key Identifier:
        38:58:29:2F:6B:57:79:4F:39:FD:32:35:60:74:92:60:6E:E8:2A:31
    X509v3 Authority Key Identifier:
        keyid:38:58:29:2F:6B:57:79:4F:39:FD:32:35:60:74:92:60:6E:E8:2A:31

    X509v3 Basic Constraints: critical
        CA:TRUE
    X509v3 Key Usage: critical
        Digital Signature, Certificate Sign, CRL Sign

叁.把系统时间调解到后天的日子。

Create the intermediate pair

An intermediate certificate authority (CA) is an entity that can sign certificates on behalf of the root CA. The root CA signs the intermediate certificate, forming a chain of trust.

The purpose of using an intermediate CA is primarily for security. 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 cryptographic pair.

四.查看证书的开头时间和过期时间是或不是如您的预想呢?

Prepare the directory

The root CA files are kept in /root/ca. Choose a different directory (/root/ca/intermediate) to store the intermediate CA files.

# mkdir /root/ca/intermediate

Create the same directory structure used for the root CA files. It’s convenient to also create a csr directory to hold certificate signing requests.

# cd /root/ca/intermediate
# mkdir certs crl csr newcerts private
# chmod 700 private
# touch index.txt
# echo 1000 > serial

Add a crlnumber file to the intermediate CA directory tree. crlnumber is used to keep track of certificate revocation lists.

# echo 1000 > /root/ca/intermediate/crlnumber

Copy the intermediate CA configuration file from the Appendix to/root/ca/intermediate/openssl.cnf. Five options have been changed compared to the root CA configuration file:

[ CA_default ]
dir             = /root/ca/intermediate
private_key     = $dir/private/intermediate.key.pem
certificate     = $dir/certs/intermediate.cert.pem
crl             = $dir/crl/intermediate.crl.pem
policy          = policy_loose
openssl x509 -startdate -noout -in key.pem

Create the intermediate key

Create the intermediate key (intermediate.key.pem). Encrypt the intermediate key with AES 256-bit encryption and a strong password.

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

Enter pass phrase for intermediate.key.pem: secretpassword
Verifying - Enter pass phrase for intermediate.key.pem: secretpassword

# chmod 400 intermediate/private/intermediate.key.pem

图片 1

Create the intermediate certificate

Use the intermediate key to create a certificate signing request (CSR). The details should generally match the root CA. The Common Name, however, must be different.

Warning

Make sure you specify the intermediate CA configuration file (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: secretpassword
You are about to be asked to enter information that will be incorporated
into your certificate request.
-----
Country Name (2 letter code) [XX]:GB
State or Province Name []:England
Locality Name []:
Organization Name []:Alice Ltd
Organizational Unit Name []:Alice Ltd Certificate Authority
Common Name []:Alice Ltd Intermediate CA
Email Address []:

To create an intermediate certificate, use the root CA with thev3_intermediate_ca extension to sign the intermediate CSR. The intermediate certificate should be valid for a shorter period than the root certificate. Ten years would be reasonable.

Warning

This time, 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.pem

Enter pass phrase for ca.key.pem: secretpassword
Sign the certificate? [y/n]: y

# chmod 444 intermediate/certs/intermediate.cert.pem

The index.txt file is where the OpenSSL ca tool stores the certificate database. Do not delete or edit this file by hand. It should now contain a line that refers to the intermediate certificate.

V 250408122707Z 1000 unknown ... /CN=Alice Ltd Intermediate CA

 

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

Verify the intermediate certificate against the root certificate. An OK indicates that the chain of trust is intact.

# openssl verify -CAfile certs/ca.cert.pem 
      intermediate/certs/intermediate.cert.pem

intermediate.cert.pem: OK

 

Create the certificate chain file

When an application (eg, a web browser) tries to verify a certificate signed by the intermediate CA, it must also verify the intermediate certificate against the root certificate. To complete the chain of trust, create a CA certificate chain to present to the application.

To create the CA certificate chain, concatenate the intermediate and root certificates together. We will use this file later to verify certificates 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

Our certificate chain file must include the root certificate because no client application knows about it yet. A better option, particularly if you’re administrating an intranet, is to install your root certificate on every client that needs to connect. In that case, the chain file need only contain your intermediate certificate.

图片 2

Sign server and client certificates

We will be signing certificates using our intermediate CA. You can use these signed certificates in a variety of situations, such as to secure connections to a web server or to authenticate clients connecting to a service.

Note

The steps below are from your perspective as the certificate authority. A third-party, however, can instead create their own private key and certificate signing request (CSR) without revealing their private key to you. They give you their CSR, and you give back a signed certificate. In that scenario, skip the genrsa and req commands.

图片 3

Create a key

Our root and intermediate pairs are 4096 bits. Server and client certificates normally expire after one year, so we can safely use 2048 bits instead.

Note

Although 4096 bits is slightly more secure than 2048 bits, it slows down TLS handshakes and significantly increases processor load during handshakes. For this reason, most websites use 2048-bit pairs.

If you’re creating a cryptographic pair for use with a web server (eg, Apache), you’ll need to enter this password every time you restart the web server. You may want to omit the -aes256 option to create a key without a password.

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

图片 4

Create a certificate

Use the private key to create a certificate signing request (CSR). The CSR details don’t need to match the intermediate CA. For server certificates, theCommon Name must be a fully qualified domain name (eg, www.example.com), whereas for client certificates it can be any unique identifier (eg, an e-mail address). Note that the Common Name cannot be the same as either your root 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: secretpassword
You are about to be asked to enter information that will be incorporated
into your certificate request.
-----
Country Name (2 letter code) [XX]:US
State or Province Name []:California
Locality Name []:Mountain View
Organization Name []:Alice Ltd
Organizational Unit Name []:Alice Ltd Web Services
Common Name []:www.example.com
Email Address []:

To create a certificate, use the intermediate CA to sign the CSR. If the certificate is going to be used on a server, use the server_cert extension. If the certificate is going to be used for user authentication, use the usr_certextension. Certificates are usually given a validity of one year, though a CA will typically give a few days extra for convenience.

# 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 444 intermediate/certs/www.example.com.cert.pem

The intermediate/index.txt file should contain a line referring to this new certificate.

V 160420124233Z 1000 unknown ... /CN=www.example.com

图片 5

Verify the certificate

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

The Issuer is the intermediate CA. The 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 the X509v3 extensions. When creating the certificate, you used either the server_cert or usr_cert extension. The options from 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

Use the CA certificate chain file we created earlier (ca-chain.cert.pem) to verify that the new certificate has a valid chain of trust.

# openssl verify -CAfile intermediate/certs/ca-chain.cert.pem 
      intermediate/certs/www.example.com.cert.pem

www.example.com.cert.pem: OK

图片 6

Deploy the certificate

You can now either deploy your new certificate to a server, or distribute the certificate to a client. When deploying to a server application (eg, Apache), you need to make the following files available:

  • ca-chain.cert.pem
  • www.example.com.key.pem
  • www.example.com.cert.pem

If you’re signing a CSR from a third-party, you don’t have access to their private key so you only need to give them back the chain file (ca-chain.cert.pem) and the certificate (www.example.com.cert.pem).

图片 7图片 8

Certificate revocation lists

A certificate revocation list (CRL) provides a list of certificates that have been revoked. A client application, such as a web browser, can use a CRL to check a server’s authenticity. A server application, such as Apache or OpenVPN, can use a CRL to deny access to clients that are no longer trusted.

Publish the CRL at a publicly accessible location (eg,http://example.com/intermediate.crl.pem). Third-parties can fetch the CRL from this location to check whether any certificates they rely on have been revoked.

Note

Some applications vendors have deprecated CRLs and are instead using the Online Certificate Status Protocol (OCSP).

图片 9

Prepare the configuration file

When a certificate authority signs a certificate, it will normally encode the CRL location into the certificate. Add crlDistributionPoints to the appropriate sections. In our case, add it to the [ server_cert ] section.

[ server_cert ]
# ... snipped ...
crlDistributionPoints = URI:http://example.com/intermediate.crl.pem

Create the 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 on how to create CRLs.

You can check the contents of the CRL with the crl tool.

# openssl crl -in intermediate/crl/intermediate.crl.pem -noout -text

No certificates have been revoked yet, so the output will state No Revoked Certificates.

You should re-create the CRL at regular intervals. By default, the CRL expires after 30 days. This is controlled by the default_crl_days option in the[ CA_default ] section.

Revoke a certificate

Let’s walk through an example. Alice is running the Apache web server and has a private folder of heart-meltingly cute kitten pictures. Alice wants to grant her friend, Bob, access to this collection.

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

$ cd /home/bob
$ openssl genrsa -out bob@example.com.key.pem 2048
$ openssl 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 incorporated
into your certificate request.
-----
Country Name [XX]:US
State or Province Name []:California
Locality Name []:San Francisco
Organization Name []:Bob Ltd
Organizational Unit Name []:
Common Name []:bob@example.com
Email Address []:

Bob sends his CSR to Alice, who then signs it.

# cd /root/ca
# openssl ca -config intermediate/openssl.cnf 
      -extensions usr_cert -notext -md sha256 
      -in intermediate/csr/bob@example.com.csr.pem 
      -out intermediate/certs/bob@example.com.cert.pem

Sign the certificate? [y/n]: y
1 out of 1 certificate requests certified, commit? [y/n]: y

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 contain a new entry.

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

Alice sends Bob the signed certificate. Bob installs the certificate in his web browser and is now able to access Alice’s kitten pictures. Hurray!

Sadly, it turns out that Bob is misbehaving. Bob has posted Alice’s kitten pictures to Hacker News, claiming that they’re his own and gaining huge popularity. Alice finds out and needs to revoke his access immediately.

# cd /root/ca
# openssl ca -config intermediate/openssl.cnf 
      -revoke intermediate/certs/bob@example.com.cert.pem

Enter pass phrase for intermediate.key.pem: secretpassword
Revoking Certificate 1001.
Data Base Updated

The line in index.txt that corresponds to Bob’s certificate now begins with the character R. This means the certificate has been revoked.

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

After revoking Bob’s certificate, Alice must re-create the CRL.

Server-side use of the CRL

For client certificates, it’s typically a server-side application (eg, Apache) that is doing the verification. This application needs to have local access to the CRL.

In Alice’s case, she can add the SSLCARevocationPath directive to her Apache configuration and copy the CRL to her web server. The next time that Bob connects to the web server, Apache will check his client certificate against the CRL and deny access.

Similarly, OpenVPN has a crl-verify directive so that it can block clients that have had their certificates revoked.

Client-side use of the CRL

For server certificates, it’s typically a client-side application (eg, a web browser) that performs the verification. This application must have remote access to the CRL.

If a certificate was signed with an extension that includescrlDistributionPoints, a client-side application can read this information and fetch the CRL from the specified location.

The CRL distribution points are visible in the certificate X509v3 details.

# openssl x509 -in cute-kitten-pictures.example.com.cert.pem -noout -text

    X509v3 CRL Distribution Points:

        Full Name:
          URI:http://example.com/intermediate.crl.pem

 

Online Certificate Status Protocol

The Online Certificate Status Protocol (OCSP) was created as an alternative tocertificate revocation lists (CRLs). Similar to CRLs, OCSP enables a requesting party (eg, a web browser) to determine the revocation state of a certificate.

When a CA signs a certificate, they will typically include an OCSP server address (eg, http://ocsp.example.com) in the certificate. This is similar in function to crlDistributionPoints used for CRLs.

As an example, when a web browser is presented with a server certificate, it will send a query to the OCSP server address specified in the certificate. At this address, an OCSP responder listens to queries and responds with the revocation status of the certificate.

Note

It’s recommended to use OCSP instead where possible, though realistically you will tend to only need OCSP for website certificates. Some web browsers have deprecated or removed support for CRLs.

Prepare the configuration file

To use OCSP, the CA must encode the OCSP server location into the certificates that it signs. Use the authorityInfoAccess option in the appropriate sections, which in our case means the [ server_cert ] section.

[ server_cert ]
# ... snipped ...
authorityInfoAccess = OCSP;URI:http://ocsp.example.com

Create the OCSP pair

The OCSP responder requires a cryptographic pair for signing the response that it sends to the requesting party. The OCSP cryptographic pair must be signed by the same CA that signed the certificate being checked.

Create a private key and encrypt it with AES-256 encryption.

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

Create a certificate signing request (CSR). The details should generally match those of the signing CA. The Common Name, however, 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: secretpassword
You are about to be asked to enter information that will be incorporated
into your certificate request.
-----
Country Name (2 letter code) [XX]:GB
State or Province Name []:England
Locality Name []:
Organization Name []:Alice Ltd
Organizational Unit Name []:Alice Ltd Certificate Authority
Common Name []:ocsp.example.com
Email Address []:

Sign the CSR with the intermediate CA.

# 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

Verify that the certificate has the correct X509v3 extensions.

# 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

Revoke a certificate

The OpenSSL ocsp tool can act as an OCSP responder, but it’s only intended for testing. Production ready OCSP responders exist, but those 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 2048
# 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 localhost. Rather than storing revocation status in a separate CRL file, the OCSP responder reads index.txt directly. The response is signed with the OCSP cryptographic pair (using the -rkey and -rsigneroptions).

# openssl ocsp -port 127.0.0.1:2560 -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

Enter pass phrase for ocsp.example.com.key.pem: secretpassword

In another terminal, send 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 start of the output shows:

  • whether a successful response was received (OCSP Response Status)
  • the identity of the responder (Responder Id)
  • the revocation status of the certificate (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: secretpassword
Revoking Certificate 1003.
Data Base Updated

As before, run the OCSP responder and on another terminal send a query. This time, the output shows Cert Status: revoked and a Revocation 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

Root CA configuration file

View this file as plain text.

# OpenSSL root CA configuration file.
# Copy to `/root/ca/openssl.cnf`.

[ ca ]
# `man ca`
default_ca = CA_default

[ CA_default ]
# Directory and file locations.
dir               = /root/ca
certs             = $dir/certs
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
RANDFILE          = $dir/private/.rand

# The root key and root certificate.
private_key       = $dir/private/ca.key.pem
certificate       = $dir/certs/ca.cert.pem

# For certificate revocation lists.
crlnumber         = $dir/crlnumber
crl               = $dir/crl/ca.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30

# SHA-1 is deprecated, so use SHA-2 instead.
default_md        = sha256

name_opt          = ca_default
cert_opt          = ca_default
default_days      = 375
preserve          = no
policy            = policy_strict

[ policy_strict ]
# The root CA should only sign intermediate certificates that match.
# See the POLICY FORMAT section of `man ca`.
countryName             = match
stateOrProvinceName     = match
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[ policy_loose ]
# Allow the intermediate CA to sign a more diverse range of certificates.
# See the POLICY FORMAT section of the `ca` man page.
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[ req ]
# Options for the `req` tool (`man req`).
default_bits        = 2048
distinguished_name  = req_distinguished_name
string_mask         = utf8only

# SHA-1 is deprecated, so use SHA-2 instead.
default_md          = sha256

# Extension to add when the -x509 option is used.
x509_extensions     = v3_ca

[ req_distinguished_name ]
# See <https://en.wikipedia.org/wiki/Certificate_signing_request>.
countryName                     = Country Name (2 letter code)
stateOrProvinceName             = State or Province Name
localityName                    = Locality Name
0.organizationName              = Organization Name
organizationalUnitName          = Organizational Unit Name
commonName                      = Common Name
emailAddress                    = Email Address

# Optionally, specify some defaults.
countryName_default             = GB
stateOrProvinceName_default     = England
localityName_default            =
0.organizationName_default      = Alice Ltd
organizationalUnitName_default  =
emailAddress_default            =

[ v3_ca ]
# Extensions for a typical CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ v3_intermediate_ca ]
# Extensions for a typical intermediate CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ usr_cert ]
# Extensions for client certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, emailProtection

[ server_cert ]
# Extensions for server certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

[ crl_ext ]
# Extension for CRLs (`man x509v3_config`).
authorityKeyIdentifier=keyid:always

[ ocsp ]
# Extension for OCSP signing certificates (`man ocsp`).
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage 
TAG标签: 韦德娱乐1946
版权声明:本文由韦德娱乐1946_韦德娱乐1946网页版|韦德国际1946官网发布于韦德国际1946官网,转载请注明出处:一声令下表达,过期的证书