Openssl View Pem Certificate

View Certificates Certificate and CSR files are encoded in PEM format, which is not readily human-readable. This section covers OpenSSL commands that will output the actual entries of PEM-encoded files. Openssl show certificate chain In any case, if you have to provide the whole chain, you are generally only given the option of uploading one PEM file. This guide will show you how to read the SSL Certificate Information from a text-file on your server or from a remote server by connecting to it with the OpenSSL. To check that the public key in your cert matches the public portion of your private key, you need to view the cert and the key and compare the numbers. To view the Certificate and the key run the commands: $ openssl x509 -noout -text -in server.crt $ openssl rsa -noout -text -in server.key. OpenSSL provides read different type of certificate and encoding formats. OpenSSL supports certificate formats like RSA, X509, PCKS12 etc. We will look how to read these certificate formats with OpenSSL. Read RSA Private Key. 50 The OpenSSL command-line utility can be used to inspect certificates (and private keys, and many other things). To see everything in the certificate, you can do: openssl x509 -in CERT.pem -noout -text.

  1. Openssl View Pem Certificate Sample
  2. Openssl View Pem Certificate Details
  3. Openssl Dump Pem File
  4. Openssl View Pem Certificate Template
  5. Openssl View Pem Certificate
  6. Openssl Show Pem

Certificate:

A certificate is a public key with extra properties (like company name, country,…) that is signed by some Certificate authority that guarantees that the attached properties are true.

View

Even though PEM encoded certificates are ASCII they are not human readable. Here are some commands that will let you output the contents of a certificate in human readable form.

View PEM encoded certificate

Use the command that has the extension of your certificate replacing cert.xxx with the name of your certificate

If you get the folowing error it means that you are trying to view a DER encoded certifciate and need to use the commands in the “View DER encoded certificate” below:

View DER encoded certificate

If you get the following error it means that you are trying to view a PEM encoded certificate with a command meant for DER encoded certs. Use a command in the “View PEM encoded certificate” above:

View all certificates in a certificate chain

Convert

These commands allow you to convert certificates and keys to different formats to make them compatible with specific types of servers or software.

  • Convert a DER file (.crt .cer .der) to PEM

  • Convert a PEM file to DER

  • Convert a PKCS#12 file (.pfx .p12) containing a private key and certificates to PEM

  • Convert a PEM certificate file and a private key to PKCS#12 (.pfx .p12)

  • Convert PEM to CRT (.CRT file)

OpenSSL Convert PEM

  • Convert PEM to DER

  • Convert PEM to P7B

  • Convert PEM to PFX

OpenSSL Convert DER

  • Convert DER to PEM

OpenSSL Convert P7B

  • Convert P7B to PEM

  • Convert P7B to PFX

OpenSSL Convert PFX

  • Convert PFX to PEM

Generate rsa keys by OpenSSL

  • Using OpenSSL on the command line you’d first need to generate a public and private key, you should password protect this file using the -passout argument, there are many different forms that this argument can take so consult the OpenSSL documentation about that.

  • This creates a key file called private.pem that uses 4096 bits. This file actually have both the private and public keys, so you should extract the public one from this file:

You’ll now have public.pem containing just your public key, you can freely share this with 3rd parties. You can test it all by just encrypting something yourself using your public key and then decrypting using your private key, first we need a bit of data to encrypt:

  • Example file :

  • You now have some data in file.txt, lets encrypt it using OpenSSL andthe public key:

  • This creates an encrypted version of file.txt calling it file.ssl, ifyou look at this file it’s just binary junk, nothing very useful toanyone. Now you can unencrypt it using the private key:

  • You will now have an unencrypted file in decrypted.txt:

RSA TOOLS Options in OpenSSL

Openssl view pem certificate download
  • NAME

  • SYNOPSIS

  • DESCRIPTION

  • COMMAND OPTIONS

    EXAMPLES

    To remove the pass phrase on an RSA private key:

    To encrypt a private key using triple DES:

    To convert a private key from PEM to DER format:

    To print out the components of a private key to standard output:

    To just output the public part of a private key:

    Output the public part of a private key in RSAPublicKey format:

Formats

RSA Public Key

Encrypted PEM Private Key

Pem

CRL

CRT

CSR

NEW CSR

PEM

PKCS7

PRIVATE KEY

DSA KEY

Elliptic Curve

PGP Private Key

PGP Public Key

For OpenSSL to recognize it as a PEM format, it must be encoded in Base64, with the following header:

Also, each line must be maximum 79 characters long. Otherwise you will receive the error:

