God bless & thanks sooooo much! 
CharlesO
0
dom
I’ve been bitten by this before too… there was some discussion last year: ssl server doesn't send complete chain?
I think this is the commit that fixed it in 23.2: ssl: Extend cert and certfile option to be able to include a cert chain · erlang/otp@8d97c09 · GitHub
OTP-16277 Application(s): ssl
Handle extraneous certs in certificate chains as well
as chains that are incomplete but can be reconstructed
or unordered chains. The cert and certfile options will
now accept a list of certificates so that the user may
specify the chain explicitly.
Also, the default value of the depth option has been
increased to allow longer chains by default.
1
voltone
I’ve been bitten by this before too… there was some discussion last year: ssl server doesn’t send complete chain?
The author of that post wants to separate the intermediate CAs for their server certificate from the list of trusted root CAs used to verify client certificates. Right now this is not possible, as Ingela pointed out in her response. If the :cacertfile option is set, the server does not look for (intermediate) CAs in the file referenced by :certfile. Only if :cacertfile is not specified does it look in that file instead.
I think this is the commit that fixed it in 23.2: ssl: Extend cert and certfile option to be able to include a cert chain · erlang/otp@8d97c09 · GitHub
That change affects the way a chain is built for a peer certificate (e.g. a client checking a server’s certificate during a TLS handshake). In particular, it is supposed to handle multiple possible paths, as in the case of cross-signed certificates. It should not affect the sources used to locate issuers of the local end certificate.
0
dom
Ah yes, indeed. I just happened to hit both problems at the same time because I was trying to configure RabbitMQ for mTLS.
0