LDAP auth ins't working since update to 2.7.4

[Fright]

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?)

[franco]

> 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

[iam]

> 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).

[benyamin]

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.

[benyamin]

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 or similar.

[Fright]

The fact the root is offline is coincidental to my argument

got it, thanks

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"

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

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

[Fright]

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)

[benyamin]

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. 

[Fright]

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)

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

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 )

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)

[benyamin]

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.

[kingfisher77]

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.

[benyamin]

There was a regression which causes some root CA certs to be identified as intermediates.

More info here and here and here.

The commit with the fix is 899c1d5.

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

[kingfisher77]

Thank you, that worked 

[kingfisher77]

Thank you, that worked 

After reboot.