Intermediate cert not being sent

[msgilligan]

It seems that the R3/Let's encrypt intermediate cert is not being sent from the server.

I have everything working OK via a web browser or command-line tools on macOS, but if I try to access the site with curl from Debian 10 I get the following error:

curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Adding the -k option makes it work, of course.

When I've manually used CertBot in the past, there has been a "full-chain" cert and I suspect that acme4j is not generating it or micronaut-acme is not using it.

I believe this page is relevant: https://community.letsencrypt.org/t/curl-does-not-trust-le-certs-on-plain-debian/54091

I'm not 100% sure I've diagnosed this correctly, but I thought I'd open an issue anyway, because I'm 90% sure.

[msgilligan]

You can visit https://testnet-btcproxy.consensusj.org/get/getblockcount to view the issue.

This seems to work in all browsers. It also works in curl on macOS, but not in curl on Debian 10. It doesn't seem to work with JDK or Graal native-image client, either.

[msgilligan]

... and I just verified that adding the intermediate cert to cacerts in OpenJDK (16.0.1, in this case) allows the connection.

(keytool -import -alias r3.intermediate.manually.installed -cacerts with the text from the middle cert in domain.crt on the server)

[msgilligan]

This may be a duplicate of #73

[msgilligan]

Additional info: openssl s_client -showcerts -connect testnet-btcproxy.consensusj.org:443 on macOS Big Sur will display the first of three certificates and then hang.

[zendern]

Started to look into this a little. On the surface I'm not seeing the issue from a code perspective. It will have to do some more debugging later. Maybe there is another flag or something that needs to happen when setting it up on the Netty server to keep those around?? Again more looking later.

We write the cert from the order to disk here

micronaut-acme/acme/src/main/java/io/micronaut/acme/services/AcmeService.java

Lines 260 to 269 in 8c99493

	Certificate certificate = order.getCertificate();
	if (certificate != null) {
	// Write a combined file containing the certificate and chain.
	try {
	File domainCsr = new File(certLocation, DOMAIN_CRT);
	try (BufferedWriter writer = Files.newBufferedWriter(domainCsr.toPath(), WRITE, CREATE, TRUNCATE_EXISTING)) {
	certificate.writeCertificate(writer);
	}
	eventPublisher.publishEvent(new CertificateEvent(getCurrentCertificate(), domainKeyPair, false));

That write should contain the full chain as well.
https://github.com/shred/acme4j/blob/8cb24680600faa4d3cc724b627eff18cda9b95c3/acme4j-client/src/main/java/org/shredzone/acme4j/Certificate.java#L127-L142

And then when we set it on the Netty server we just use the cert that was passed in the event, that is the one on disk that should contain all the cert chain as well.

micronaut-acme/acme/src/main/java/io/micronaut/acme/ssl/AcmeSSLContextBuilder.java

Lines 79 to 82 in 8c99493

	SslContext sslContext = SslContextBuilder
	.forServer(certificateEvent.getDomainKeyPair().getPrivate(), certificateEvent.getCert())
	.build();
	delegatedSslContext.setNewSslContext(sslContext);

[zendern]

PR officially opened in draft mode for now. I need to do some more full project level testing but I believe this should fix the issue.

[msgilligan]

@zendern Thanks for this. I've been able to work-around the issue for my main application (by using JSSE to load the missing cert locally) but will be happy to look at this and/or test it in a few weeks.