Converting a PFX to PEM for NetScaler, without OpenSSL on your desk

The renewed certificate arrives as a .pfx: exported from a Windows server, from IIS, or straight from the certificate authority’s portal. A NetScaler can import a PFX (PKCS#12) file as it is, as well as PEM and DER. Converting it to separate PEM files is still worth doing when you need to see what is in it — which certificate, which key, which intermediates, in which order — when each intermediate has to be added and linked on its own, when the same certificate goes to other servers, and when a deployment workflow reads PEM files from a folder. Here is the conversion, what goes wrong with it, and a way to do it without OpenSSL on your desk.

What is inside a PFX

A PFX file is a password-protected bundle. It usually holds the server certificate, its private key, and some or all of the chain above it — sometimes including the root, in no particular order. Split into PEM files, each piece can be read, checked and installed on its own, and each intermediate can be linked to the certificate it issued.

With OpenSSL

The file names below are the ones the converter further down produces, so the two routes end in the same files.

# the server certificate
openssl pkcs12 -in gateway.pfx -clcerts -nokeys -out gateway-crt.pem

# the private key (you will be asked for a passphrase to protect it)
openssl pkcs12 -in gateway.pfx -nocerts -out gateway-key.pem

# every CA certificate in the file, in the order the PFX stored them
openssl pkcs12 -in gateway.pfx -cacerts -nokeys -out gateway-chain-only.pem

Three things catch people out:

Older PFX files and OpenSSL 3. A file exported with the old RC2 encryption fails with an “unsupported algorithm” error on OpenSSL 3 until you add -legacy.
The chain file holds several certificates. -cacerts writes every CA certificate in whatever order the PFX stored them, often with the root included. On a NetScaler each intermediate is its own certKey, so it needs its own file (below).
The key. Add -noenc and the key is written unencrypted (-nodes is the older spelling, deprecated in OpenSSL 3). That is sometimes what you want for the upload, but it is then a credential sitting in your Downloads folder.

One file per intermediate. When gateway-chain-only.pem holds more than one certificate, split it and name each by what it is. Each BEGIN CERTIFICATE … END CERTIFICATE block is one certificate:

# one file per certificate in the bundle: ca-part-1.pem, ca-part-2.pem, ...
awk '/BEGIN CERTIFICATE/{n++} n{print > ("ca-part-" n ".pem")}' gateway-chain-only.pem

# what each one is: its subject and its issuer
openssl x509 -in ca-part-1.pem -noout -subject -issuer

The one whose subject is your certificate’s issuer (openssl x509 -in gateway-crt.pem -noout -issuer) is gateway-ca-1.pem. If that one is not signed by a root, the certificate whose subject is its issuer is gateway-ca-2.pem, and so on. A certificate whose subject and issuer are the same is the root: leave it out.

Without OpenSSL: in your browser

Vantage Toolkit · no cost

PFX to PEM, in your browser

Choose the .pfx, type its password, and download the certificate, the key and the chain as separate PEM files. The chain is put in order by issuer and the root is left out. The file is opened in the page and never uploaded; the page is not allowed to make a network request at all.

Open the certificate converter →

It reads modern AES-encrypted files and the older 3DES and RC2 ones, RSA and ECDSA keys, and files with no key at all. You choose whether the key file is encrypted with a passphrase, and it tells you plainly when it is not. The result names the file that carries the private key:

The converter's result: four files. gw.example.com-crt.pem is the server certificate; gw.example.com-key.pem is the private key, marked not encrypted; gw.example.com-chain-only.pem holds the intermediates, issuer first; gw.example.com-chain.pem is the certificate followed by its intermediates. — The converter’s result for a test certificate, gw.example.com; the names start with the prefix you give it, so with `gateway` they are the `gateway-crt.pem`, `gateway-key.pem` and `gateway-chain-only.pem` used here. The `-key.pem` file is the private key, and the page says when it is not encrypted. `-chain-only.pem` lists the intermediates issuer first, so with a single intermediate it is the file to add as `gateway-ca-1`.

Installing the result on a NetScaler

Upload the files to /nsconfig/ssl/, then add the pair, the intermediate, and the link:

add ssl certKey gateway-2026 -cert gateway-crt.pem -key gateway-key.pem -passplain <the key's passphrase>
add ssl certKey gateway-ca-1 -cert gateway-ca-1.pem
link ssl certKey gateway-2026 gateway-ca-1
bind ssl vserver gateway-vs -certkeyName gateway-2026
save ns config

With a second intermediate, add gateway-ca-2.pem the same way and link gateway-ca-1 to it. If you are replacing a certificate that is already bound, update ssl certKey on the existing pair keeps every binding in place instead. Either way, check the chain your gateway presents afterwards with the SSL/TLS check.

Doing this on every appliance, every year

One certificate is ten minutes. Twenty appliances, a gateway certificate shared by an authentication virtual server you forgot about, and a maintenance window, is an evening. Certificate automation in DTR Vantage takes the renewed files from a share — named exactly the way the converter above names them — and installs them everywhere they are used, with every binding read before anything changes, a preview first, and a report after.