Certificate Chains
Your server's certificate is valid, in-date, and names the right host, yet curl still refuses it with unable to get local issuer certificate. Validity was never the question: someone has to vouch for it, all the way up.
- ▸A certificate can be valid, in-date, and correctly named and still be refused, because validity was never what earned belief.
- ▸Your server ships the middle certificates and stops short; forget one and Firefox fails while Chrome quietly downloads it.
- ▸Endorse one certificate under two authorities and it gains two paths; the client, not the server, picks one.
The prior topic left the server holding proof it owns the key inside its certificate. That certificate is well-formed, in-date, and carries the right hostname. None of that decides whether your client should believe it.
A certificate names two parties: its Subject (who it is for) and its Issuer (who signed it). The leaf certificate for a host lists an issuer that is not itself, some authority signed it. So the client goes looking for that authority's certificate. It finds one whose Subject matches the leaf's Issuer, then checks that this upper certificate's public key actually validates the signature on the leaf. If both hold, the first rung is good.
Then it repeats. That upper certificate has its own Issuer, so the client climbs again, matching name to name and re-checking each signature, one rung at a time. This is a walk, and the client is the one walking. The server never runs it; it only supplies the certificates.
You are handed the certificates for one connection, out of order. Assemble the climb: match each certificate's issuer to the subject above it, and let each signature confirm the rung before the next one can form.