OPNsense Forum

Archive => 21.7 Legacy Series => Topic started by: iam on October 29, 2021, 07:53:15 pm

Title: LDAP auth ins't working since update to 2.7.4
Post by: iam on October 29, 2021, 07:53:15 pm
Hi,

the LDAP authentication isn't working since updating to 2.7.4. In the tester I get the following error:
Code: [Select]
The following input errors were detected:

    Authentication failed.
    error: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (unable to get local issuer certificate)
    ldap_error: Can't contact LDAP server

Maybe related: After accessing the Ca manager (I get the following PHP error:
Quote
[29-Oct-2021 19:49:43 Europe/Berlin] PHP Warning:  A non-numeric value encountered in /usr/local/www/system_camanager.php on line 176

Best,
iam

EDIT: I use OpenSSL
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: iam on October 29, 2021, 08:28:10 pm
In /etc/ssl/cert.pem in found a line starting with
Code: [Select]
#(system local trust) skip intermediate certificate

related to my internal CA.
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: iam on October 29, 2021, 08:37:59 pm
Ok it might be faulty how UCS creates the CA. But anyway it would if the new behavior could be disabled:

Quote
system: prevent expired or intermediate CA certificates from being added to trust store by default

I hope the part "by default" means exactly this.
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: iam on October 29, 2021, 08:50:11 pm
i've found the option in System -> Settings -> General. Thank you for implementing this option!
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: Fright on October 30, 2021, 08:03:14 am
Hi
can you please explain why you use intermediate CA cert to trust the ldap server and not the root CA cert?
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: benyamin on October 30, 2021, 09:35:11 am
Hi
can you please explain why you use intermediate CA cert to trust the ldap server and not the root CA cert?

That would be standard enterprise best practice. The root CA should only issue certificates to an intermediate CA, and the intermediate or issuing CA would issue certificates to services, e.g. a LDAP service or server.

CAs normally wouldn't be on a network perimeter either...
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: Fright on October 30, 2021, 09:55:53 am
@benyamin
I'm not talking about which certification authority should issue certificates to servers. I'm talking about which certification authority the connecting server should trust
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: iam on October 30, 2021, 10:01:45 am
Hi
can you please explain why you use intermediate CA cert to trust the ldap server and not the root CA cert?

Because there is no root CA. That's the way the UCS CA works.
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: Fright on October 30, 2021, 10:13:15 am
Quote
Because there is no root CA
sorry, how is this possible?
if UCS stands for UCS Univention Corporate Server then this is the first that google returns
https://help.univention.com/t/how-to-import-ucs-root-ca-on-windows-clients/8847
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: iam on October 30, 2021, 10:14:56 am
Here are the relevant attributes I assume:
Code: [Select]
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
[...]
            X509v3 Key Usage:
                Certificate Sign, CRL Sign
            Netscape Cert Type:
                SSL CA, S/MIME CA, Object Signing CA
            X509v3 Subject Alternative Name:
                email:****
            X509v3 Issuer Alternative Name:
                email:*****
            Netscape Comment:
                This certificate is a Root CA Certificate

So I don't now why OPNSENSE thinks that isn't a root CA.
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: Fright on October 30, 2021, 10:29:05 am
Quote
why OPNSENSE thinks that isn't a root CA
opnsense defines a certificate as root CA cert if it is self-signed. as a self-signed, in turn, it defines a certificate that does not have Authority Key Identifier or if Authority Key Identifier is equal to Subject Key Identifier.
can you share this cert?
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: iam on October 30, 2021, 10:34:52 am
Code: [Select]
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            *censored*
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: *censored*
        Validity
            Not Before: *censored*
            Not After : *censored*
        Subject: *censored*
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    *censored*
                Exponent: *censored*
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                *censored*
            X509v3 Authority Key Identifier:
                keyid:*censored* / equal to X509v3 Subject Key Identifier
                DirName:*censored*
                serial:*censored*

            X509v3 Key Usage:
                Certificate Sign, CRL Sign
            Netscape Cert Type:
                SSL CA, S/MIME CA, Object Signing CA
            X509v3 Subject Alternative Name:
                email:*censored*
            X509v3 Issuer Alternative Name:
                email:*censored*
            Netscape Comment:
                This certificate is a Root CA Certificate
    Signature Algorithm: sha256WithRSAEncryption

EDIT: I might sent the cert to you via PM in case this isn't sufficient
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: Fright on October 30, 2021, 10:44:31 am
l it may be a little regression in this new feature (prevent expired or intermediate CA certificates from being added to trust store by default).
and you would be very helpful in debugging if you could share the real certificate (pem. public key only)
can you do this? via personal message, if you like. i will remove it right after debugging. thanks
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: Fright on October 30, 2021, 11:33:30 am
thanks! i made pull request for this
https://github.com/opnsense/core/pull/5323
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: benyamin on October 30, 2021, 11:59:39 am
@benyamin
I'm not talking about which certification authority should issue certificates to servers. I'm talking about which certification authority the connecting server should trust

Yes, but they are related. For instance, I have to import an intermediate (issuing) CA for my LDAP service. It is not my root CA (which is offline). I was just pointing out that in an enterprise environment, it should always be an intermediate CA that issues the LDAP server's certificate. Therefore, the intermediate CA certificate would need to be imported.

I see in the OP's case, the cert was actually a root CA, and you identified the regression and have submitted the pull request. That being said, there will still be cases (like mine) where an intermediate CA will need to be used. As such, I am grateful for the override at System: Settings: General > Trust > Store intermediate.

Cheers,
Ben
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: Fright on October 30, 2021, 03:29:08 pm
Quote
it should always be an intermediate CA that issues the LDAP server's certificate. Therefore, the intermediate CA certificate would need to be imported
I'm sorry, but how does the second follow from the first? you say that trust is related to whether the CA is offline or online?

Im using offline root CA and M$ Enterprise subordinate CAs to issue certificates to services. and I always trust only the root CA (including OPNsense, including LDAP).
what am I doing wrong?)
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: franco on October 30, 2021, 04:14:39 pm
> Netscape Comment:

