Differences between .pfx, .p12, .cer and .crt explained in detail

If you've come here looking for the Differences between .pfx, .p12, .cer and .crtYou've probably already encountered more than one strange file when installing a digital certificate or SSL on a server. You're not alone: ​​between acronyms, extensions, and formats, it's easy to get confused and not know what each file does or which one you need in each case.

The good news is that, although the names may seem intimidating, all of this can be explained quite simply if we understand that all these files are nothing more than certificate and key containers in different formats (text or binary) and designed for different systems (Windows, Linux(Java, browsers, etc.). We'll look at them one by one, calmly, and relate them to each other so you know exactly what each thing is, what it's for, and how to use or convert them when necessary.

What is a digital certificate and how do .pfx, .p12, .cer and .crt fit together?

A digital certificate is nothing more than a electronic document signed by a Certification Authority (CA or, according to the eIDAS regulation, a Qualified Service Provider) that links an identity to a public key. That identity can be a person, a company, a web server, a domain, etc.

To achieve this connection, the following is used: public-key or asymmetric cryptographyThere is a pair of keys: a public key (which anyone can know) and a private key (which only the owner should have). What is encrypted with the public key can only be decrypted with the private key, and vice versa, allowing for authentication, encryption, and electronic signatures.

Behind all these certificates there is a public key infrastructure or PKIwhich includes the certification authority, registration authorities, certificate repositories, certificate revocation lists (CRLs), and, in many environments, a timestamp authority (TSA) to record when something was signed.

The internal structure of the vast majority of general-purpose certificates follows the standard X.509, defined by the ITU and described in detail in RFC 5280. This standard defines fields such as version, serial number, signature algorithm, issuer, validity period, subject, holder's public key and possible additional extensions.

Regarding the algorithms, certificates typically use asymmetric cryptography with RSA, DSA or ECDSARSA and ECDSA serve for both signing and encryption, while DSA focuses on digital signature signing and verification.

Internal formats and extensions: PEM, DER, CER, CRT and company

When we talk about extensions like .cer, .crt, .pem, .der, .pfx, .p12 or .p7bIn reality, we are mixing two concepts: the encoding format of the certificate (Base64 text or binary) and the function that the file has (certificate only, certificate + private key, certificate chain, etc.).

At the internal format level, X.509 certificates are represented with ASN.1 and are normally encoded with DER (binary) or its textual variant PEM (DER converted to Base64 and wrapped with headers like BEGIN/END). From there, different systems and standards have defined specific containers such as PKCS#7 (.p7b) or PKCS#12 (.pfx, .p12).

The key to avoiding confusion is to remember that the file extension is often just one naming conventionA .cer file or a .crt file can contain exactly the same thing, only one is used more in Windows and the other in Unix/Linux environments, to give an example.

Within this general group, there are some key formats These are important to understand clearly, because they are the ones you will encounter all the time when working with SSL/TLS or personal certificates.

PEM format: the “readable text” of certificates

The PEM format is by far the most common for SSL/TLS certificates on servers like Apache or Nginx and in most security tools. A PEM file is simply a DER recoded in Base64 and surrounded by text headerswhich allows you to open and copy it with any editor (Notepad, nano, vim, etc.).

A PEM is recognized because its content is delimited by lines like —–BEGIN CERTIFICATE—– y —–END CERTIFICATE—– when it contains a certificate, or —–BEGIN PRIVATE KEY—– y —–END PRIVATE KEY—– when it contains a private key. Everything in between is a Base64 string representing the original binary data.

In a single PEM file you can have only the certificateThe certificate plus the intermediate CA chain, the private key separately, or even the entire package (private key, server certificate, intermediate certificates, and root certificate) can be supplied. Certificate signing requests are also provided in PEM. CSRwhich are nothing more than PKCS#10 structures recoded into text.

This format was originally defined in RFCs 1421-1424 as part of the Privacy-enhanced Electronic Mail project, which didn't catch on for email, but left behind an excellent text format for transport cryptographic data in a comfortable, legible and easy to copy/paste format.

In practice, files with extensions .pem, .crt, .cer or .key In Unix/Linux systems, they are usually PEM files. Typically, .key contains the private key, .crt or .cer contains the server certificate, and sometimes an additional PEM file includes the intermediate CA chain.

DER format: the pure and simple binary

DER (Distinguished Encoding Rules) is the binary encoding format of the ASN.1 structures that describe an X.509 certificate. It is not text, so if you open it with an editor you will see strange characters instead of the typical Base64 string.

A DER file can contain any type of certificate or private keyIt is typically identified by the .der or .cer extensions, especially in Windows environments or on Java platforms. On Windows, a .der file is directly recognized as a certificate file and opens with the native viewer when double-clicked.

The practical difference with PEM is that, while PEM can be easily copied and emailed or pasted into web forms, DER is a closed binary blob Designed for direct consumption by applications. Internally, however, the information is the same: a PEM is nothing more than a DER re-encoded into Base64 text.

Tools like OpenSSL allow you to switch from DER to PEM and vice versa with a single command, without altering the logical content of the certificate at all, only its form of representation.

.cer and .crt extensions: same dog with a different collar

The .cer and .crt extensions are used to designate files containing public certificates, usually in PEM or DER format, depending on the system in which they are generated or installed.

In cases, a .crt file on an Apache server will be a certified in PEM surrounded by the BEGIN/END CERTIFICATE headers and ready to be pasted into a configuration block. In Windows, a .cer file can be either PEM or DER, although it typically falls into either category depending on the tool that generated it.

The important thing to understand is that the extension doesn't strictly define the internal format: a .cer file can be PEM text or DER binary, and a viewer or utility like OpenSSL will determine how to read it. In browsers and Windows systems, double-clicking will open the... certificate viewerwhere you can see the issuer, subject, validity dates, key usage, etc.

When you export a certificate without a private key from a browser or the Windows certificate store, you will normally get a .cer file, which is used for validate signatures, trust chains, or encrypt informationbut never to sign on behalf of the owner (for that you need the private key, which is separate or inside a protected container).

CSR, KEY, CA and intermediate files: the other files that accompany the certificate

When you process an SSL certificate or a personal certificate, you won't just see .pfx, .p12, or .cer files. The entire process also involves files like .csr, .key or CA certificates (root and intermediates), which are equally important for everything to work.

The request for signature or CSR (.csr) It's a file you typically generate on the server where the SSL certificate will be installed. It contains the public key, domain name, organization, country, and other information the certificate authority will use to issue the certificate. It follows the PKCS#10 standard and is usually encoded in PEM so you can copy and paste it into the provider's form.

The private key or KEY (.key) This is the file where the secret key associated with the certificate is stored. It is usually in PEM format, delimited by BEGIN PRIVATE KEY and END PRIVATE KEY. It is an extremely sensitive file that should not be shared or uploaded to public repositories, and in many cases, it is additionally password-protected.

The file of CA or certificate of authority It contains the public key of the entity that issues or mediates the certificate. Browsers and OS They come with a default list of trusted CAs, but sometimes you need to install intermediate certificates to complete the chain of trust so that clients can validate your server's certificate without errors.

These intermediate certificates can be supplied as PEM files (.pem, .crt, .cer) or within a container such as .p7bIn hosting configurations, it is very common to be asked for the CRT (domain certificate), KEY (private key) and CA or intermediate certificate files to properly install SSL.

PKCS#7 / P7B: certificate chain without private key

PKCS#7, usually represented with extensions .p7b or .p7cIt is a format designed to group one or more certificates into a structured container, without including the private key. It is commonly used for distribute certificate chains (server certificate plus intermediate ones) in Windows or Java environments (Tomcat, keystore, etc.).

A .p7b file is typically encoded in Base64 ASCII, similar to a PEM file, and was originally defined in RFC 2315 as part of the public-key cryptography standards. Today, its successor is CMS (Cryptographic Message Syntax), but the name PKCS#7 is still widely used in the SSL certificate world.

This format is very useful when you need install the entire chain of trust on a server or in a system that manages certificates through a store (for example, the Java keystore). Typically, an SSL provider will deliver the server certificate on one hand and a .p7b file with the entire CA chain on the other, or a single .p7b file containing everything.

If you want to convert a .p7b file to PEM, tools like OpenSSL allow you to extract the certificates with a single command and save them to one or more text files. You can then separate the BEGIN/END CERTIFICATE blocks if you need to upload them separately to your server.

It is important to note that a PKCS#7 file never contains the private keyTherefore, by itself it is not useful for signing or decrypting: it only provides the public part of the certificate chain to validate trust.

PKCS#12: What exactly are .pfx and .p12?

The PKCS#12 standard defines a password-protected binary container that can include public certificates, complete CA chains, and the private key associated. The most common extensions for this format are .pfx and .p12, which are practically equivalent.

Historically, PKCS#12 began as a format closely tied to Microsoft, but with There It was standardized in RFC 7292 and is used today in all types of systems, precisely because it allows securely transport the certificate + private key pair from one team to another.

In the Windows world, when you export a "private key" certificate from the user or machine certificate store, the wizard generates a .pfx (or .p12) file that includes everything you need to import it into another system: private key, certificate holder, and usually the intermediate chain.

During the creation or export of a PKCS#12 file, the system will ask you to specify a password protectionThis password will be required later to import the file into another browser, IIS, an email client, or even another operating system. This way, if someone steals the .pfx file, they won't be able to use it without knowing that password.

Tools like OpenSSL allow you to convert a .pfx or .p12 file to PEM, so you get a text file where you can easily locate the private key block, the server certificate, and the intermediate certificates, and copy them where appropriate (for example, in a hosting panel that only accepts CRT, KEY, and CA separately).

Renewal, export and import of .pfx and .p12 certificates

In the area of ​​personal certificates (for example, those issued by the FNMT or other authorities for identification purposes), the way to back them up and renew them is closely linked to the use of .pfx or .p12 files, which travel on cryptographic cards, tokens USB or directly as protected files on the computer.

If your personal certificate has not yet expired, many authorities allow Renew it online: renewal is enabled from the registration point (professional association, company, certification service provider, etc.) and you receive a link by email to complete the process from your own computer.

However, if the certificate has already expired, you will normally have to go in person Go to that same registration point with your cryptographic card or device where the expired certificate is stored, identify yourself and request a new issuance, which you can again export in .pfx or .p12 format to import wherever you need it.

In browsers like Edge or ChromeThe import process goes through the Windows certificate storeFrom the privacy and security settings, you can open the certificate manager, select the Personal tab, and import a .pfx or .p12 file. The wizard will ask for the container password and offer to mark the key as exportable for future backups.

If instead of a .pfx file you have a .cer file without a private key (certificate icon without a key), that file is only useful for install the public certificate (it appears under “Other people”), but not for signing or authenticating. In that case, you won't be able to retrieve the private key from there, and if you don't have another valid copy, the only option will be to request a new certificate.

How these formats are used in server SSL certificates

In day-to-day work with web servers, VPNWhether using proxies or Java applications, the different certificate formats used depend on the system and the type of installation. Setting up Apache on Linux is not the same as setting up IIS on Windows or Tomcat on Java.

In Unix/Linux environments (Apache, Nginx, HAProxy, etc.) it is normal to work with PEM files separate files: one for the private key (.key), another for the server certificate (.crt or .cer), and sometimes yet another with the intermediate CA string. All of these are referenced in the server configuration to establish TLS.

On Windows platforms (IIS, remote desktop services, etc.) it is very common to be asked for a .pfx or .p12 containing both the certificate and the private key and the chain. The import wizard takes care of placing each piece in its corresponding store, so you don't have to worry about the internal details.

In Java environments (Tomcat, applications with their own keystore) stores of the type JKS or PKCS#12In many cases, a .pfx file is imported directly, or .p7b certificates are used to configure the chain of trust within a keystore, depending on the tool and Java version.

When you purchase an SSL certificate from a third-party provider, you may receive various file combinations: a CRT + CA file in PEM format, a .p7b file containing the string, or even a pre-prepared .pfx file. The key is to identify the correct file type. Where is the private key? (if it comes with you and is not generated by the server) and what file contains the server certificate and the intermediate chain.

In hosting control panels, you'll typically be asked to fill in fields for the CRT, KEY, and optionally, the CA or intermediate certificate. If you only have a .pfx file, you can convert it to PEM using OpenSSL and extract each block from there, carefully copying from BEGIN to END of each type.

Conversion between certificate formats with OpenSSL

Once you understand what each file is, the next logical step is to know how to convert them When the server or application requests a format different from the one provided by your ISP or CA, the standard tool for this is OpenSSL, available in most Linux distributions and also installable on Windows.

For example, if you have a certificate in DER (.der, .cer) And if you need to convert it to PEM, a single command that takes that binary and re-encodes it to Base64 with the appropriate headers would suffice. Similarly, you can transform a PEM to DER if your system only accepts binary.

With a PKCS#7 (.p7b) file, you can use OpenSSL to extract the certificates in PEM format with a simple command that prints the contained certificates and saves them to a text file. From there, you separate the different BEGIN/END CERTIFICATE blocks if you need individual files.

In the case of PKCS#12 (.pfx, .p12), OpenSSL allows you to convert the container to a PEM file containing the private key and all certificates. During the process, you will be prompted for the container password and can choose whether to leave the private key encrypted or in plain text within the PEM file, depending on its intended use.

These types of conversions make possible scenarios such as uploading a .pfx file to a Linux server, converting it to PEM, and then separate CRT and KEY to fill out an SSL installation form that does not directly support PKCS#12 containers.

In addition to direct DER↔PEM, PEM↔PKCS#7, PKCS#7↔PKCS#12 and PKCS#12↔PEM conversions, the same utility can generate CSRs, manage keys, inspect certificates and check expiration dates, making it a basic tool in any environment that works with certificates.

Types of digital certificates and areas of use

Beyond the file format, it's also helpful to be clear about the types of certificates depending on their use or the type of entity they represent, as that influences how their backups, renewals, and installations are managed.

At the European regulatory level (eIDAS Regulation), a distinction is made between "Simple" electronic certificates and qualified certificatesThe former meet basic identification and issuance requirements, while the latter demand stricter identity verification processes and more rigorous technical and organizational conditions from the provider. A clear example in Spain would be the electronic ID card (DNIe).

If we look at who the holder is, we can have certificates of natural person, legal person or entity without legal personalityEach one is used to sign or authenticate in different areas: personal procedures, dealings on behalf of a company, or tax obligations, respectively.

In the world of web servers, the most well-known certificate family is that of SSL/TLS certificatesThese certificates are installed on servers to encrypt the communication channel with users. They include variants such as single-domain, wildcard, and multi-domain (SAN) certificates, which differ in the number of names they cover and their level of validation.

Regardless of the type, all these certificates can end up being stored and distributed in the same formats: .cer, .crt, .pem, .p7b files or .pfx/.p12 containers, depending on the system where they will be used and the method chosen to transport or back them up.

The usefulness of digital certificates is enormous: They ensure confidentiality and authenticity of communications, they allow legally valid electronic signatures, simplify administrative and commercial procedures, and make it possible for multiple network services to function securely without the user having to worry about cryptographic details.

At this point, it's clear that extensions like .pfx, .p12, .cer, or .crt are simply different ways of packaging the same thing: an X.509 certificate, a private key, and, where applicable, a chain of trust, which, depending on the environment, are represented as Base64 text, DER binary, or PKCS containers to facilitate installation and deployment. transport between systems.