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

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

This time, it is a derivative of the article "Checking the SSL certificate with openssl command" that I wrote earlier.

In the article below, we have specified the extensions used in the description ``◯Extensions used in this article.''
This is a preface that I wrote 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

, you may be wondering,
" Why are there different extensions for certificates and private keys " I'd like to explain why there are different extensions, including the types of extensions and data formats. I would like to explain this to you.

I also tried to think of personal countermeasures for the issues that I was worried about, ` ` 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 settings to Japanese

"Extension that represents the encoding format" and "Extension that represents the content"

If the site or environment changes, the extension of the SSL certificate or private key used may change.

They may be unified by ".pem" and ".der", or separated by ".crt" and ".key", etc.,
or they may be mixed.

This is because, as in the heading, there is an ``extension that represents the encoding format (.pem) (.der)'' and an ``extension that represents the content (.crt) (.key).''

"Extension indicating the encoding format" (.pem)(.der)

This is an extension that represents the format of encoding (encoding/conversion).

Therefore, if a certificate or private key is commonly used, it is necessary to judge by the file name and contents.

".pem" is the extension that indicates the PEM format encoding format, and ".der" is the extension that indicates the DER format encoding format.

We will explain these common encoding formats.

DER

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

This DER format is one of the formats that converts data that follows that notation into binary data.

It seems that some software with older specifications only supports DER format certificates.

It is often used on Windows (OS side).

PEM

The commonly used PEM format is the Base64 encoded version of the DER format above.

Base64 format is a data representation method that uses uppercase and lowercase letters of the alphabet and numbers, and
essentially converts data into character strings (text).

PEM format is delimited by the character string "-----BEGIN (name of content)-----" at the beginning and
"-----END (name of content)-----" at the end. ,
in between, the binary data expressed in Base64 is written.

Base64 has the following advantages.

・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 and editing and checking is not easy.

・Can be connected

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

I explained in the previous article that since Apache 2.4.8, there are certificates and intermediate certificates that are integrated

The advantage of the PEM format is that you can combine certificates, intermediate certificates, and private keys in one file.
*However, the order of joining is fixed.

PEM format is the default setting for "openssl", an 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

There is a public key infrastructure standard called X.509, and certificates basically comply with this standard.

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

X.509 is a digital certificate standard originally established by the ITU, but
now refers to the RFC5280 standard profiled by the IETF.

"Extension that represents the contents" (.crt) (.key) etc.

It is an extension when expressing the content (role).

*Since the extension is relatively free, there are multiple extensions.

.crt/.cer

This is the extension used to represent a certificate.

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

.cer is often used in Windows environments, and
may be used when issued by a certificate authority such as digicert for Microsoft IIS configuration.

Conventionally, the extension is different depending on the environment, and
it doesn't matter whether the data is in DER (binary) or PEM (text) format regardless of the extension.

.key

This is an extension commonly used to represent private keys.

Although it is basically not touched during update work,
it is common to use ".pub" for public keys to distinguish them from private keys.

.ca

This is an extension often used to represent intermediate certificates.

my impression is that it is not as common as the certificate extension, as there are cases where .crt is used as a certificate and .cer is used as an intermediate certificate.

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

Although these are included in the category of "extensions that represent contents,"
many software do not support them, and they are generally not used frequently in Linux environments.

We decided to separate them because it would be difficult to understand if they were explained under the same headings.

*Also used on macOS.

P.K.C.S.

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, there are extensions such as .pfx for PKCS#12, but we will omit them for explanation.

It is not a standard that defines certificates, but rather a data format that stores (containers) certificates.

formats are often used in Windows Server environments because they are supported by Microsoft IIS, the Windows Web server

It is also possible to convert to PEM format etc. using OpenSSL commands.

.p7b

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

It is possible to combine a certificate and intermediate certificate (+ root certificate) into one.

.p12

This certificate is created using the encryption standard PKCS#12.

It is now possible to store the private key in a certificate in one file.

However, it is a specification that you need to set a password before using it.

Mixed extension problem

unintentionally using an extension with a different nature because the worker was a different person than usual, or
the extension issued by default changed due to a change in the certification authority. occurs.

It's not a big problem, but it's a little troublesome for the operator when extensions are mixed.

This is because while it is common for the person in charge of building the environment to be different from the operator,
the person responsible for issuing the certificate and the person responsible for updating it may also be different.

Therefore, if the extensions are mixed, the following may occur.

• If the extensions are different in the environment, you need to check the specified file name in conf each time.
• There is a possibility that you may think that there is an intention with the related software and check with the person responsible for issuing the issue.
• Looks bad (subjective)

How should we respond?

Unified rules by stipulating that ``use extensions that represent the contents''

It would be a good idea to explicitly state the extension to be used in the "operation rules" or "environment document".

Depending on the operation, the person in charge of issuing SSL certificates may be an office worker and
not be able to see the conf in the first place , so I personally think it would be better to establish a general rule and document it. I think.

Side note: Why are there multiple extensions in the first place?

In the first place, the extension is a name used by the software to identify the file format, and is not an absolute name.

This is a software concept, not a data standard or specification.

Of course, even if you change the extension of image data (.jpg) to ".txt",
the software will only interpret it as text data and open it,
which means that the JPEG data inside will change to text data. Not.

An extension is something that can be set arbitrarily so that it can be rewritten at will

In short, the data structure of certificates, etc. is only specified as a standard, and
the extension is not strictly specified.

Tips: The concept of extensions does not exist in Linux in the first place

In Linux, file formats are not identified by extensions, in other words, there is no concept of extensions.

In Linux, users (humans) add extensions to file names for administrative identification and convenience.

The concept of "extension" is not absolute, and the specifications vary greatly depending on the OS.

*When installing software that creates a GUI environment on Linux,
a function may be added to the software to recognize and judge the extension.

lastly

I casually started digging into the Tips section of the previous article, but it turned out to be
more difficult to explain than I had imagined, and it required a lot of prerequisite knowledge.

Although the explanation is long,
I think it would be good if people were aware of the fact that the extensions should be the same

I hope this article provides some useful knowledge 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 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
*Section 5.3 mentions file extensions, but
``clarifies the widely used de facto alternatives.'' (Japanese translation)"
is written at the end, and it does not seem to be strictly specified in the standard.