Closed nsheridan closed 3 weeks ago
Yes, it seems to be related to the java.net.http
client.
I can reproduce this issue when I use a domain instead of localhost
to connect to a Pebble container. I will have a look into that.
You can use -Djdk.internal.httpclient.disableHostnameVerification
to disable hostname verification. Since Pebble is only meant to be used in test environments, it should be an acceptable workaround. I could not reproduce the error anymore when I set that system property.
According to this stackoverflow question, it was a deliberate decision not to add a hostname verifier to the java.net.http
client. If that's correct, the disableHostnameVerification
system property is the only possible fix.
I will still try to find a proper solution this weekend, although I'm not too optimistic.
Yeah that's a workaround I'd found too, though hadn't tested yet. I can also use a different cert with the correct SAN. Thanks for looking into it - it's only a minor inconvenience but I wanted to flag it anyway.
Yes, the correct approach is to generate an end-entity certificate on your Pebble server that matches your Pebble FQDN. This is how to create it: https://github.com/letsencrypt/pebble/tree/main/test/certs
disableHostnameVerification
is the only alternative I see, with all the security implications of disabling hostname verification globally.
Thank you for the pointer! I will update the Pebble chapter of the acme4j documentation accordingly.
Closing this issue. Feel free to reopen if necessary.
I'm updating a dependency on acme4j from pre-3.x to 3.3 and I've encountered an issue where the http client rejects the certificate presented by pebble. This worked with the previous version of acme4j, maybe an artifact of the switch to the
java.net.http
client?pebble.cert-pebble.svc.stage.kubernetes
acme://pebble/pebble.cert-pebble.svc.stage.kubernetes:14000
java.security.cert.CertificateException: No subject alternative DNS name matching pebble.cert-pebble.svc.stage.kubernetes found
The full exception follows: