H, , ' ello. My my d xx xx xx be me z cc MC off to mm. Nx xx xx xx
On Thu, Mar 13, 2025, 20:02 Mik J via nginx <nginx@nginx.org> wrote: > Hello Thomas, > > Thank you for your answer and the time you took to write it down. > > Actually I had created a root CA and an Intermediate CA that I use to sign > my certificates. > I am confused by the name of the directive "ssl_client_certificate" and in > your explanation you tell me that I need to specify the CA certificate that > signed the client certificate. > So I will try that, that confused me. > > Thank you > > > > Le jeudi 13 mars 2025 à 01:54:04 UTC+1, Thomas Ward <tew...@ubuntu.com> a > écrit : > > > > > > > > > > On 2025-03-12 19:45, Mik J wrote: > > > When I read your explanation, I understand that in this file > > ssl_client_certificate /path/to/client/cert/ca.pem; > > => I would need to concatenate all my individual client certificates ? > > No. This is where a deeper understanding of how PKI works is important. > > In the proper scenario, you will have a Certificate Authority certificate > that is used to issue and sign all SSL Client Certificates. Using my > direct example of a PKI chain from before, let's assume this is the chain > of certs that exist in my PKI wherever I manage the X.509 certificates: > CN=Spigot-CA,OU=Technical,O=Spigot,C=US (Serial 69D2DC9DAAABD023) > |-> CN=teward,OU=Admin,O=Spigot (Serial 575EDDCAAA0D654F) > |-> CN=johndoe,OU=HR,O=Spigot > |-> CN=janedoe,OU=Random,O=Spigot > Only one is the Certificate Authority - CN=Spigot-CA - which is the > certificate that cryptographically signs every client certificate - > CN=teward, CN=johndoe, CN=janedoe are an example of multiple users. > > You ONLY specify in `ssl_client_certificate` the certificate that is the > CA certificate. In this case, `/etc/ssl/Spigot-CA/ca.crt` if put in for > ssl_client_certificate would have the PEM encoded form of the CA > certificate with the CN=Spigot-CA. > > > Every single client certificate in the PKI chain is **issued and signed** > by that CA certificate. Case in point, I just created this example PKI in a > local tree of certificates and want to show you the client certificate and > its data after its parsed by OpenSSL: > > $ openssl x509 -noout -text -in teward.crt > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 6295713191616669007 (0x575eddcaaa0d654f) > Signature Algorithm: sha256WithRSAEncryption > Issuer: C = US, O = Spigot, OU = Technical, CN = Spigot-CA, > emailAddress = nore...@example.com > Validity > Not Before: Mar 11 23:26:00 2025 GMT > Not After : Mar 11 23:26:00 2026 GMT > Subject: O = Spigot, OU = Admin, CN = teward, emailAddress = > nore...@example.com > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (2048 bit) > Modulus: > ... > Exponent: 65537 (0x10001) > X509v3 extensions: > ... > Signature Algorithm: sha256WithRSAEncryption > Signature Value: > ... > > See the "Issuer" line where the issuing certificate authority is > CN=Spigot-CA? That means the certificate *must* be issued by that CA > certificate. However, that alone is not enough. By giving NGINX the > **trusted CA certificate** in `ssl_client_certificate`, we are explicitly > telling it what certificate to use for verification of the signature and > issuing line to validate against. > > Therefore, behind the scenes, NGINX will make sure the signature on the > certificate from its issuing CA is in fact from the CA certificate expected > (therefore preventing the Red Team or a bad guy from creating a different > CA certificate with the same DN and then a client cert with your same DN on > the client cert) to make sure it's legitimate. > > With my brief explanation of how PKI for client authentication works out > of the way... > > > > I wanted to remove "ssl_client_certificate /etc/ssl/certs/myuser.crt" > because I wanted that client verification would work for myuser1, > myuser2....not juste for one user. > > Basicly for all my users in my company, and the website would be exposed > on the internet. > > DO NOT remove the `ssl_client_certificate` line. As explained above, > that's CRITICAL to validate what client certificates are in fact allowed. > As long as all your authorized client certificates for all your users (in > my example, teward, johndoe, and janedoe) are *issued and signed* by the CA > certificate, then the client certificates will be validated against the CA > certificate to make sure that they're signed by the CA certificate NGINX is > told to expect, and then from there the clients will either be accepted or > rejected **based on the validity of the certificate and that it was issued > by the expected CA certificate**. > > You don't need to have a certificate with all the certificate public keys, > etc. of your client certificates, you just need the PEM-encoded file of the > CA certificate, that's how PKI validation will validate the signature on > the client certificates. > > > Thank you for clarifying the attack scenario, I didn't think about it > at all. > > > > You're welcome, there's OTHER attack scenarios (like the one i just > explained also in my example describing PKI above) but this one was > actually used in a pentester's exercise against an Internet-facing TLS > Client Certificate-shielded endpoint we actually have at my dayjob and they > failed to pass any way of generating a 'fake' cert to bypass the client > protections, because the CA certificate was actually used to check/test the > signatures for validity. > > (Also note as a disclaimer, I'm a CISSP certified security professional, > so there's an understanding of how cryptography and the PKI chains are > meant to be used and in fact are used in this scenario ingrained from the > CISSP training) > > --- > Thomas > _______________________________________________ > nginx mailing list > nginx@nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx >
_______________________________________________ nginx mailing list nginx@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx
