[.pem/.crt] Why are the extensions of certificates and private keys different?

Hello everyone.
I work in the System Solutions Department and I sleep about 12 hours on my days off.
I admire short sleepers.

This article is a spin-off of the previous one, "Checking SSL certificates with the openssl command."

In the article below, we have clearly stated the extensions used in the section "◯ Extensions used in this article."
This is a preface written because "certificate and key extensions may differ depending on the environment and person."

How to check certificate integrity and verification results with openssl command/option explanation

Some people may wonder why the extensions of certificates and private keys are sometimes different, so we would like to explain why they are different,
including the types of extensions and data formats.

I also thought about some personal solutions to the issues that make people wonder, " How should I respond

Execution environment

• Linux environment
  OS:AlmaLinux release 8.5 (WSL2 environment)
  Shell:Bash
  OpenSSL 1.1.1k FIPS 25 Mar 2021
• Windows environment
  OS: Windows 11 Pro (version: 22H2)
  Change language setting to Japanese

"Extensions that indicate the encoding format" and "Extensions that indicate the contents"

If the site or environment changes, the extensions of the SSL certificate and private key used may change

They may be unified as ".pem" or ".der", or divided into ".crt" and ".key", etc. -
perhaps they are all mixed together.

This is because, as mentioned in the title, there are extensions that indicate the encoding format (.pem, .der) and extensions that indicate the contents (.crt, .key)

"Extensions that indicate the encoding format" (.pem) (.der)

This is an extension used to indicate the encoding (coding/conversion) format

Therefore, if it is commonly used for certificates and private keys, you will need to determine it by its file name and contents

The ".pem" extension indicates that the file is encoded in PEM format, and the ".der" extension indicates that the file is encoded in DER format

We will explain these common encoding formats

DER

ASN.1 is a standard notation for defining data structures when communicating over a network

The DER format is one of the formats that converts data that follows this notation into binary data

It seems that some older software only supports DER format certificates

It is commonly used on Windows (OS side)

PEM

The commonly used PEM format is the Base64 encoding of the DER format above

The Base64 format is a data representation method that uses uppercase and lowercase letters and numbers,
essentially converting data into a string (text).

The PEM format begins with the string "-----BEGIN (name of content)-----"
and ends with the string "-----END (name of content)-----",
with the binary data of the contents expressed in Base64 written between them.

The use of Base64 provides the following benefits:

Easy to edit

Since it is text data, it can be easily displayed and edited using a text editor

In the case of DER, a binary editor is required, making editing and checking difficult

・Can be connected

The distinctive feature of this delimited format is that multiple pieces of data can be stored in one file

the previous article , we explained that from Apache 2.4.8 onwards, certificates and intermediate certificates are integrated

The advantage of the PEM format is that it allows you to combine the certificate, intermediate certificate, and private key in one file.
*However, the order in which they are combined is fixed.

The PEM format is the default setting for "openssl", the SSL software commonly used on Linux

Therefore, it is a container format that can store multiple data in a format that is common in Linux environments

Tips: Certificate standards

Certificates are basically based on a public key infrastructure standard called X.509

The ANS.1 notation is the format used to define the data structures specified in this standard

X.509 was originally a standard for digital certificates established by the ITU, but
now refers to the RFC5280 standard profiled by the IETF.

"Extensions that represent the contents" (.crt) (.key), etc

This is an extension used to indicate the contents (role)

*There is a fair amount of freedom when it comes to extensions, so there are multiple types

.crt /.cer

The extension used to represent the certificate

.crt is commonly used in Linux environments, and
this extension is used when issued by a certification authority such as digicert for an Apache + OpenSSL configuration.

.cer is commonly used in Windows environments and
is sometimes used when issued by a certificate authority such as Digicert for Microsoft IIS configurations.

Conventionally, the extension differs depending on the environment,
but regardless of the extension, the data inside can be in DER (binary) or PEM (text) format.

.key

This is a commonly used extension for private keys

This is not generally touched during the update process, but
it is common to use ".pub" for public keys to distinguish them from private keys.

.ca

This is a commonly used extension for intermediate certificates

