From mikydevel at yahoo.fr  Tue Mar 11 22:58:21 2025
From: mikydevel at yahoo.fr (Mik J)
Date: Tue, 11 Mar 2025 22:58:21 +0000 (UTC)
Subject: Is if statement valid for cert client verification ?
References: <520567571.4755872.1741733901165.ref@mail.yahoo.com>
Message-ID: <520567571.4755872.1741733901165@mail.yahoo.com>

Hello,

I remember from Nginx that "if" can be evil.

I would like to validate that if can be used in the a context where I would like to authenticate my clients with a certificate.

if ($ssl_client_s_dn !~ "O=MyCorp") { return 403; }

Do you have any recommendation ?

Thank you

From mikydevel at yahoo.fr  Wed Mar 12 23:45:06 2025
From: mikydevel at yahoo.fr (Mik J)
Date: Wed, 12 Mar 2025 23:45:06 +0000 (UTC)
Subject: Is if statement valid for cert client verification ?
In-Reply-To: <22558779-7f8f-4d98-b03f-c602ad664910@ubuntu.com>
References: <520567571.4755872.1741733901165.ref@mail.yahoo.com>
 <520567571.4755872.1741733901165@mail.yahoo.com>
 <22558779-7f8f-4d98-b03f-c602ad664910@ubuntu.com>
Message-ID: <605483145.5579160.1741823106179@mail.yahoo.com>

Hello Thomas,

Thank you very much for these detailed explanations.

I did use
    ssl_client_certificate /etc/ssl/certs/myuser.crt;
    ssl_verify_client on;

But I had in mind to remove "ssl_client_certificate /etc/ssl/certs/myuser.crt", and replace it with
if ($ssl_client_s_dn !~ "O=MyCorp") { return 403; }

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 ?

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.


Thank you for clarifying the attack scenario, I didn't think about it at all.


My ssl configuration is
    ssl_dhparam /etc/nginx/dhparam4096.key;
    ssl_ecdh_curve prime256v1;
    ssl_certificate /etc/ssl/certs/myapp.mydomain.org_chain.crt;
    ssl_certificate_key /etc/ssl/private/myapp.mydomain.org.key;
    ssl_stapling_verify on;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:1m;
    ssl_session_timeout 180m;
    ssl_client_certificate /etc/ssl/certs/myuser1.crt;
    ssl_verify_client on;


Regards


Le mercredi 12 mars 2025 à 00:35:36 UTC+1, Thomas Ward <teward at ubuntu.com> a écrit : 





Ideally, I would suggest you avoid using `if` for this because there's 
ways your string matching could be bypassed (by providing a client cert 
with your Org defined in the DN but not legitimate), and instead rely on 
issuing of certs by a specific Certificate Authority and validate 
against that, ala:

server {
  listen 443 ssl;
  ...
  ssl_client_certificate /path/to/client/cert/ca.pem;
  ssl_verify_client on;
  ...
}

This will reject anyone who doesn't have a valid client certificate 
created by the CA defined in ssl_client_certificate. Explanation of my 
issues with YOUR approach (as you don't specify if you're doing 
ssl_client_certificate or ssl_verify_client on;) is assuming you aren't 
doing this, and there's a detailed explanation of why your solution is bad.

---

The way YOU'VE suggested is unsafe and opens to MITM or certificate 
faking. Let's use the following example.

My site accepts client certificates. The CA chain is:

CN=Spigot-CA,OU=Technical,O=Spigot,C=US (Serial 69D2DC9DAAABD023)
--> CN=teward,OU=Admin,O=Spigot (Serial 575EDDCAAA0D654F)

I am using your if statement, matching any case where O(rg) is not equal 
to Spigot. However, I am not actually validating the certificate 
signature against the CA cert. As part of Red Team exercises, the red 
team makes a new certificate that has no CA chain and is self-signed 
with the following DN:

(SELFSIGNED) CN=joesmith,OU=badguy,O=Spigot

When the `if` gets triggered and the ssl_client_certificiate isn't set 
and ssl_verify_client not set to "on", then when your if statement reads 
the DN of the Red Team's certificate, it will not ever hit the 443, 
instead it'll be seen as a "legitimate" cert and processing continues. 
That opens you up to "spoofing" of certificates to bypass protections.

Red Team notifies the security team (me) about this vulnerability. So I 
enforce CA cert checks and client verification.  By forcing the 
verification instead of the CA's certificate against the Client 
Certificate presented (which does cryptographic signature tests, etc. 
far beyond just checking the DN of a certificate), it will prevent that 
'spoofed' cert from working.