Note: the PEM standard (RFC1421) mandates lines with 64 characters long. A PEM certificate stored as a single line can be converted with the UNIX command-line utility:

  • PKCS#1 RSAPublicKey (PEM header: BEGIN RSA PUBLIC KEY)
  • PKCS#8 EncryptedPrivateKeyInfo (PEM header: BEGIN ENCRYPTED PRIVATE KEY)
  • PKCS#8 PrivateKeyInfo (PEM header: BEGIN PRIVATE KEY)
  • X.509 SubjectPublicKeyInfo (PEM header: BEGIN PUBLIC KEY)
  • CSR PEM header : (PEM header:—-BEGIN NEW CERTIFICATE REQUEST—–)
  • DSA PrivateKeyInfo (PEM header: (—–BEGIN DSA PRIVATE KEY—-)

Verify

Before establishing a SSL/TLS connection, the client needs to be sure that the received certificate is valid. In order to do it the client verifies not only the authenticity of its public key but also other metadata associated with it (to understand this is important to know the contents of a typical digital certificate):

  • The signature verifies. This ensures that the certificate was not altered in any way.
  • The certificate has not expired. When the certificate is issued by the CA its granted an expiration date.
  • The certificate subject matches the host name. The certificate is issued for an specific server. Thus the certificate subject name needs to match the URL the client is trying to connect.
  • It has not been revoked. Sometimes certificates can be revoked by their issuers in any case needed (for example, the associate private key has been exposed hence the certificate becomes invalid).
  • It was signed by a trusted CA. To prove the certificate authenticity we need to get the CA certificate and verify its trustiness. Nevertheless in PKI there is a concept of Chain of Trust, so the CA certificate could have been issued by another CAs. Therefore we need to get this another CA’s certificate and validate it. And so on… Ergo, in order to trust a certificate, we need to navigate all the way up to the Root CA. Finally, if we trust in the Root CA it is safe to say that we trust in the whole chain.

Validate chain of trust

Depending on the scenario you either have:

a) your entire CA chain in a single file and the actual webserver or client certificate in another file

Verify it with:

Note:

Unfortunately, an “intermediate” cert that is actually a root / self-signed will be treated as a trusted CA. It seems openssl will stop verifying the chain as soon as a root certificate is encountered, which may also be Intermediate.pem if it is self-signed. In that case root.pem is not considered

b) the root and intermediate certificates in separate files and the actual webserver or client certificate in another file

Verify with:

If you have multiple intermediate CAs (e.g. root.pem -> intermediate1.pem -> intermediate2.pem -> client-cert.pem), concatenate them in a single file and pass it via: -untrusted intermediate-chain.pem or do it with cat:

Practical example

Expiration date

View

Check local certificate files

Here’s my bash command line to list multiple certificates in order of their expiration, most recently expiring first.

Sample output:

Check remote servers

Here’s a bash function which checks all your servers, assuming you’re using DNS round-robin. Note that this requires GNU date and won’t work on Mac OS

Output example:

Openssl view pem certificate download

Check with curl

You need to provide the entire certificate chain to curl, since curl no longer ships with any CA certs. Since the cacert option can only use one file, you need to concat the full chain info into 1 file. Get the bundle of root CA certificates from https://curl.haxx.se/ca/cacert.pem.

Check with openssl s_client

With SNI

If the remote server is using SNI (that is, sharing multiple SSL hosts on a single IP address) you will need to send the correct hostname in order to get the right certificate (-servername option is to enable SNI support).

Without SNI

If the remote server is not using SNI, then you can skip -servername parameter:

Openssl View Pem Certificate Sample

To view the full details of a site’s cert you can use this chain of commands as well:

For SMTP with starttls use:

For Client Auth protected resources use:

-prexit will return the data as well:

Verify TLS cert with private key

Hopefully you’re never in a situation where you don’t know what private key you used to generate your TLS certificate, but if you do… here’s how you can check.

Note: this is better than uploading the certs to production to check on them 😉

Assuming we have generated a private key named example.com.key and a certificate named example.com.crt we can use openssl to check that the MD5 hashes are the same:

To make things better, you can write a script:

Java Key store

Create

Create a development certificate with certstrap

Openssl View Pem Certificate Details

Create a development certificate with mkcert

Create a self-signed certificate with OpenSSL

The commands below and the configuration file create a self-signed certificate (it also shows you how to create a signing request).

View

Note: The Common Name (CN) is deprecated - the hostname will be matched against available names in the Subject Alternate Name (SAN) field. So enter the main hostname as CN and list it together with the rest of your DNS records in the SAN field.

