I am getting the shorter chain (End-entity certificate ← R3 ← ISRG Root X1) by default on Acme4j when used "getCertificateChain" (Certificate (acme4j Client 2.12 API)).
I think this is not client/browser issue where it has ignored the rest of the chain because the expiry of X1 is 2035 (not 2024).
However, on the staging server, I see the longer chain (End-entity certificate <--(STAGING) R3 <- (STAGING) X1) served by default. Although X1 here is signed by X3.
Browsers are free to determine the chain, even if a different chain is send by the server. Therefore, you can't use a browser to check the actual chain send.. Please use sites such as the SSL Server Test from SSLLabs to check the chain.
Note that SSLLabs also let's you see the certificate/chain send when no SNI information is included in the request. In 99,99999 % of cases you can safely ignore that.
Yeah, in this case since you're talking about an ACME library I think what you need to be looking at is the length of the List returned by getCertificateChain(). This should have changed around May 4 to be 3 certificates instead of 2. Are you saying that it's changed back and returns 2 now? Can you provide some sample code?
As @Osiris says, what you see as the chain when looking in your OS or in your web browser is completely irrelevant and has nothing to do you what the ACME server sent to your client or what your web server sends to a web browser.
Thank you @Osiris and @petercooperjr .
It was naive of me to think the browser wouldn't have manipulated the chain I assumed the browser could possibly stop showing the chain beyond the trusted CA but not a different chain altogether. However, SSL Server Test from SSLLabs did show the right certificate chain as expected.
I assumed the browser could possibly stop showing the chain beyond the trusted CA but not a different chain altogether. However,