- Openssl Ssl Certificate
- Openssl Create Intermediate Ca
- Openssl Intermediate Certificate Windows
- Openssl Certificate Information
- Openssl Certificate Verify
- From the client certificate, we'll grab all issuer certificates (intermmediate and root). First, we need to get the certificate that signed the client cert (which is either an intermmediate cert or the root cert itself).
- May 30, 2017 The -untrusted option is used to give the intermediate certificate (s); se.crt is the certificate to verify. The depth=2 result came from the system trusted CA store. If you don't have the intermediate certificate (s), you can't perform the verify. That's just how X.509 works.
Create and operate Public Key Infrastructures with OpenSSL.
Install OpenSSL. On RHEL/CentOS 7/8 you can use yum or dnf respectively while on Ubuntu use apt. Jerry, When you create the intermediate certificate, you need to add the following attribute:- basicConstraints=CA:true Otherwise, the intermediate CA certificate can not issue server certificates. Best regards, John Mok On Thu, Nov 27, 2014 at 3:43 PM, Jerry OELoo wrote. An Intermediate Certificate is a subordinate certificate issued by a Root certificate authority for the purpose of issuing certificates. This creates a certificate chain that begins in the Root CA, through the intermediate and ending in the issued certificate. This establishes a chain of trust that can verify the validity of a certificate.
Overview¶
This tutorial shows how to implement real-worldPKIs with the OpenSSL toolkit.
In the first part of the tutorial we introduce the necessary terms and concepts.The second part consists of examples, where we build increasingly moresophisticated PKIs using nothing but the openssl
utility.The tutorial puts a special focus on configuration files, which are keyto taming the openssl
command line. It also serves to promote what we havefound to be the most effective way of partinioning the configuration space:
Openssl Ssl Certificate
- One configuration file per CA, and
- One configuration file per CSR type.
Please study the configuration files included in the examples, it's where mostof the treasure is buried.
PKI Concepts¶
At its heart, an X.509 PKI is a security architecture that uses well-establishedcryptographic mechanisms to support use-cases like email protection and webserver authentication. In this regard it is similarto other systems based on public-key cryptography, for example OpenPGP [RFC 4880].In the realm of X.509 however, and thanks to its roots in a globe-spanningscheme devised by the telecom industry, these mechanisms come with a fairamount of administrative overhead.
One thing to keep in mind is that X.509 is not an application,but a specification upon which applications likeSecure Multipurpose Internet Mail Extensions (S/MIME) andTransport Layer Security (TLS) are based.The building blocks are very generic and derive most oftheir meaning from the relations that exist/are established between them.It's called an infrastructure for a reason.
Process¶
- A requestor generates a CSR and submits it to the CA.
- The CA issues a certificate based on the CSR and returns it to the requestor.
- Should the certificate at some point be revoked, the CA adds it to its CRL.
Components¶
- Public Key Infrastructure (PKI)
- Security architecture where trust is conveyed through the signatureof a trusted CA.
- Certificate Authority (CA)
- Entity issuing certificates and CRLs.
- Registration Authority (RA)
- Entity handling PKI enrollment. May be identical with the CA.
- Certificate
- Public key and ID bound by a CA signature.
- Certificate Signing Request (CSR)
- Request for certification. Contains public key and ID to be certified.
- Certificate Revocation List (CRL)
- List of revoked certificates. Issued by a CA at regular intervals.
- Certification Practice Statement (CPS)
- Document describing structure and processes of a CA.
CA Types¶
- Root CA
- CA at the root of a PKI hierarchy. Issues only CA certificates.
- Intermediate CA
- CA below the root CA but not a signing CA. Issues only CA certificates.
- Signing CA
- CA at the bottom of a PKI hierarchy. Issues only user certificates.
Certificate Types¶
- CA Certificate
- Certificate of a CA. Used to sign certificates and CRLs.
- Root Certificate
- Self-signed CA certificate at the root of a PKI hierarchy.Serves as the PKI's trust anchor.
- Cross Certificate
- CA certificate issued by a CA external to the primary PKI hierarchy.Used to connect two PKIs and thus usually comes in pairs. [1]
- User Certificate
- End-user certificate issued for one or more purposes:email-protection, server-auth, client-auth, code-signing, etc.A user certificate cannot sign other certificates.
Footnotes
[1] | The RFC classifies any CA-signs-CA scenario as cross-certification,to distinguish it from self-issuing.Outside of specs however, the term normally only refers to inter-PKIcross-certification. |
File Formats¶
- Privacy Enhanced Mail (PEM)
- Text format. Base-64 encoded data with header and footer lines.Preferred format in OpenSSL and most software based on it (e.g. Apachemod_ssl, stunnel).
- Distinguished Encoding Rules (DER)
- Binary format. Preferred format in Windows environments. Also theofficial format for Internet download of certificates and CRLs.
Examples¶
Openssl Create Intermediate Ca
The examples are meant to be done in order, each providing the basis forthe ones that follow.They are deliberately low on prose, we prefer to let the configuration filesand command lines speak for themselves.
You will find a reference section at the bottom of each page, withlinks to relevant parts of the OpenSSL documentation. Please use the linksfor details on command line options and configuration file settings.
Openssl Intermediate Certificate Windows
Note: You need at least OpenSSL 1.0.1. Check with:
Simple PKI¶
In this example we create the simplest possible PKI: One root CA and onesigning CA.We use the CA to issue two types of user certificates.
Advanced PKI¶
In this example we create a larger setup, consisting of a root CA and threesigning CAs.We use the CAs to issue 4 different types of user certificates.We also encounter two new certificate extensions: authorityInfoAccess andcrlDistributionPoints.
Expert PKI¶
In this example we create a 3-tier CA hierarchy: One root CA, one intermediateCA, and two signing CAs.We use the CAs to issue 6 types of user certificates.We introduce certificate policies and the certificatePolicies extension.We also show how to configure an OCSP responder.
Appendices¶
MIME Types¶
This section takes a closer look at the MIME types and file extensionsused.
CA Database¶
This section examines the format of the CA database.
References¶
- RFC 5280
- Internet X.509 Public Key Infrastructure Certificateand Certificate Revocation List (CRL) Profile
- RFC 2585
- Internet X.509 Public Key InfrastructureOperational Protocols: FTP and HTTP
- RFC 5750
- Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2Certificate Handling
- RFC 6125
- Representation and Verification of Domain-Based Application ServiceIdentity within Internet Public Key Infrastructure Using X.509 (PKIX)Certificates in the Context of Transport Layer Security (TLS)
- Baseline Requirements [pdf, opens in browser]
- CA/Browser Forum Baseline Requirements for the Issuance and Managementof Publicly-Trusted Certificates
- X.509 Recommendation [pdf, direct download]
- ITU-T X.509 Public-Key and Attribute Certificate Frameworks Recommendation
- OpenSSL TEST CA [pdf, direct download]
- Carillon Information Security: How to Set Up an OpenSSL TEST CA forInteroperability Testing with CertiPath
Acting as a certificate authority (CA) means dealing with cryptographic pairs ofprivate keys and public certificates. The very first cryptographic pair we'llcreate is the root pair. This consists of the root key (ca.key.pem
) and rootcertificate (ca.cert.pem
). This pair forms the identity of your CA.
Typically, the root CA does not sign server or client certificates directly. Theroot CA is only ever used to create one or more intermediate CAs, which aretrusted by the root CA to sign certificates on their behalf. This is bestpractice. It allows the root key to be kept offline and unused as much aspossible, 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 ispermanently isolated from the Internet. Remove the wireless card and fillthe ethernet port with glue.
Prepare the directory¶
Choose a directory (/root/ca
) to store all keys and certificates.
Create the directory structure. The index.txt
and serial
files act as aflat file database to keep track of signed certificates.
Prepare the configuration file¶
You must create a configuration file for OpenSSL to use. Copy the root CAconfiguration file from the Appendixto /root/ca/openssl.cnf
.
The [ca]
section is mandatory. Here we tell OpenSSL to use the optionsfrom the [CA_default]
section.
The [CA_default]
section contains a range of defaults. Make sure youdeclare the directory you chose earlier (/root/ca
).
We'll apply policy_strict
for all root CA signatures, as the root CA isonly being used to create intermediate CAs.
We'll apply policy_loose
for all intermediate CA signatures, as theintermediate CA is signing server and client certificates that may come from avariety of third-parties.
Options from the [req]
section are applied when creating certificates orcertificate signing requests.
The [req_distinguished_name]
section declares the information normallyrequired in a certificate signing request. You can optionally specify somedefaults.
At its heart, an X.509 PKI is a security architecture that uses well-establishedcryptographic mechanisms to support use-cases like email protection and webserver authentication. In this regard it is similarto other systems based on public-key cryptography, for example OpenPGP [RFC 4880].In the realm of X.509 however, and thanks to its roots in a globe-spanningscheme devised by the telecom industry, these mechanisms come with a fairamount of administrative overhead.
One thing to keep in mind is that X.509 is not an application,but a specification upon which applications likeSecure Multipurpose Internet Mail Extensions (S/MIME) andTransport Layer Security (TLS) are based.The building blocks are very generic and derive most oftheir meaning from the relations that exist/are established between them.It's called an infrastructure for a reason.
Process¶
- A requestor generates a CSR and submits it to the CA.
- The CA issues a certificate based on the CSR and returns it to the requestor.
- Should the certificate at some point be revoked, the CA adds it to its CRL.
Components¶
- Public Key Infrastructure (PKI)
- Security architecture where trust is conveyed through the signatureof a trusted CA.
- Certificate Authority (CA)
- Entity issuing certificates and CRLs.
- Registration Authority (RA)
- Entity handling PKI enrollment. May be identical with the CA.
- Certificate
- Public key and ID bound by a CA signature.
- Certificate Signing Request (CSR)
- Request for certification. Contains public key and ID to be certified.
- Certificate Revocation List (CRL)
- List of revoked certificates. Issued by a CA at regular intervals.
- Certification Practice Statement (CPS)
- Document describing structure and processes of a CA.
CA Types¶
- Root CA
- CA at the root of a PKI hierarchy. Issues only CA certificates.
- Intermediate CA
- CA below the root CA but not a signing CA. Issues only CA certificates.
- Signing CA
- CA at the bottom of a PKI hierarchy. Issues only user certificates.
Certificate Types¶
- CA Certificate
- Certificate of a CA. Used to sign certificates and CRLs.
- Root Certificate
- Self-signed CA certificate at the root of a PKI hierarchy.Serves as the PKI's trust anchor.
- Cross Certificate
- CA certificate issued by a CA external to the primary PKI hierarchy.Used to connect two PKIs and thus usually comes in pairs. [1]
- User Certificate
- End-user certificate issued for one or more purposes:email-protection, server-auth, client-auth, code-signing, etc.A user certificate cannot sign other certificates.
Footnotes
[1] | The RFC classifies any CA-signs-CA scenario as cross-certification,to distinguish it from self-issuing.Outside of specs however, the term normally only refers to inter-PKIcross-certification. |
File Formats¶
- Privacy Enhanced Mail (PEM)
- Text format. Base-64 encoded data with header and footer lines.Preferred format in OpenSSL and most software based on it (e.g. Apachemod_ssl, stunnel).
- Distinguished Encoding Rules (DER)
- Binary format. Preferred format in Windows environments. Also theofficial format for Internet download of certificates and CRLs.
Examples¶
Openssl Create Intermediate Ca
The examples are meant to be done in order, each providing the basis forthe ones that follow.They are deliberately low on prose, we prefer to let the configuration filesand command lines speak for themselves.
You will find a reference section at the bottom of each page, withlinks to relevant parts of the OpenSSL documentation. Please use the linksfor details on command line options and configuration file settings.
Openssl Intermediate Certificate Windows
Note: You need at least OpenSSL 1.0.1. Check with:
Simple PKI¶
In this example we create the simplest possible PKI: One root CA and onesigning CA.We use the CA to issue two types of user certificates.
Advanced PKI¶
In this example we create a larger setup, consisting of a root CA and threesigning CAs.We use the CAs to issue 4 different types of user certificates.We also encounter two new certificate extensions: authorityInfoAccess andcrlDistributionPoints.
Expert PKI¶
In this example we create a 3-tier CA hierarchy: One root CA, one intermediateCA, and two signing CAs.We use the CAs to issue 6 types of user certificates.We introduce certificate policies and the certificatePolicies extension.We also show how to configure an OCSP responder.
Appendices¶
MIME Types¶
This section takes a closer look at the MIME types and file extensionsused.
CA Database¶
This section examines the format of the CA database.
References¶
- RFC 5280
- Internet X.509 Public Key Infrastructure Certificateand Certificate Revocation List (CRL) Profile
- RFC 2585
- Internet X.509 Public Key InfrastructureOperational Protocols: FTP and HTTP
- RFC 5750
- Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2Certificate Handling
- RFC 6125
- Representation and Verification of Domain-Based Application ServiceIdentity within Internet Public Key Infrastructure Using X.509 (PKIX)Certificates in the Context of Transport Layer Security (TLS)
- Baseline Requirements [pdf, opens in browser]
- CA/Browser Forum Baseline Requirements for the Issuance and Managementof Publicly-Trusted Certificates
- X.509 Recommendation [pdf, direct download]
- ITU-T X.509 Public-Key and Attribute Certificate Frameworks Recommendation
- OpenSSL TEST CA [pdf, direct download]
- Carillon Information Security: How to Set Up an OpenSSL TEST CA forInteroperability Testing with CertiPath
Acting as a certificate authority (CA) means dealing with cryptographic pairs ofprivate keys and public certificates. The very first cryptographic pair we'llcreate is the root pair. This consists of the root key (ca.key.pem
) and rootcertificate (ca.cert.pem
). This pair forms the identity of your CA.
Typically, the root CA does not sign server or client certificates directly. Theroot CA is only ever used to create one or more intermediate CAs, which aretrusted by the root CA to sign certificates on their behalf. This is bestpractice. It allows the root key to be kept offline and unused as much aspossible, 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 ispermanently isolated from the Internet. Remove the wireless card and fillthe ethernet port with glue.
Prepare the directory¶
Choose a directory (/root/ca
) to store all keys and certificates.
Create the directory structure. The index.txt
and serial
files act as aflat file database to keep track of signed certificates.
Prepare the configuration file¶
You must create a configuration file for OpenSSL to use. Copy the root CAconfiguration file from the Appendixto /root/ca/openssl.cnf
.
The [ca]
section is mandatory. Here we tell OpenSSL to use the optionsfrom the [CA_default]
section.
The [CA_default]
section contains a range of defaults. Make sure youdeclare the directory you chose earlier (/root/ca
).
We'll apply policy_strict
for all root CA signatures, as the root CA isonly being used to create intermediate CAs.
We'll apply policy_loose
for all intermediate CA signatures, as theintermediate CA is signing server and client certificates that may come from avariety of third-parties.
Options from the [req]
section are applied when creating certificates orcertificate signing requests.
The [req_distinguished_name]
section declares the information normallyrequired in a certificate signing request. You can optionally specify somedefaults.
The next few sections are extensions that can be applied when signingcertificates. For example, passing the -extensionsv3_ca
command-lineargument will apply the options set in [v3_ca]
.
We'll apply the v3_ca
extension when we create the root certificate.
We'll apply the v3_ca_intermediate
extension when we create theintermediate certificate. pathlen:0
ensures that there can be no further certificate authorities below theintermediate CA.
We'll apply the usr_cert
extension when signing client certificates, suchas those used for remote user authentication.
We'll apply the server_cert
extension when signing server certificates,such as those used for web servers.
The crl_ext
extension is automatically applied when creatingcertificate revocation lists.
We'll apply the ocsp
extension when signing the Online CertificateStatus Protocol (OCSP) certificate.
Create the root key¶
Create the root key (ca.key.pem
) and keep it absolutely secure. Anyone inpossession of the root key can issue trusted certificates. Encrypt the root keywith 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 shorterlength.
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 theroot certificate expires, all certificates signed by the CA become invalid.
Warning
Whenever you use the req
tool, you must specify a configuration file touse with the -config
option, otherwise OpenSSL will default to/etc/pki/tls/openssl.cnf
.
Verify the root certificate¶
The output shows:
Openssl Certificate Information
- the
SignatureAlgorithm
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.
The output also shows the X509v3 extensions. We applied the v3_ca
extension, so the options from [v3_ca]
should be reflected in theoutput.
Openssl Certificate Verify
Version 1.0.4 — Last updated on 2015-12-09.
© Copyright 2013-2015, Jamie Nguyen. Created with Sphinx using a custom-built theme.