Nginx server sending wrong intermediate chain

Help
22

Yes, a seriously wrong clock would cause cert validation problems but not "unable to get local issuer certificate" validation failure. The nginx server isn't use the Nov6 certs.

As an aside, based on the sizes those certs were issued back in Nov with a large rsa key size to get that large of a privkey file. The size of fullchain reflects a leaf and one intermediate so typical of the chains used back then (only to ISRG Root X1 for RSA)

23

All these can easily be explained

  1. Nov 6 - because it is an expired cert, I was merely trying to show what is the minimum required for NPM to have no errors
  2. /docker/compose/nginx-proxy-work/data-nginx there are no nginx config files outside of the docker container, I know because I wrote the docker-compose.yaml
services:
  app:
    image: "jc21/nginx-proxy-manager:latest"
    restart: always
    ports:
      - "80:80"
      - "81:81"
      - "443:443"
    volumes:
      - "./data-docker/data:/data"

Instead, what I would not ignore is

  1. When I replace these 2 files with ones from zerossl, no more openssl errors

With everything kept the same and only replacing the fullchain and key file from another provider, the error goes away. And with several other complains about YR certs on this site, I'm really not going to question NPM.

Since there is so much interest in the size of the files, this is the fullchain of YR certs from 5 days ago

-rw-r--r-- 1 root root 3911 Jun 15 06:31  fullchain.pem
-rw-r--r-- 1 root root 3272 Jun 15 00:31  privkey.pem
24

The length of the fullchain looks too small for that size of privkey. That they don't have the same timestamp is unusual as well. Almost as if something later modified fullchain.

Do NOT post the contents of privkey.pem. But, please post the contents of fullchain.pem

25

If you don't want to show the entire fullchain show at least output of this

cat fullchain.pem | grep CERT
26

Not to put too fine a point on it, but if your judgment on this matter were reliable, you wouldn't need our help.

Nginx Proxy Manager (not the same thing as Nginx, and it would have been helpful to have noted in the OP) isn't serving the correct certificate chain, and there are really only two possible causes:

  • You're giving it an incorrect certificate chain, perhaps because your DIY client isn't requesting or saving the chain properly; or
  • NPM is barfing on the certificate chain it's being given.

If you'd share the contents of fullchain.pem, as you've been repeatedly asked to do, we'd be able to determine if it's the cause of the problem.

Since none of those other complaints involve NPM, perhaps you should reconsider that position.

27
  1. I narrow down by debugging top down: what is the single action that I can take to fix the problem? Ans: replace 2 and only 2 files, here on referred to as the elephant
  2. I have been able to clarify every question raised, yet, it was very obvious to me right at the start that there would be no questions or attempts to address this elephant in the room
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

That they don't have the same timestamp is unusual as well. Almost as if something later modified fullchain.

Simple, YR cert had openssl verification issues, thus I ran the client again to renew the cert and burnt 6 hours in the process of doing so. My client re-uses existing private keys Live cert does not match with key - #6 by bilogic

you wouldn't need our help.

My problem is already solved, the only reason I'm still replying is in the hope that someone, would address the elephant in the room for everybody's sake.

You're giving it an incorrect certificate chain, perhaps because your DIY client isn't requesting or saving the chain properly; or

Repeat: Fullchain certs are not constructed my client, they are saved as-is directly as received from LE's servers.

From other reports, it sounded like LE is missing some certs in the fullchain

Taken together with the elephant, it is not logical for me to suspect any aspect of the NPM/nginx.

28

If that were the case, you wouldn't be having any problems.

Since in all those other reports, it wasn't the case that they were using the full chain being sent by LE as is, but some software was only using part of it.

29

That proves you are missing the second intermediate cert. There should be 3 total certs in fullchain for an RSA cert. The leaf itself and then intermediates leading to the YR root and the X1 root in that order.

You should review the fullchain file you save from your custom ACME Client and work step by step past that if needed to find out where the second intermediate gets lost.

The validation failure shown in your first post related to the unknown issuer which was the YR root. That's how we know you lost the last intermediate leading to X1.

As @petercooperjr and others have noted if you truly saved the complete leaf cert and chain you were sent by Let's Encrypt it would not be missing. LE issues millions of certs per day and has used this YR series for all certs for over 3 weeks and certain profiles even longer than that. There has not been a single confirmed case of being sent the wrong chain. I am confident you are not the first given all we have seen here.