https://bugs.openldap.org/show_bug.cgi?id=10149
Issue ID: 10149 Summary: [PATCH] Allow certificates and keys to be read from URIs. Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs@openldap.org Reporter: minfrin@sharp.fm Target Milestone: ---
Add the LDAP_OPT_X_TLS_URIS and LDAP_OPT_X_TLS_CACERTURIS options to allow certificates and keys to be set using OpenSSL provider URIs.
The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Graham Leggett minfrin@sharp.fm. I have not assigned rights and/or interest in this work to any party.
The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2023 Graham Leggett Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.
https://bugs.openldap.org/show_bug.cgi?id=10149
--- Comment #1 from minfrin@sharp.fm minfrin@sharp.fm --- Created attachment 996 --> https://bugs.openldap.org/attachment.cgi?id=996&action=edit Allow certificates and keys to be read from URIs.
https://bugs.openldap.org/show_bug.cgi?id=10149
--- Comment #2 from minfrin@sharp.fm minfrin@sharp.fm --- Also visible here: https://github.com/openldap/openldap/pull/11
https://bugs.openldap.org/show_bug.cgi?id=10149
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs_review | Target Milestone|--- |2.7.0
https://bugs.openldap.org/show_bug.cgi?id=10149
minfrin@sharp.fm minfrin@sharp.fm changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #996 is|0 |1 obsolete| |
--- Comment #3 from minfrin@sharp.fm minfrin@sharp.fm --- Created attachment 1000 --> https://bugs.openldap.org/attachment.cgi?id=1000&action=edit Allow certificates and keys to be read from URIs.
Man page updates with examples of uris.
https://bugs.openldap.org/show_bug.cgi?id=10149
--- Comment #4 from minfrin@sharp.fm minfrin@sharp.fm --- Quick ping on this one.
This patch blocks the fixing of secure replication support in 389ds, which is currently limited to a restrictive certificate setup and is in turn fixed in https://github.com/389ds/389-ds-base/pull/6021.
Is there an option to have this included in the v2.6.x branch?
https://bugs.openldap.org/show_bug.cgi?id=10149
--- Comment #5 from Ondřej Kuzník ondra@mistotebe.net --- On Sun, Jan 12, 2025 at 10:47:45AM +0000, openldap-its@openldap.org wrote:
Quick ping on this one.
This patch blocks the fixing of secure replication support in 389ds, which is currently limited to a restrictive certificate setup and is in turn fixed in https://github.com/389ds/389-ds-base/pull/6021.
Hi Graham, would you be able to explain in more detail what this provides that cannot be achieved with existing options like LDAP_OPT_X_TLS_CACERT, ...?
Also if you want to open a MR on git.openldap.org, that would make review much easier for all involved but we don't insist on going that route. If you need your Gitlab account to be confirmed, please provide your account name here (and make sure its email matches your Bugzilla email).
Is there an option to have this included in the v2.6.x branch?
As a significant change in library API, I feel it unlikely to land in 2.6 unless it can be shown that it has no impact on existing installations.
Thanks,
https://bugs.openldap.org/show_bug.cgi?id=10149
--- Comment #6 from minfrin@sharp.fm minfrin@sharp.fm --- Due to a regression in openssl which broke error handling, the following additional workaround is needed until https://github.com/openssl/openssl/issues/26412 is fixed.
diff --git a/libraries/libldap/tls_o.c b/libraries/libldap/tls_o.c index ab9338944..1619e937a 100644 --- a/libraries/libldap/tls_o.c +++ b/libraries/libldap/tls_o.c @@ -556,7 +556,7 @@ tlso_ctx_init( struct ldapoptions *lo, struct ldaptls *lt, int is_server, char * } OSSL_STORE_INFO_free( info ); } - if (OSSL_STORE_error(sctx)) { + if (!OSSL_STORE_eof(sctx) && OSSL_STORE_error(sctx)) { Debug1( LDAP_DEBUG_ANY, "TLS: could not load from uri `%s'.\n", lo->ldo_tls_uris[i] ); @@ -776,7 +776,7 @@ tlso_ctx_init( struct ldapoptions *lo, struct ldaptls *lt, int is_server, char * } OSSL_STORE_INFO_free(info); } - if (OSSL_STORE_error(sctx)) { + if (!OSSL_STORE_eof(sctx) && OSSL_STORE_error(sctx)) { Debug1( LDAP_DEBUG_ANY, "TLS: could not load from uri `%s'.\n", lo->ldo_tls_uris[i] );
https://bugs.openldap.org/show_bug.cgi?id=10149
--- Comment #7 from minfrin@sharp.fm minfrin@sharp.fm --- (In reply to Ondřej Kuzník from comment #5)
would you be able to explain in more detail what this provides that cannot be achieved with existing options like LDAP_OPT_X_TLS_CACERT, ...?
The existing options are routed firmly in the 1990s, a time when keys and certificates were files on disk.
In the 2020s, keys and certificates exist in secure enclaves, such as TPM chips, smartcards (physical or virtual), or Hardware Security Modules.
The location of these certificates is no longer described with a filename or a directory on disk, but are instead described by a URI.
These URIs have been standardised, for example this RFC for URIs starting with pkcs11:
https://www.rfc-editor.org/rfc/rfc7512.html
OpenSSL has been updated in OpenSSL3 to use a new provider framework that is URI based. This replaces the old ENGINE mechanism.
What this patch does is offer a clean, safe, no-legacy-baggage, mechanism to access keys and certificates described by a URI.
In the long term it is expected that all prior options be deprecated.
Also if you want to open a MR on git.openldap.org, that would make review much easier for all involved but we don't insist on going that route. If you need your Gitlab account to be confirmed, please provide your account name here (and make sure its email matches your Bugzilla email).
Will do.
Is there an option to have this included in the v2.6.x branch?
As a significant change in library API, I feel it unlikely to land in 2.6 unless it can be shown that it has no impact on existing installations.
This patch isn't a change, but rather an addition.
Instead of changing existing behaviour, we add two new constants with clean, well defined semantics for the new way of accessing certs and keys. This will have no impact on existing installations because no existing installations have been changed.
The driver for this patch is the 389ds directory server. Originally, 389ds was developed against the NSS security library, which has the ability to store keys and certificates in smartcards and HSMs. At some point a number of years ago 389ds secure replication was updated to replace mozldap+nss with openldap+openssl. This created a regression - openldap+openssl did not have the ability to access smartcards or HSMs, so a hack was introduced where 389ds did a rudimentary attempt to export a certificate and key as files in a temporary directory for use by openldap+openssl, and the this was released mid-product-cycle on a number of distros. Bang, production outage, pain and suffering.
This patch brings openldap+openssl into the world of openssl providers, and allows 389ds to replicate securely using keys and certificates in smartcards and HSMs. Once this patch is in place and once the 389ds patch is in place, nine years of LDAP replication pain will go away.
-
openldap-its＠openldap.org