Accordingly, when I ask Red Team to retest with the permissions set 
accordingly to actually validate the cert against a specific CA cert or 
chain of certs, the Red Team can no longer succeed with their 'spoofed 
certificates' approach, and would need a valid client certificate signed 
by the valid CA certificate (which requires them to have the private 
key, which if you handle data right will never happen) to access the 
site or its resources (and simply would get Bad Request or similar 
because they didn't send a proper SSL cert).

---

Unless I'm misunderstanding your intention, which may be possible 
because you don't include your whole example configuration, etc. for 
this use case.


Thomas

On 2025-03-11 18:58, Mik J via nginx wrote:
> Hello,
>
> I remember from Nginx that "if" can be evil.
>
> I would like to validate that if can be used in the a context where I would like to authenticate my clients with a certificate.
>
> if ($ssl_client_s_dn !~ "O=MyCorp") { return 403; }
>
> Do you have any recommendation ?
>
> Thank you
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx

From mikydevel at yahoo.fr  Thu Mar 13 17:02:25 2025
From: mikydevel at yahoo.fr (Mik J)
Date: Thu, 13 Mar 2025 17:02:25 +0000 (UTC)
Subject: Is if statement valid for cert client verification ?
In-Reply-To: <c01e7b0f-e951-47aa-b874-75b062b47f55@ubuntu.com>
References: <520567571.4755872.1741733901165.ref@mail.yahoo.com>
 <520567571.4755872.1741733901165@mail.yahoo.com>
 <22558779-7f8f-4d98-b03f-c602ad664910@ubuntu.com>
 <605483145.5579160.1741823106179@mail.yahoo.com>
 <c01e7b0f-e951-47aa-b874-75b062b47f55@ubuntu.com>
Message-ID: <1367928361.6169260.1741885345955@mail.yahoo.com>

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 <teward at 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 = noreply at 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 = noreply at 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

From lucas.oketch at gmail.com  Fri Mar 14 12:22:01 2025
From: lucas.oketch at gmail.com (lucas oketch)
Date: Fri, 14 Mar 2025 15:22:01 +0300
Subject: Is if statement valid for cert client verification ?
In-Reply-To: <1367928361.6169260.1741885345955@mail.yahoo.com>
References: <520567571.4755872.1741733901165.ref@mail.yahoo.com>
 <520567571.4755872.1741733901165@mail.yahoo.com>
 <22558779-7f8f-4d98-b03f-c602ad664910@ubuntu.com>
 <605483145.5579160.1741823106179@mail.yahoo.com>
 <c01e7b0f-e951-47aa-b874-75b062b47f55@ubuntu.com>
 <1367928361.6169260.1741885345955@mail.yahoo.com>
Message-ID: <CAEjYZoLWpErZyFkRuF-Pr1aueAQNX_kc9H-wxEH++TuFwzu+WA@mail.gmail.com>

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 at 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 <teward at 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 = noreply at 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 =
> noreply at 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 at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20250314/483a79e8/attachment.htm>

From bmvishwas at gmail.com  Mon Mar 17 11:42:01 2025
From: bmvishwas at gmail.com (Vishwas Bm)
Date: Mon, 17 Mar 2025 17:12:01 +0530
Subject: Stable release date ?
Message-ID: <CANgk=832nKHOUyyn2xjhdQvxWK8awisB9_S=kTyOS5Dh2fbU5w@mail.gmail.com>

Hi,

When is the next nginx stable release date ?

I do not see it mentioned here
https://trac.nginx.org/nginx/roadmap



Regards,
Vishwas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20250317/327c43c0/attachment.htm>

From arut at nginx.com  Tue Mar 18 05:48:47 2025
From: arut at nginx.com (Roman Arutyunyan)
Date: Tue, 18 Mar 2025 09:48:47 +0400
Subject: Stable release date ?
In-Reply-To: <CANgk=832nKHOUyyn2xjhdQvxWK8awisB9_S=kTyOS5Dh2fbU5w@mail.gmail.com>
References: <CANgk=832nKHOUyyn2xjhdQvxWK8awisB9_S=kTyOS5Dh2fbU5w@mail.gmail.com>
Message-ID: <729DAF79-2B69-442D-9020-49CD723FA297@nginx.com>

Hello,

Typically it's around April 12 each year.

> On 17 Mar 2025, at 3:42 PM, Vishwas Bm <bmvishwas at gmail.com> wrote:
> 
> Hi,
> 
> When is the next nginx stable release date ?
> 
> I do not see it mentioned here
> https://trac.nginx.org/nginx/roadmap
> 
> 
> 
> Regards,
> Vishwas 
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx

----
Roman Arutyunyan
arut at nginx.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20250318/938bba24/attachment.htm>