LDAP auth ins't working since update to 2.7.4

[iam]

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:

[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

[iam]

In /etc/ssl/cert.pem in found a line starting with

Code: [Select]

#(system local trust) skip intermediate certificate

related to my internal CA.

[iam]

Ok it might be faulty how UCS creates the CA. But anyway it would if the new behavior could be disabled:

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

I hope the part "by default" means exactly this.

[iam]

i've found the option in System -> Settings -> General. Thank you for implementing this option!

[Fright]

Hi
can you please explain why you use intermediate CA cert to trust the ldap server and not the root CA cert?

[benyamin]

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

[Fright]

@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

[iam]

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.

[Fright]

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

[iam]

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.

[Fright]

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?

[iam]

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

[Fright]

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

[Fright]

thanks! i made pull request for this
https://github.com/opnsense/core/pull/5323

[benyamin]

@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