And people still rely on this mechanic?

Code: [Select]
The following extensions are non standard, Netscape specific and largely obsolete. Their use in new applications is discouraged.

Netscape String extensions.

Netscape Comment (nsComment) is a string extension containing a comment which will be displayed when the certificate is viewed in some browsers.

And isn't the problem simply that the LDAP server does not return its intermediate where the new compat settings needs to be enabled?


Cheers,
Franco
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: iam on October 30, 2021, 04:25:45 pm
> Netscape Comment:

And people still rely on this mechanic?

If this really a surprise for you? If you use the standard way for creating a self-signed certificate you still won't have a SAN entry in it. And many tools won't accept this today.

And isn't the problem simply that the LDAP server does not return its intermediate where the new compat settings needs to be enabled?


Cheers,
Franco

No there is no intermediate (what I think is fine for my small private setup. For enterprise probably not).
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: benyamin on October 31, 2021, 06:19:05 am
I'm sorry, but how does the second follow from the first? you say that trust is related to whether the CA is offline or online?

Im using offline root CA and M$ Enterprise subordinate CAs to issue certificates to services. and I always trust only the root CA (including OPNsense, including LDAP).
what am I doing wrong?)

The trust isn't related to whether a CA is online, but rather to the issuance of certificates. Spinning an offline root up to issue certs and CRLs is a security risk that should be kept to a minimum. The fact the root is offline is coincidental to my argument. My point was that the intermediate CA is the issuer.

In your case, the root and subordinate CA certs should both be imported to ensure that the entire chain of trust is available. Most systems will bork when there is a cert missing from the chain. It is noteworthy that some poorly implemented systems do not. Of those that do not, some will issue a warning or error message and others will silently continue.

