The certificate a customer hands over almost never comes in the format a WAF wants. Tomcat exports a JKS keystore, IIS exports a PFX file, and the WAF wants a plain public key, private key and certificate chain. Here is the actual conversion chain, the keytool and OpenSSL commands, and what to check before an upload that looks fine turns out not to be.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
The certificate is real, it hasn't expired, and it still won't go into the WAF — because the file itself is the wrong shape.
Most Web server platforms don't store certificates as a plain public key, private key and chain. Apache and Nginx, built on OpenSSL, come closest — they already work in CRT, KEY and CER-style files. Tomcat, WebLogic and JBoss run on Java and store everything in a single Java Keystore (JKS) file built with the JDK's Keytool. Microsoft's IIS uses the Windows certificate store and exports as PFX. A WAF's HTTPS configuration wants the OpenSSL-style files directly, so anything that came out of a JKS or a PFX container has to be converted first — and the chain has to travel with it, or the site stays unreachable even with a perfectly valid certificate.
What follows is the conversion relationship between the three formats, the exact commands for each hop, how to generate a certificate chain when the customer's is missing, how to tell a public key file from a CA file before you upload either one, and a handful of real FAQ answers pulled from actual field cases.
JKS, PFX and PEM/KEY/CRT aren't three unrelated formats — they sit on a single conversion chain, and every WAF certificate upload ends up traveling along it from one end or the other.
Knowing which end you're starting from tells you exactly how many hops are between you and an upload that actually works.
Diagram labels are kept in English for engineering clarity.
Everything to the left of PEM/KEY/CRT has to make the trip across this diagram before a WAF will accept it. The certificate chain is a separate concern that travels alongside the public/private key pair, not a fourth format on the same chain — and it's the piece that's most often forgotten.
Two hops, one chain-building step if you need it, and one verification pass before you touch the upload form.
If the certificate came off a Tomcat, WebLogic or JBoss server, it's sitting in a single JKS file and needs one hop through Keytool first.
keytool -importkeystore -srckeystore D:\server.jks -destkeystore D:\server.pfx -srcstoretype JKS -deststoretype PKCS12Whether the PFX came from Step 1 or straight off an IIS server, this is the hop that produces the files the WAF actually wants.
openssl pkcs12 -in server.pfx -nodes -out server.pem
openssl rsa -in server.pem -out server.key
openssl x509 -in server.pem -out server.crtWhen the certificate came from an intermediate CA rather than a root authority — the normal case — the chain has to be uploaded too, or the site stays unreachable for anyone whose browser doesn't already trust that intermediate.
A file that opens without error isn't proof it's the right file for the field you're about to put it in.
The conversion commands themselves rarely fail — these four things around them are what actually break the upload.
SYMPTOMA certificate that works perfectly on the customer's Tomcat or IIS server gets rejected, or simply won't upload, when you try to configure the same HTTPS site on the WAF.
CAUSEDifferent Web server platforms store certificates in different formats by default: Apache/Nginx use OpenSSL-based CRT/KEY files, Tomcat/WebLogic/JBoss use a Java Keystore (JKS) built with the JDK's Keytool, and IIS on Windows Server exports as PFX. The WAF's HTTPS/SSL configuration wants the OpenSSL-style public key, private key and certificate chain — not a JKS or PFX container.
FIXConvert along the standard chain — JKS to PFX with Keytool, then PFX to PEM/KEY/CRT with OpenSSL — rather than trying to upload the customer's original file as-is.
SYMPTOMThe HTTPS site is unreachable after the certificate is uploaded, even though the certificate itself checks out and hasn't expired.
CAUSEWhen a certificate is issued by an intermediate CA rather than directly by a root authority — the normal case — clients need the intermediate chain to build a trust path back to a root they already trust. If that chain isn't uploaded alongside the public and private key, the handshake fails for anyone whose browser doesn't already have the intermediate cached.
FIXUpload the certificate chain the customer provides. If it's missing or lost, import the site's CA certificate into an online chain-download tool such as myssl.com's chain_download page, generate the chain there, and upload the result.
SYMPTOMA certificate upload appears to succeed, but the site still fails to serve HTTPS correctly, or the wrong file ends up in the wrong upload field.
CAUSEA leaf certificate (the site's public key) and a CA certificate can both be ordinary .crt/.cer files with similar names, and there's no reliable way to tell them apart just by filename.
FIXDouble-click the certificate file before uploading it and check the certificate path. A domain name in the path means it's the public key; no domain name means it's a CA certificate — upload each into the field that matches what it actually is, not what its filename suggests.
SYMPTOMThe exact same site serves fine over HTTP, but HTTPS access fails for some or all clients after the certificate has already been uploaded.
CAUSEOnce HTTP is confirmed working, the fault is somewhere in the TLS handshake itself, and it's usually one of four things: an SSL/TLS version the client is stuck on that the WAF doesn't support (SSLv2/SSLv3/TLS 1.0), a cipher suite the WAF disables by default, a public key, private key or chain that doesn't actually match the origin server, or a client presenting mutual (two-way) TLS authentication such as a UKey — which this class of WAF can't proxy at all.
FIXWork through the four in order: check the client's negotiated protocol version first, then cipher suite support, then re-verify the uploaded key/chain actually matches the origin, and finally rule out mutual-authentication clients — which need to bypass the WAF rather than be proxied through it.
Pulled straight from the field — the ones worth having an answer ready for.
Apache and Nginx normally use OpenSSL's own tools, producing CRT, KEY and CER-style files directly. Tomcat, WebLogic and JBoss go through Java's Keytool, part of the JDK, and store everything in a single Java Keystore (JKS) file. Microsoft's IIS uses the Windows certificate store and exports as PFX. A WAF needs the OpenSSL-style public key, private key and chain — so anything that came out of a JKS or a PFX file has to be converted first.
Two hops. First, Keytool converts JKS to PFX: keytool -importkeystore -srckeystore server.jks -destkeystore server.pfx -srcstoretype JKS -deststoretype PKCS12. Then OpenSSL splits the PFX into the PEM/KEY/CRT files the WAF actually wants: openssl pkcs12 -in server.pfx -nodes -out server.pem, followed by openssl rsa -in server.pem -out server.key and openssl x509 -in server.pem -out server.crt.
Yes — you need to upload the certificate chain along with the public and private key, or the site becomes unreachable even though the leaf certificate itself is completely valid. If the customer didn't provide a chain file, or it's been lost, importing the site's CA certificate at myssl.com's chain-download tool and generating the chain from there is the standard workaround.
Double-click the certificate file to open it and check the certificate path. If a domain name shows up in the chain, you're looking at the public key — the leaf certificate issued to your site. If there's no domain name, it's a CA certificate — useful for building the chain, but not something you should upload into the public-key field.
Four usual suspects, in roughly this order: an unsupported SSL/TLS protocol version on the client (SSLv2, SSLv3, TLS 1.0); a cipher suite the WAF disables by default for security reasons, which you can enable at the cost of some of that security; a public key, private key or chain that simply doesn't match what the origin server is actually using; or a client doing mutual (two-way) TLS authentication with something like a UKey — which this class of WAF doesn't support proxying at all.
This note is built around the Huawei WAF's certificate requirements — a public key, private key and certificate chain in OpenSSL-style PEM/KEY/CRT form — and the Keytool / OpenSSL commands used to get there from JKS or PFX, plus the field cases behind them. If your WAF is a different vendor, the exact upload fields may differ, but the underlying conversion chain — JKS through PFX to PEM/KEY/CRT — and the certificate-chain and public-key-versus-CA checks carry over directly. It doesn't cover mutual (two-way) TLS client-certificate authentication, which most WAF appliances don't proxy at all.
Tell us what format you're starting from — JKS, PFX, or something else — and where the chain breaks, and we'll help you read it.