[.pem/.crt] Why are certificate and private key extensions sometimes different?

Hello everyone.
I'm Nakano from the Systems Solutions Department, and I tend to sleep for about 12 hours on my days off.
I really envy short sleepers.

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

In the article below, I have specified the file extensions used in the section titled "File extensions used in this article."
This is a preface written because "the file extensions for certificates and keys can vary depending on the environment and the person."

How to check certificate integrity and verification results with the openssl command and options

"Why do certificates and private keys sometimes have different file extensionsmight lead some to wonder,
I'd like to explain the reasons why they can be different, including the types of file extensions and data formats.

"Howshould I respondI also considered some personal strategies for dealing with the issues that make me wonder,

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)
  Language setting changed 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

Some files might be consistently formatted as ".pem" and ".der," while others might be formatted as ".crt" and ".key," etc.
It's possible they're 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

Base64 is a data representation method that uses uppercase and lowercase letters and numbers;
in short, it converts data into a string (text).

The PEM format is structured with the strings "-----BEGIN (Name of contents)-----" at the beginning and
"-----END (Name of contents)-----" at the end, with
the binary data of the contents represented 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

, Apache 2.4.8 and later versions have a single document that combines the certificate and intermediate certificatethe previous articleexplained in

One advantage of the PEM format is that it allows you to combine certificates, intermediate certificates, and private keys into a single file.
*However, the order of merging 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 digital certificate standard established by the ITU, but
currently it 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

The .crt extension is commonly used in Linux environments, and
is used when certificate authorities such as Digicert issue certificates for Apache + OpenSSL configurations.

The .cer extension is commonly used in Windows environments and
is sometimes used when certificates are issued by certificate authorities such as Digicert for Microsoft IIS configurations.

Conventionally, file extensions differ depending on the environment,
but the format of the data inside, whether DER (binary) or PEM (text), is irrelevant regardless of the extension.

.key

This is a commonly used extension for private keys

you generally won't touch it during the update process,
it's common practice to use ".pub" for public keys to distinguish them from private keys.

.ca

This is a commonly used extension for intermediate certificates

However, there are cases where .cer is used for intermediate certificates when .crt is the certificate extension,
so my impression is that it's not as conventionally used as certificate extensions.

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

These technically fall under the category of "extensions that represent the content," but they
are not supported by many software programs and 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 certificate-related standards, and
files conforming to these standards have the extensions .p7b and .p12.
(Strictly speaking, PKCS#12 also has extensions like .pfx, but these will be omitted from this explanation.)

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

because they are supported by Microsoft IIS, the web server for Windows
formats are 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 use of different file extensions unintentionally because the person performing the task is different from the usual one, or
because the default file extensions issued change due to a change in the certification authority.

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's common for the person responsible for setting up the environment and the person responsible for operating it to be different,
the person responsible for issuing certificates and the person responsible for renewing them can 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 operational setup, the person handling SSL certificate issuance might be an office worker who
doesn't even have access to the configurationfile. Therefore, I personally believe it's a good idea to establish general rules and document them.

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, changing the file extension of an image file (.jpg) to ".txt"
only means that "the software will interpret it as text data and open it," but
the JPEG data inside does not actually change to text data.

, allowing them to be rewritten as neededFile extensions are something that can be set arbitrarily

In short, certificates and similar documents only have a defined data structure as a standard;
their file extensions are not strictly defined.

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 provides a GUI environment on Linux,
that software may add a function to recognize and determine file extensions.

lastly

I started writing this article by casually digging into some tips from a previous article, but
it turned out to be much more difficult to explain than I imagined, and it required a lot of prerequisite knowledge.

This explanation has become quite long, but to reduce confusion in the field,
I think it's sufficient to simply have the understanding that "let's keep the file extensions 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's official website / [CertCental] Server Certificate Installation Procedure
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
*Although section 5.3 mentions file extensions,
that "they merely indicate widely used de facto alternatives,"
suggesting that they are not strictly defined within the standard.