From your experience, i.e. that it works without importing the subordinate CA cert, I see two possibilities:

The most likely is that the subordinate CA cert and the LDAP server cert have been concatenated within the one file. As such, the subordinate CA cert is available for verification as it is effectively imported with every download of the server cert.

I believe Franco alludes to this when he says:

And isn't the problem simply that the LDAP server does not return its intermediate where the new compat settings needs to be enabled? [Emphasis mine]

The other possibility is that the error is being suppressed. It is likely prudent to check which of these is occurring.

@franco: I don't think anyone was particularly relying on the nsComment. Fright mentioned the semantics here:

opnsense defines a certificate as root CA cert if it is self-signed. as a self-signed, in turn, it defines a certificate that does not have Authority Key Identifier or if Authority Key Identifier is equal to Subject Key Identifier.

Fright then correctly determined that the AuthorityKeyIdentifier extension is an array with KeyIdentifier held at AuthorityKeyIdentifier[0].

I note the pull request was merged at commit 898c1d5 (https://github.com/opnsense/core/commit/898c1d58f10e799ae98cae85d5a5fb9760239a61).
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: benyamin on October 31, 2021, 06:47:05 am
I should note if your LDAP service is ADDS, both the server and issuer certs are likely provided by the server.

You can check LDAPS certificate chains using Duo's tool (https://help.duo.com/s/article/4207?language=en_US) or similar.
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: Fright on October 31, 2021, 06:48:26 am
Quote
The fact the root is offline is coincidental to my argument
got it, thanks
Quote
the root and subordinate CA certs should both be imported to ensure that the entire chain of trust is available
https://datatracker.ietf.org/doc/html/rfc5246#section-7.4.2
server must provide full chain. and only "the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain"

Quote
I believe Franco alludes to this when he says
i beleive Franco hinted at the possibility of incorrect ldap server settings, as a result of which server not send the full (except root) chain

Quote
CA certs should both be imported to ensure that the entire chain of trust is available
importing intermediate certificates to trusted store can lead to unpredictable consequences, since different libraries and applications interpret the presence of an intermediate certificate in the store differently.
I am not saying that this should never be done at all (sometimes it is necessary for a specific behavior of the application, sometimes due to a server limitation), but in the overwhelming majority of cases this is done without reason. imho
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: Fright on October 31, 2021, 07:12:15 am
and besides, broadly trusting the intermediate CA you partially undermine the very idea of an offline root: there is no need to compromise the root CA, because applications that use intermediate certificates in the store as a trusted anchor will trust certificates issued by the intermediate authority (so it remains just to compromise the intermediate CA)
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: benyamin on October 31, 2021, 07:39:37 am
Fright, I think we are mostly on the same page.

I note your comments re the RFC and the Certificate message and note that many times over the years I did not observe the full chain (less root CA) being sent by various servers. I'm not convinced that everyone reading the RFC would interpret it as saying the entire trust chain (less the root) MUST be present (despite the fact it should: the message MUST be sent, the first cert MUST be the server cert and each subsequent cert MUST certify the preceding cert). The lack of an explicit "MUST include all certificates in the chain with exception to the root CA which MAY be omitted", I'm sure would be read as an opportunity by certain developers to cut corners. I'm pleased to see that would likely not apply to you.

In relation to LDAPS, I believe it's still the recommendation of many providers to import the whole certificate chain on clients. It is also my understanding that this remains best practice for most SSL/TLS services.

In relation to your last post, I note that if any CA was compromised, the respective cert(s) would need to be revoked and a CRL published. I presume this means that any Intermediate CA should be imported into System: Trust: Certificates (marked as a CA) and the corresponding root CA to System: Trust: Authorities. I only say this because I presume a CA listed under Authorities cannot be revoked... I think this would mitigate the risk you mentioned (and provide another level of protection), yes...?

I cannot say I recall ever witnessing "unpredictable consequences" of importing intermediate CA certs into trusted stores (not to say it doesn't happen), but would say that stores that provide demarcation between different CA types would probably mitigate such behaviour. It appears that OPNsense provides such distinction, even if it is somewhat ambiguous.

Finally, I note my previous post, and suggest it best to "trust, but verify", if you'll pardon the pun.  :D
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: Fright on October 31, 2021, 08:10:53 am
Quote
I'm sure would be read as an opportunity by certain developers to cut corners
to be honest, I do not understand how can understand this otherwise if read the whole phrase (where it is indicated what exactly can be omitted)
Quote
I believe it's still the recommendation of many providers to import the whole certificate chain on clients
official recommendation or just mentioned in various 'guides'? )
as I said, I understand that various options are possible (forced chain of trust, poorly implemented server etc.), but this should be a reluctant measure and not the main order imho
Quote
any Intermediate CA should be imported into System: Trust: Certificates ...I think this would mitigate the risk you mentioned (and provide another level of protection), yes...?
hm..given the fact that the certificates from the System: Trust: Certificates are not flushed into the trusted store?  ;) Certainly )
Quote
I cannot say I recall ever witnessing "unpredictable consequences" of importing intermediate CA certs into trusted stores
you can search for Lets Encrypt issues last month
or you can import outdated intermediate cert to trust store (say LE again) and try to curl something (say letsencrypt.org)
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: benyamin on October 31, 2021, 03:07:59 pm
you can search for Lets Encrypt issues last month
or you can import outdated intermediate cert to trust store (say LE again) and try to curl something (say letsencrypt.org)
Not sure the LE issues would qualify here. I use plenty of LE certs and had no issue making sure they were using appropriate chains. I also only had one device old enough not to have the new(er) root CA (ISRG Root X1) and intermediate CA (ISRG R3) in it's store (due to lack of vendor updates). This seemed more an issue of poor PKI management for affected vendors than anything else.

