Internal SSL certificate is not standards compliant.

[kevdog]

Hi -

I’m using syncthing v 1.20.3 on MacOS Arm-64. I’ve have syncthing configured to used an LDAP server for GUI authentication. I’ve used this setup for at least about a year. Recently however I’m receiving an error using the program if I try to verify the server certificate which was working previously. Verification if done using the Advanced Options->LDAP->Insecure Skip Verify (leave unchecked).

For the LDAP connection I’m using a local LDAP server run via Docker on a Linux host with self signed certificates. The server certificate is a ecdsa-with-SHA384 using a prime256v1 curve with following attribute: X509v3 Extended Key Usage: TLS Web Server Authentication and the X509v3 Subject Alternative Name field contains the domain name I’m using to connect to the backend server.

The Syncthing client is a MacOS Monterey Client iOS 12.4. I’m not exactly sure how the Syncthing interacts with the underlying OS. I’ve uploaded the self signed CA root certificate and imported it within the System Keychain, so I’m aware the program using the MacOS system Keychain.

I ran across this article (which isn’t too old) discussing some of the changes MacOS recently introduced requirements for trusted certificates in iOS 13 and macOS 10.15. I perused through the requirements – specifically:

1. RSA keys > 2048 bits (I’m using ec-dsa certs so this isn’t really applicable in my case)

2. Hash algorithm in the SHA-2 family (I’m using SHA384 so I’ve met this requirement)

3. DNS Name must be listed within the SAN extension of the certificate (Met this requirement since I’m aware the CN field is no longer recognized)

4. TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID – (I’m pretty sure I’ve met this requirement since as listed above I have the X509v3 Extended Key Usage: TLS Web Server Authentication listed within the server certificate although the not totally clear on this)

5. • TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate). (Here is my certificate validity period which is definitely more than 825 days: Validity Not Before: Jan 3 14:56:12 2021 GMT Not After : Apr 11 14:56:12 2031 GMT ).
   • So it seems I don’t meet this last requirement. Unfortunately syncthing when it reports the error isn’t exactly specific on what requirement is not being fulfilled other than stating the x509 is not standards compliant. I’m guessing this error message within the logs is being generated by a library syncthing is using in this case and probably wasn’t exactly directly coded by the developer in this instance. Is there a way to discover the cause of this error specifically?

[calmh (Jakob Borg)]

Can you show us the actual error you see?

[kevdog]

Sure here is the error:

[Z2M6G] 2022/07/24 07:22:36 WARNING: LDAP Dial: LDAP Result Code 200 "Network Error": x509: “openldap” certificate is not standards compliant
[Z2M6G] 2022/07/24 07:22:36 INFO: Wrong credentials supplied during API authorization from 127.0.0.1:63805

[calmh (Jakob Borg)]

Right, Go uses the system TLS validation on macOS nowadays, which includes the checks you mention. So yes, you’ll run afoul of the validity period requirement. And yes, that is the error returned by the OS.

[kevdog]

I figured you used a Go Library, however error messages like this aren’t exactly helpful. Can’t they be more specific?? Standards compliance in this case could theoretically mean anything. It would be a lot more helpful if they could spit out what isn’t standards compliant however I’m guessing the library creators just kind of defaulted to throwing the errors into one big bucket and used the generic term “not standards compliant”.

[calmh (Jakob Borg)]

Like I said, the error comes from the OS. Your criticism is valid, but the proper target of it is Apple.

[kevdog]

So I went ahead and regenerated the server certificate:

sudo openssl ca -rand_serial -config ../openssl.cnf -extensions server_cert -days 825 -notext -md SHA512 -noemailDN -in cert-825.csr -out cert-825.pem

I loaded the new server certificate into the ldap server and restarted and can confirm I’m no longer getting any errors with a server certificate valid for 825 days. I unfortunately didn’t test this condition for any other instances however the certificate seems to be valid and not rejected on MacOSX.