2

I'm trying to configure a WildFly server running in Docker to use SSL:

  • created a private key: keytool -genkey -alias axcelpk -keyalg RSA -keystore server.keystore -keysize 2048 -validity 1825
  • created a CSR: keytool -certreq -alias axcelPK -keystore server.keystore -file axcel.csr
  • converted the p7b to cer: openssl pkcs7 -print_certs -inform der -in axcel-B64-chain.p7b -out axcel-B64-chain.cer
  • added the certificate to the keystore: keytool -import -alias axcelCert -trustcacerts -file axcel-B64-chain.cer -keystore server.keystore

The WildFly configuration in standalone.xml was already done so I didn't touch that (did check it and seems OK).

When requesting a page from the server I get a Certificate error. When checking the certificate I noticed that I'm getting the SHA256 fingerprint of the private key instead of the fingerprint of the actual certificate. Also the issuer is incorrect and the certification path is basically empty.

Any ideas?

Sylvain Girard
  • 123
  • 3

1 Answers1

1

TLDR: it's not the private key, it's the self-signed cert

Although you don't say so (or show), I guess you did keytool -list on your keystore and saw two entries, one privateKeyEntry and one trustedCertEntry, each with a fingerprint. The fingerprint on the privateKeyEntry is NOT a fingerprint of the private key; it is the fingerprint of the (first) certificate stored in the privateKeyEntry. In your case that is the dummy self-signed certificate that was generated as part of the -genkey operation, since you didn't subsequently replace it as you should have. Such as self-signed cert always has Issuer equal to Subject (and not set to a real CA, as a real CA cert does).

A Java SSL/TLS server uses the certificate(s) in the privateKeyEntry, and the/any client that receives this cert should (1) not trust it, and display an error or warning indicating that it is not trusted and (2) show it as being its own certification path with no parent(s) (i.e. a singleton, not empty). It is not possible for an SSL/TLS server to send the privatekey; the protocol doesn't allow for it, because it would be completely insecure and stupid.

In your fourth step, use keytool -import on the CA-provided cert chain to the same alias that you used for the -genkey operation, here axcelpk, not a different alias. Note you don't actually need your third step; when importing a CA response (i.e. your own cert chain) to a privatekey entry, keytool (and more generally CertificateFactory) can read a p7b, in either PEM or DER, directly. Although if you want to have either the PEM cert sequence which is supported by OpenSSL, or a DER cert sequence which is not, those also work.

dave_thompson_085
  • 3,100
  • 1
  • 15
  • 14