Hello! On Sat, Jan 29, 2022 at 01:50:24PM +0000, CHHABRA Mandeep Singh via nginx-devel wrote:
> > Sure, intermediate certificates are not required to be known > > by the server and can be provided by the client in the extra > > certificates during SSL/TLS handshake. > > I am not sure what you mean by passing the intermediate CAs in > the extra certificates. They are CA certificates and are passed > as CA certificate chain. For example: curl has option --cacert > which can take the entire chain of CA certificates (from > immediate issuer to the trust anchor) > # curl --cacert The "extra" is as in SSL_CTX_add_extra_chain_cert, see https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_add_extra_chain_cert.html. During SSL/TLS handshake client sends the list of certificates to the server. The certificate list is expected to contain the client certificate itself, followed by optional/extra additional certificates (usually not including the root, since including it is just a waste of resources). It is defined by TLSv1.2 sepecification as follows (https://datatracker.ietf.org/doc/html/rfc5246#section-7.4.2): certificate_list This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. Note that the certificate list is used for both server and client certificates. As previously suggested, it is believed that client certificates are almost always used without any additional intermediate certificates being sent by the client. > > Further, it is not really possible to properly retrieve such > > client-provided intermediate certificates after the initial > > handshake: these certificates are not saved to the session > > data and therefore not available after session reuse, see > > 7653:8409f9df6219 > > (http://hg.nginx.org/nginx/rev/8409f9df6219). > > AFAIU, intermediate CA certificates are not supposed to be known > by Nginx anyway. I am not sure if we are referring to > two different things here. But with the changes which I > proposed, I am able to retrieve the entire chain from Nginx(also > in cases > when intermediate CAs are not known to the server). During > certificate verification, Nginx creates a verified chain from > the incoming certificate chain and the CA certificate which is > trusted on the web interface. Nginx only needs to know about the > trust anchor (the self signed CA certificate) Try to retrieve the entire chain in a connection which is using an abbreviated handshake, not an initial one. The information about intermediate certificates which are not known on the server is not preserved by OpenSSL in the session data. As such, it is not possible to re-create the certificate chain in the connection using abbreviated handshake. This is explicitly documented in the man page of the SSL_get0_verified_chain() function you are using, see https://www.openssl.org/docs/man1.1.1/man3/SSL_get0_verified_chain.html: : If the session is resumed peers do not send certificates so a NULL : pointer is returned by these functions. The client certificate itself is preserved in the session data, so it is available after session resumption. This makes it possible to re-create the certificate chain if no client-provided certificates are used, see the 7653:8409f9df6219 change mentioned above. Hope this helps. > > And you want to allow access only to certificates signed by > > Intermediate1 CA in some cases, and only certificates signed by > > Intermediate2 CA in other cases. Is that correct? > > You are correct partially. Yes, we need to allow/deny a configuration based > on the configuration available for the CA. > There could be different combinations with the chain here > 1- Cert-> Intermediate1 -> Root > 2- Cert-> Intermediate2 -> Root > 3- Cert-> Root > 4- Cert-> Intermediate1 -> Intermediate2 -> Root > > For example:- > Consider the chain "Cert-> Intermediate1 -> Intermediate2 -> Root" > We need to something based on Intermediate2's configuration and it is > possible that the > Intermediate1 is not known to the server. As previously suggested, while technically it is possible, it is usually indicate that it might be a good idea to reconsider the configuration and make sure that all intermediate certificates are known on the server. -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx-devel mailing list -- nginx-devel@nginx.org To unsubscribe send an email to nginx-devel-le...@nginx.org