The DNS names are placed in the SAN through the configuration file with the line subjectAltName = @alternate_names (there’s no way to do it through the command line). Then there’s an alternate_names section in the configuration file (you should tune this to suit your taste):

It’s important to put DNS name in the SAN and not the CN, because both the IETF and the CA/Browser Forums specify the practice. They also specify that DNS names in the CN are deprecated (but not prohibited). If you put a DNS name in the CN, then it must be included in the SAN under the CA/B policies. So you can’t avoid using the Subject Alternate Name.

If you don’t do put DNS names in the SAN, then the certificate will fail to validate under a browser and other user agents which follow the CA/Browser Forum guidelines.

Related: browsers follow the CA/Browser Forum policies; and not the IETF policies. That’s one of the reasons a certificate created with OpenSSL (which generally follows the IETF) sometimes does not validate under a browser (browsers follow the CA/B). They are different standards, they have different issuing policies and different validation requirements.

Create a self signed certificate

Notice the addition of -x509 option:

Create a signing request

Openssl Dump Pem File

Notice the lack of -x509 option:

Print a self-signed certificate

Print a signing request

Configuration file

Passed via -config option:

Current certificate best practices

  • Set lifetime lower than 398 days
  • Use SHA-256 instead of SHA-1
  • Use 2048 bit keys for now (4096 is still too resource intensive)

Certificate chain order

The correct order of a certificate bundle a.k.a certificate chain e.g:

is:

Web Server:

HTTP Client:

The following certificate chain issues can occur:

  • Missing intermediate certificates: When a site does not provide the necessary intermediate certificates, a trust path cannot be established. Generally speaking, one cannot distinguish that case from a certificate signed by a custom CA. However, some server certificates include the information on which intermediate certificates are required, and also where to obtain them. If the intermediate certificates are found, then it’s very likely that a trust path will be established. In such cases you should reconfigure the server to add the missing certificates.
  • Certificate chains that are too long: Sites often include more certificates in the handshake than necessary. Of those, most include one extra certificate, and that is the actual trusted root certificate (which browsers already have in their storage). This last certificate is not needed for the validation process. Having an additional certificate in the chain wastes bandwidth and decreases overal performance slightly. A small number of sites will include a very large number of certificates as a result of misconfiguration. Such sites will typically suffer significant performance issues and need to be reconfigured.
  • Certificates given in incorrect order: According to the standard, certificates must be presented in the order in which they are needed. The main, server, certificate must come first, followed by the certificate that signed it, followed by the next certificate in the chain, and so on. A small number of sites does not get this order right. Most SSL clients will deal with this problem silently, but there is a small number of platforms that will give up.

Streamlined CSR creation

To create web server certificates a CSR is required. Since many projects have their own CSR signing process, the following template can be used:

req.conf

  1. Customize the DN and the following lines:
  1. Then generate the CSR and corresponding key:
  1. If you already have a key and only need to renew a certificate, use the following command instead:

The generated CSR can be checked as follows:

The CSR can now be submitted for signing.

The private key remains in your possession. Note that the same private key will be used even if you’ve renewed a certificate. This is import for certificate pinning because it ensures that the certificate signature remains the same.

Bonus: fire and forget

Use the following script to skip having to remember the commands. Hardcode the keyname. The CSR will have the same base name.

renew.sh

Notes

You can also add -nodes (short for no DES) if you don’t want to protect your private key with a passphrase. Otherwise it will prompt you for “at least a 4 character” password.

Sources:

Openssl View Pem Certificate Template

How to verify that a private key goes with a certificate

Note: It should be noted that this is not a UW-Madison Help Desk or DoIT Middleware supported procedure, and, naturally, we can't take responsibility for any damage you do while following or attempting to follow these procedures. Be sure you understand what you are doing.

(Shamelessly stolen from (and expanding upon) The Apache SSL FAQ)

Openssl View Pem Certificate

The private key contains a series of numbers. Two of those numbers form the 'public key', the others are part of your 'private key'. The 'public key' bits are also embedded in your Certificate (we get them from your CSR). To check that the public key in your cert matches the public portion of your private key, you need to view the cert and the key and compare the numbers. To view the Certificate and the key run the commands:

The `modulus' and the `public exponent' portions in the key and the Certificate must match. But since the public exponent is usually 65537 and it's bothering comparing long modulus you can use the following approach:

And then compare these really shorter numbers. With overwhelming probability they will differ if the keys are different. As a one-liner:

And with auto-magic comparison (If more than one hash is displayed, they don't match):

BTW, if I want to check to which key or certificate a particular CSR belongs you can compute

Openssl Show Pem

See Also: