---
title: "Prepare Certificate and Private Key Files"
slug: "polarity-prepare-certificate-and-private-key-files"
updated: 2026-11-14T00:29:06Z
published: 2026-11-14T00:29:06Z
canonical: "knowledge.threatconnect.com/polarity-prepare-certificate-and-private-key-files"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://knowledge.threatconnect.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Prepare Certificate and Private Key Files

Prepare a PEM-encoded server certificate and its matching unencrypted PKCS#8 private key before replacing files in a running installation.

## Applies To

Certificate preparation for a standard Polarity Server v5 Docker deployment. The examples use OpenSSL 3.x command syntax. Run them in a protected staging directory on an administrative workstation or the server, using Bash. Do not run them in the live certificate directories.

## Before You Begin

Obtain the server certificate, its matching private key, and the issuing intermediate certificates from your CA. Obtain the approved root certificate separately for trust verification. Know the DNS name clients will use.

Keep originals unchanged. The examples write new files and can overwrite files with the same names, so use an empty staging directory and restrict its access. Set a restrictive creation mask before producing private-key files.

```bash
umask 077
```

A PEM certificate contains `BEGIN CERTIFICATE`. An unencrypted PKCS#8 private key contains `BEGIN PRIVATE KEY`. PKCS#8 describes the private key, not the certificate. A file containing `BEGIN PUBLIC KEY` or `BEGIN RSA PUBLIC KEY` is not an X.509 server certificate. Renaming it to `.crt` does not create one.

Use the conversion below that matches your input, then complete all verification steps. If your files already have the required format, go directly to verification.

## Normalize a Private Key

Place the input private key in `original.key`. This command accepts supported private-key input, writes unencrypted PKCS#8, and prompts for the input passphrase if needed. The output is sensitive even though it has no passphrase.

```bash
openssl pkcs8 -topk8 -inform PEM -in original.key \
  -outform PEM -nocrypt -out server.key
```

Do not print the private key to check its format. Validate it without displaying key material.

```bash
openssl pkey -in server.key -check -noout
```

If this prompts for a key passphrase, the file is still encrypted. Stop and normalize the intended input again. A successful key check establishes key consistency; it does not establish certificate trust or product support for that key algorithm.

## Convert an Existing Key at `/etc/pki/tls/private`

If your input key is staged as `/etc/pki/tls/private/server.key.orig`, use the following command with permission to read the input and write the output. The backslash must be the last character on each continued line; do not put a space after it.

```bash
openssl pkcs8 -topk8 -inform PEM -outform PEM -in \
/etc/pki/tls/private/server.key.orig -out \
/etc/pki/tls/private/server.key -nocrypt
```

Copy the validated result from these staging paths to the v5 installation destinations when ready.

## Convert a DER Certificate to PEM

Place the binary X.509 certificate in `certificate.cer`.

```bash
openssl x509 -inform DER -in certificate.cer \
  -outform PEM -out server-leaf.pem
```

Use `openssl x509` for the certificate. A private-key conversion command such as `openssl rsa` cannot convert an X.509 certificate.

## Convert RSA Public Key Encoding

To convert a PKCS#1 RSA public key to PEM SubjectPublicKeyInfo, place the input in `public_pkcs1.pem` and run the following command.

```bash
openssl rsa -RSAPublicKey_in -in public_pkcs1.pem -pubout -out public-key.pem
```

The output contains `BEGIN PUBLIC KEY`. It is a public-key file rather than the X.509 certificate required by the web TLS loader. If this is the only public file you received, obtain the matching issued certificate before continuing to installation.

## Extract a Certificate and Key From PFX

Use this procedure for a PFX containing one server identity. Place it in `server.pfx`. If it contains multiple identities, have the certificate administrator select and export the intended identity before continuing.

1. Extract the non-CA certificate, then re-export it as a clean PEM certificate. Enter the PFX import password when prompted.

```bash
openssl pkcs12 -in server.pfx -clcerts -nokeys -out leaf-export.pem
openssl x509 -in leaf-export.pem -outform PEM -out server-leaf.pem
```
2. Extract the private key to an encrypted intermediate file. Enter the PFX import password and choose a temporary PEM passphrase when prompted.

```bash
openssl pkcs12 -in server.pfx -nocerts -out key-export.pem
```
3. Normalize that key to the unencrypted PKCS#8 file used for installation. Enter the temporary PEM passphrase when prompted.

```bash
openssl pkcs8 -topk8 -inform PEM -in key-export.pem \
  -outform PEM -nocrypt -out server.key
```
4. Extract the CA certificates for review.

```bash
openssl pkcs12 -in server.pfx -cacerts -nokeys -out ca-export.pem
```

The CA export can contain metadata and multiple certificates. Have the certificate administrator identify each certificate and provide separate clean PEM files in issuer order. Do not assume the first certificate in a combined PFX export is the server certificate, or install the combined export as a private-key file. For unsupported legacy PFX encryption, obtain a compatible export from the certificate administrator rather than changing the server's cryptographic policy. See the [OpenSSL PKCS#12 reference](https://docs.openssl.org/3.0/man1/openssl-pkcs12/).

## Verify the Certificate and Key

1. Inspect the leaf certificate's identity, issuer, dates, and SANs.

```bash
openssl x509 -in server-leaf.pem -noout \
  -subject -issuer -dates -ext subjectAltName
```

Confirm that the intended DNS name or IP address appears in the appropriate SAN entry. Stop if the certificate is for another system.
2. Check the private key.

```bash
openssl pkey -in server.key -check -noout
```
3. Compare the public component of the private key with the public key in the certificate. Run each command only after the preceding command succeeds.

```bash
openssl pkey -in server.key -pubout -outform DER -out key-public.der
openssl x509 -in server-leaf.pem -pubkey -noout > certificate-public.pem
openssl pkey -pubin -in certificate-public.pem \
  -outform DER -out certificate-public.der
cmp key-public.der certificate-public.der
```

`cmp` must exit with status zero. Different output files mean the key and certificate do not match. This comparison avoids RSA-only modulus checks and does not print the private key.
4. Verify the chain and DNS identity. Replace `polarity.example.test` with the real client-facing DNS name. Put the approved trust root in `root-ca.pem` and the intermediate certificates, closest issuer first, in `intermediates.pem`.

```bash
openssl verify -purpose sslserver \
  -verify_hostname polarity.example.test \
  -CAfile root-ca.pem -untrusted intermediates.pem server-leaf.pem
```

If the root directly issued the leaf, omit `-untrusted intermediates.pem`. For an IP connection, use `-verify_ip` with the IP address instead of `-verify_hostname`. Success must report the leaf as `OK` and exit with status zero. This check does not perform a complete revocation assessment or establish client workstation trust.

## Assemble the Server Chain

Combine the server certificate and its CA chain in order from the most specific certificate to the least specific certificate. In the three-certificate example, `cert1.crt` is the server leaf, `cert2.crt` is its issuing intermediate CA, and `cert3.crt` is the root CA. Add further intermediates between the leaf and root in issuer order when needed.

For staging, combine them without writing to the running installation.

```bash
cat cert1.crt cert2.crt cert3.crt > server-fullchain.pem
```

The web service loads this combined chain from `server.crt`. The platform uses its separate certificate file and CA-loading process. Preserve those separate destinations; do not replace them with one shared loading assumption.

The installation inputs are `server-leaf.pem`, `server-fullchain.pem`, and `server.key`, plus the separate CA certificates. Continue to [Install or Replace a Server Certificate](/docs/polarity-install-or-replace-a-server-certificate). Keep PFX exports and intermediate key files protected until your retention policy permits their removal.