However, the author's impression is that there are cases where .crt is used for the certificate and .cer is used for the intermediate certificate, so it
is not as commonly used as certificate extensions.

+α: Extension representing the certificate (.p7b) (.p12)

These are categorized as "extensions that indicate content," but
many software programs do not support them, and they are generally not used frequently in Linux environments.

We have separated them because we felt that explaining them under the same heading would be difficult to understand

*It is also used on macOS

PKCS

There is a set of public-key cryptography standards called PKCS (Public-Key Cryptography Standards)

PKCS#7 and PKCS#12 are standards related to certificates, and
the extensions for those standards are .p7b and .p12.
*Strictly speaking, PKCS#12 also has extensions such as .pfx, but we will not explain them here.

It is not a standard that defines certificates, but rather defines the data format for storing (container) certificates

These formats are supported by Microsoft IIS, a Windows web server, and
are therefore often used in Windows Server environments.

It is also possible to convert it to PEM format using OpenSSL commands

.p7b

This is a certificate created using the PKCS#7 encryption standard

It is possible to combine the certificate and intermediate certificate (plus root certificate) into one

.p12

This is a certificate created using the PKCS#12 cryptographic standard

This allows the certificate and private key to be stored in a single file

However, you will need to set a password to use it

Mixed file extensions issue

as the worker being different from usual and unintentionally using an extension with a different nature, or
the certificate authority changing and changing the extensions issued by default.

It's not a big problem, but it can be a bit of a hassle for the worker when file extensions are mixed

This is because, while it is common for the person responsible for setting up the environment and the person who operates it to be different,
the person who issues the certificates and the person who updates them may also be different.

Therefore, if the file extensions are mixed, the following may occur:

• If the file extensions are different in the environment, you need to check the specified file name in conf each time
• I think there may be some intention behind the software involved, so I'll check with the person in charge of issuing it
• It looks bad (subjective)

How should we respond?

The rule was established to standardize the use of file extensions that represent the contents

It is recommended that you explicitly state the extensions you will use in the "Operational Rules" or "Environment Documentation"

Depending on the operation, the person issuing the SSL certificate may be an office worker who
may not even be able to see the conf file , so I personally think it would be better to set this as a general rule and put it in writing.

Aside: Why do multiple file extensions exist in the first place?

In the first place, extensions are names used by software to identify file formats, and are not absolute

It is merely a software concept, not a data standard or specification

Obviously, even if you change the extension of image data (.jpg) to ".txt",
the software will simply interpret it as text data and open it, but
the JPEG data inside will not change into text data.

The extension can be set arbitrarily so that it can be rewritten at will

In short, the data structure of certificates and other documents is simply defined as a standard, and
the file extension is not strictly specified.

Tip: The concept of file extensions doesn't exist in Linux

In Linux, file formats are not identified by extensions in the first place; in other words, the concept of extensions does not exist

In Linux, it is the user (human) who adds extensions to file names for management identification and convenience

This is an example of how the concept of an "extension" is not absolute, and specifications vary greatly depending on the OS

*When installing software that creates a GUI environment on Linux,
the software may add a function to recognize and distinguish file extensions.

lastly

I started writing this article by casually digging deeper into the tips from my previous article, but
it was more difficult to explain than I expected, and it required a lot of prerequisite knowledge.

This explanation has become quite long, but in order to reduce confusion in the field,
I think it would be good to have the understanding that "we should make sure the extensions are consistent."

I hope this article will be of some use to those who read it

Reference materials

Let's Encrypt official documentation / Welcome to ASN.1 and DER
https://letsencrypt.org/ja/docs/a-warm-welcome-to-asn1-and-der/

Digicert official website / [CertCental] Server certificate installation instructions
https://knowledge.digicert.com/ja/jp/solution/SOT0002.html

RFC 5280
https://www.rfc-editor.org/rfc/rfc5280

ITU-T Recommendations
https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=X.509

RFC 7468
https://www.rfc-editor.org/rfc/rfc7468#section-5.3
*File extensions are mentioned in section 5.3, but
"They merely clarify the de facto alternatives that are in widespread use." This
does not seem to be a strict specification within the standard.