Search code examples
sslclient-serverjkspkcs#12

Can a server accept a client certificate in JKS format and refuse the same certificate in PKCS12

I am testing get requests for mutual TLS, and I started from a JKS certificate that was working, but when I convert it to PKCS12 it is refused by the server, and when I convert it back to JKS from PKCS12 it works again.

I am trying to understand what could be the issue.

This is what I got when debugging the handshake, juste before the refusal by the server:

javax.net.ssl|DEBUG|10|main|2023-10-02 09:24:55.689 CEST|CertificateRequest.java:697|Consuming CertificateRequest handshake message (
"CertificateRequest": {
  "certificate types": [rsa_sign, dss_sign, ecdsa_sign]
  "supported signature algorithms": [rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, rsa_pkcs1_sha1, ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, ecdsa_sha1, dsa_sha1, rsa_pkcs1_sha512, ecdsa_secp521r1_sha512]
  "certificate authorities": []
}
......
javax.net.ssl|DEBUG|10|main|2023-10-02 09:24:55.746 CEST|CertificateMessage.java:299|No X.509 certificate for client authentication, use empty Certificate message instead
javax.net.ssl|DEBUG|10|main|2023-10-02 09:24:55.748 CEST|CertificateMessage.java:330|Produced client Certificate handshake message (
"Certificates": <empty list>
)
Exception: Server returned HTTP response code: 403 for URL: https://serverURL

Here is the command for the conversion:

keytool -importkeystore -srckeystore MTLS_DEV_keystore.jks -srcstoretype JKS -destkeystore MTLS_DEV_keystore.p12 -deststoretype PKCS12

When I converted back to JKS it worked with SOAP UI:

keytool -importkeystore -srckeystore MTLS_DEV_keystore.pfx
-srcstoretype pkcs12 -destkeystore MTLS_DEV_keystore_converted.jks -deststoretype jks -deststorepass thePass
Solution

  • Can the server be configured to accept a specific format?

    JKS, PKCS12, PEM ... are just different containers and encoding of the same thing. These are purely used by the application to load the certificate (and key) for use within the TLS connection. What is transferred within the TLS handshake is the same though no matter which container and encoding was used by the application. That's why it is impossible for the TLS peer to make a decision based on the container or encoding used to load the certificate.