Hi all,
A search in the openldap source shows we don’t yet support the OpenSSL3 provider OSSL_STORE_open() call, which takes a URL as a parameter.
I’m happy to patch the openldap client to support this, would it make sense to add a LDAP_OPT_X_TLS_URL option to ldap_option_set()?
Regards, Graham —
On 19 Dec 2023, at 12:45, Graham Leggett minfrin@sharp.fm wrote:
A search in the openldap source shows we don’t yet support the OpenSSL3 provider OSSL_STORE_open() call, which takes a URL as a parameter.
I’m happy to patch the openldap client to support this, would it make sense to add a LDAP_OPT_X_TLS_URL option to ldap_option_set()?
Patch available here:
https://bugs.openldap.org/show_bug.cgi?id=10149
This allows replication in 389ds to be fixed, with the patch available here for anyone interested:
https://github.com/389ds/389-ds-base/pull/6021
Regards, Graham —
Graham Leggett wrote:
On 19 Dec 2023, at 12:45, Graham Leggett minfrin@sharp.fm wrote:
A search in the openldap source shows we don’t yet support the OpenSSL3 provider OSSL_STORE_open() call, which takes a URL as a parameter.
I’m happy to patch the openldap client to support this, would it make sense to add a LDAP_OPT_X_TLS_URL option to ldap_option_set()?
Patch available here:
Looks a bit like a chicken'n'egg situation, why should anyone trust the connection that was used to retrieve certs and keys from the designated URI?
This allows replication in 389ds to be fixed, with the patch available here for anyone interested:
https://github.com/389ds/389-ds-base/pull/6021
Regards, Graham —
On 03 Jan 2024, at 18:02, Howard Chu hyc@symas.com wrote:
Looks a bit like a chicken'n'egg situation, why should anyone trust the connection that was used to retrieve certs and keys from the designated URI?
Not at all.
We’re referring to URIs known to crypto libraries, such as pkcs11 URLs (for smartcard interfaces) and tpmkey URIs for TPM chips.
https://www.rfc-editor.org/rfc/rfc7512.html https://datatracker.ietf.org/doc/html/draft-mavrogiannopoulos-tpmuri-01
By default OpenSSL always supports the file:// URI, which points at PEM encoded certs/keys/crls/params/etc.
Other URIs might point at the MacOS keychain, or the Windows crypto api. It’s up to the crypto library.
Regards, Graham —
Graham Leggett wrote:
On 03 Jan 2024, at 18:02, Howard Chu hyc@symas.com wrote:
Looks a bit like a chicken'n'egg situation, why should anyone trust the connection that was used to retrieve certs and keys from the designated URI?
Not at all.
We’re referring to URIs known to crypto libraries, such as pkcs11 URLs (for smartcard interfaces) and tpmkey URIs for TPM chips.
Probably worth noting this in the manpages too then, that these are generally not internet URIs.
https://www.rfc-editor.org/rfc/rfc7512.html https://datatracker.ietf.org/doc/html/draft-mavrogiannopoulos-tpmuri-01
By default OpenSSL always supports the file:// URI, which points at PEM encoded certs/keys/crls/params/etc.
Other URIs might point at the MacOS keychain, or the Windows crypto api. It’s up to the crypto library.
Regards, Graham —
On 03 Jan 2024, at 18:23, Howard Chu hyc@symas.com wrote:
We’re referring to URIs known to crypto libraries, such as pkcs11 URLs (for smartcard interfaces) and tpmkey URIs for TPM chips.
Probably worth noting this in the manpages too then, that these are generally not internet URIs.
I’ve just updated the patch accordingly.
https://bugs.openldap.org/show_bug.cgi?id=10149
Regards, Graham —
-
Graham Leggett -
Howard Chu