Would your second example actually work..?!? Wouldn't the cert be detected as "expired"...? That would be the "expected" behaviour for their old R3 intermediate CA cert which was cross-signed by IdenTrust as it also retired on September 30.

I would have thought having the proper intermediate CA in the store would help mitigate against servers providing certificate messages with expired issuing CAs... I recall seeing a couple of reverse proxies where this was the case.   

hm..given the fact that the certificates from the System: Trust: Certificates are not flushed into the trusted store?  ;) Certainly )
Having had a play with it, I don't actually think this will work (importing into Certificates rather than Authorities). The private key must be imported for this to work which is not appropriate in this instance.

Having thoroughly hijacked this thread, I think it best to start a new topic to continue this worthwhile discussion. The new topic is here (https://forum.opnsense.org/index.php?topic=25378.0).
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: kingfisher77 on October 31, 2021, 03:55:39 pm
Same problem here (same?). We use a self signed root CA and TLS connection to the LDAP/Samba AD worked for long time. All of a sudden, with 21.7.4, it stopped working. We do not have an intermediate certificate.
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: benyamin on October 31, 2021, 04:18:37 pm
There was a regression which causes some root CA certs to be identified as intermediates.

More info here (https://github.com/opnsense/core/pull/5323) and here (https://github.com/opnsense/core/issues/5328) and here (https://github.com/opnsense/core/issues/5314).

The commit with the fix is 899c1d5 (https://github.com/opnsense/core/commit/898c1d58f10e799ae98cae85d5a5fb9760239a61).

You should be able to fix it by checking the Systems: Settings: General > Trust > Store intermediate checkbox, or at the console shell with:

Code: [Select]
opnsense-patch 898c1d5
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: kingfisher77 on October 31, 2021, 05:39:24 pm
Thank you, that worked  8)
Title: Re: LDAP auth ins't working since update to 2.7.4
Post by: kingfisher77 on October 31, 2021, 05:40:57 pm
Thank you, that worked  8)

After reboot.