Spring boot and Lets Encrypt no cipher suites in common

Question

Using the awesome library acme4j, I've created 3 files.

• domain.csr
• domain.key
• domain-chain.crt

The problem I have is when I convert those to a keystore.p12 I can't get Spring boot working with it. I've used the following command to create the keystore.p12 file:

openssl pkcs12 -export -out keystore.p12 -inkey domain.key -in domain-chain.crt

The configuration is setup as such

server:
  port: 9443
  ssl:
    key-store: keystore.p12
    key-password: secret
    key-store-type: PKCS12

However if I try and hit my endpoint, I get javax.net.ssl.SSLHandshakeException: no cipher suites in common thrown.

This seems to be a relatively common issue and one suggestion is to enable debugging as per https://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/ReadDebug.html

So, doing that and hitting the endpoint again I can see

javax.net.ssl|DEBUG|2B|reactor-http-epoll-2|2019-05-03 07:47:10.917 NZST|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLS11
javax.net.ssl|DEBUG|2B|reactor-http-epoll-2|2019-05-03 07:47:10.917 NZST|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for TLS11
javax.net.ssl|DEBUG|2B|reactor-http-epoll-2|2019-05-03 07:47:10.917 NZST|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS11
javax.net.ssl|DEBUG|2B|reactor-http-epoll-2|2019-05-03 07:47:10.918 NZST|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 for TLS10
javax.net.ssl|DEBUG|2B|reactor-http-epoll-2|2019-05-03 07:47:10.918 NZST|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for TLS10
javax.net.ssl|DEBUG|2B|reactor-http-epoll-2|2019-05-03 07:47:10.918 NZST|HandshakeContext.java:294|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS10

And I'm sure the answer is somewhere in the ClientHello response but It's beyond me on how to understand the issue, or how to fix it

javax.net.ssl|DEBUG|2B|reactor-http-epoll-2|2019-05-03 07:47:10.934 NZST|ClientHello.java:806|Consuming ClientHello handshake message (
"ClientHello": {
  "client version"      : "TLSv1.2",
  "random"              : "C5 25 B0 63 79 3A D5 FB 76 1C 7B DF B5 E9 74 2A 5F FF 2E 1B 7B F0 21 66 5B 33 9C 64 3F 52 40 2A",
  "session id"          : "",
  "cipher suites"       : "[TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F), TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B), TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384(0xC030), TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384(0xC02C), TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384(0xC028), TLS_DHE_RSA_WITH_AES_256_CBC_SHA256(0x006B), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384(0xC024), TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA(0xC014), TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA(0xC00A), TLS_DH_DSS_WITH_AES_256_GCM_SHA384(0x00A5), TLS_DHE_DSS_WITH_AES_256_GCM_SHA384(0x00A3), TLS_DH_RSA_WITH_AES_256_GCM_SHA384(0x00A1), TLS_DHE_RSA_WITH_AES_256_GCM_SHA384(0x009F), TLS_DHE_DSS_WITH_AES_256_CBC_SHA256(0x006A), TLS_DH_RSA_WITH_AES_256_CBC_SHA256(0x0069), TLS_DH_DSS_WITH_AES_256_CBC_SHA256(0x0068), TLS_DHE_RSA_WITH_AES_256_CBC_SHA(0x0039), TLS_DHE_DSS_WITH_AES_256_CBC_SHA(0x0038), TLS_DH_RSA_WITH_AES_256_CBC_SHA(0x0037), TLS_DH_DSS_WITH_AES_256_CBC_SHA(0x0036), TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384(0xC032), TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384(0xC02E), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384(0xC02A), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384(0xC026), TLS_ECDH_RSA_WITH_AES_256_CBC_SHA(0xC00F), TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA(0xC005), TLS_RSA_WITH_AES_256_GCM_SHA384(0x009D), TLS_RSA_WITH_AES_256_CBC_SHA256(0x003D), TLS_RSA_WITH_AES_256_CBC_SHA(0x0035), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013), TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009), TLS_DH_DSS_WITH_AES_128_GCM_SHA256(0x00A4), TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2), TLS_DH_RSA_WITH_AES_128_GCM_SHA256(0x00A0), TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040), TLS_DH_RSA_WITH_AES_128_CBC_SHA256(0x003F), TLS_DH_DSS_WITH_AES_128_CBC_SHA256(0x003E), TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033), TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032), TLS_DH_RSA_WITH_AES_128_CBC_SHA(0x0031), TLS_DH_DSS_WITH_AES_128_CBC_SHA(0x0030), TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(0xC031), TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(0xC02D), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(0xC025), TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(0xC00E), TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(0xC004), TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C), TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), TLS_RSA_WITH_AES_128_CBC_SHA(0x002F), TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]",
  "compression methods" : "00",
  "extensions"          : [
    "server_name (0)": {
      type=host_name (0), value=example.com
    },
    "ec_point_formats (11)": {
      "formats": [uncompressed, ansiX962_compressed_prime, ansiX962_compressed_char2]
    },
    "supported_groups (10)": {
      "versions": [secp256r1, secp521r1, UNDEFINED-NAMED-GROUP(28), UNDEFINED-NAMED-GROUP(27), secp384r1, UNDEFINED-NAMED-GROUP(26), secp256k1, sect571r1, sect571k1, sect409k1, sect409r1, sect283k1, sect283r1]
    },
    "unknown extension (35)": {

    },
    "signature_algorithms (13)": {
      "signature schemes": [rsa_pkcs1_sha512, dsa_sha512, ecdsa_secp512r1_sha512, rsa_pkcs1_sha384, dsa_sha384, ecdsa_secp384r1_sha384, rsa_pkcs1_sha256, dsa_sha256, ecdsa_secp256r1_sha256, rsa_sha224, dsa_sha224, ecdsa_sha224, rsa_pkcs1_sha1, dsa_sha1, ecdsa_sha1]
    },
    "unknown extension (13,172)": {

    }
  ]
}
)

Do I need to be doing something more than I already am? I'm running on OpenJDK Runtime Environment Zulu11.31+11-CA and using Spring boot 2.1.3.RELEASE with WebFlux, so running on Netty if that makes a difference

Cheers

Update:

Thanks to the helpful comments, I've tried using openssl s_client as suggested and the result looks like no certificate is being loaded at all?

CONNECTED(00000003)
140175956235392:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1536:SSL alert number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 338 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Answer 1

I'm not familiar with the configuration you're using, but I'd try to use key-store-password: secret in addition to key-password: secret (which you already have).

The Java keystore format (in general) allows for two passwords: one for the store, and one for the key itself.

For the p12 file you've generated, they should be the same. Whether both need to be specified depends on the tool that loads this configuration (some libraries would fall back on the keystore password if the key wasn't specified, for example).

If the store and key aren't unlocked, the certificate won't be in use, so it will try to use an anonymous cipher suite which is not advertised by the client and also likely to be disabled by default on the server.