I have searched the faq-o-matic, google, the admin guide, and I cannot find any documentation that will allow me to set up my OpenLDAP 2.4.25 server using an SSL certificate that was issued from a CA that uses intermediate certificates (by, which I mean to indicate any commercial SSL cert company currently selling certs).
Apache has the SSLCertificateChainFile directive to handle this. OpenLDAP seems to be lacking this functionality.
I have tried placing both the server certificate and the intermediate certificate in the same file. OpenLDAP won't start if I put the intermediate certificate first, and openssl fails to verify the certificate chain if I put the server certificate first in the file.
Have I missed something obvious or has OpenLDAP really forced me into the position of needing to add the intermediate certificate from my SSL CA Vendor into my trusted store on all my clients?
On Fri, 29 Jul 2011, Francis Swasey wrote:
I have searched the faq-o-matic, google, the admin guide, and I cannot find any documentation that will allow me to set up my OpenLDAP 2.4.25 server using an SSL certificate that was issued from a CA that uses intermediate certificates (by, which I mean to indicate any commercial SSL cert company currently selling certs).
Apache has the SSLCertificateChainFile directive to handle this. OpenLDAP seems to be lacking this functionality.
I have tried placing both the server certificate and the intermediate certificate in the same file. OpenLDAP won't start if I put the intermediate certificate first, and openssl fails to verify the certificate chain if I put the server certificate first in the file.
Have I missed something obvious or has OpenLDAP really forced me into the position of needing to add the intermediate certificate from my SSL CA Vendor into my trusted store on all my clients?
It's a CA cert; have you tried adding it to the file specified by the TLSCACertificateFile option?
Philip Guenther
On 7/29/11 3:09 PM, Philip Guenther wrote:
On Fri, 29 Jul 2011, Francis Swasey wrote:
I have tried placing both the server certificate and the intermediate certificate in the same file. OpenLDAP won't start if I put the intermediate certificate first, and openssl fails to verify the certificate chain if I put the server certificate first in the file.
Have I missed something obvious or has OpenLDAP really forced me into the position of needing to add the intermediate certificate from my SSL CA Vendor into my trusted store on all my clients?
It's a CA cert; have you tried adding it to the file specified by the TLSCACertificateFile option?
Well, I never looked at it that way. Yes, adding the intermediate certificate to the file pointed to by the TLSCACertificateFile option on the OpenLDAP server appears to have worked.
Thanks, Frank
Frank Swasey wrote:
On 7/29/11 3:09 PM, Philip Guenther wrote:
On Fri, 29 Jul 2011, Francis Swasey wrote:
I have tried placing both the server certificate and the intermediate certificate in the same file. OpenLDAP won't start if I put the intermediate certificate first, and openssl fails to verify the certificate chain if I put the server certificate first in the file.
Have I missed something obvious or has OpenLDAP really forced me into the position of needing to add the intermediate certificate from my SSL CA Vendor into my trusted store on all my clients?
It's a CA cert; have you tried adding it to the file specified by the TLSCACertificateFile option?
Well, I never looked at it that way. Yes, adding the intermediate certificate to the file pointed to by the TLSCACertificateFile option on the OpenLDAP server appears to have worked.
Amaazing what trouble you could save yourself if you actually read the documentation.
http://www.openldap.org/doc/admin24/tls.html#Server%20Configuration Section 16.2.1.1
2011/7/30 Howard Chu hyc@symas.com:
Frank Swasey wrote:
On 7/29/11 3:09 PM, Philip Guenther wrote:
On Fri, 29 Jul 2011, Francis Swasey wrote:
I have tried placing both the server certificate and the intermediate certificate in the same file. OpenLDAP won't start if I put the intermediate certificate first, and openssl fails to verify the certificate chain if I put the server certificate first in the file.
Have I missed something obvious or has OpenLDAP really forced me into the position of needing to add the intermediate certificate from my SSL CA Vendor into my trusted store on all my clients?
It's a CA cert; have you tried adding it to the file specified by the TLSCACertificateFile option?
Well, I never looked at it that way. Yes, adding the intermediate certificate to the file pointed to by the TLSCACertificateFile option on the OpenLDAP server appears to have worked.
Amaazing what trouble you could save yourself if you actually read the documentation.
He told he looked at the documentation. Documentation is not a novel, things must be organized to be easily found.
http://www.openldap.org/doc/admin24/tls.html#Server%20Configuration Section 16.2.1.1
I too think a configuration directive is missing here. The logic that says "this is a CA, you must place it in this CA file/path" is wrong. This directive (TLSCACertificateFile/Path) is used to verify the client certificate, and it shouldn't be used to place the certificates needed by the client to verify the server certificate.
Imagine this situation: - Root CA A, sub-CA A1 used to sign server certificates - Root CA B, sub-CA B1 used to sign client certificates - Server, Client, each one has a certificate signed by the correct CA (A1 and B1, respectively) - Client knows A (the trust anchor, maybe have been bundled with the software), B and B1 (it has received the whole certificate chain when it received its personal certificate - Server knows A and A1 (it received the whole certificate chain), and B (manually set by the admin), and maybe B1 (the admin could have set it, or he's waiting for the client to send it, both situations are valid and can be justified)
Actual OpenLDAP configuration would be to place B (and maybe B1) certificate in TLSCACertificateFile/Path element, to be able to verify the Client certificate. The Server must also place A1 in this element, so it can be sent to the Client to help it verify the Server certificate. So, during the TLS negotiation, B, A1, maybe B1, maybe A are sent to the Client for it to verify the Server certificate? (remember, this certificate is signed by A1, and A must already be known by the Client). That's a waste of bandwidth. What if B is a global CA, Bx are national ones (or similar decomposition, so we have a lot of Bx)? And, because A1 is in TLSCertificateFile/Path element, then Server will implicitly trust any certificate signed by the A+A1 chain? That's not what the admin has thought.
Erwann ABALEA wrote:
2011/7/30 Howard Chuhyc@symas.com:
Frank Swasey wrote:
On 7/29/11 3:09 PM, Philip Guenther wrote:
On Fri, 29 Jul 2011, Francis Swasey wrote:
I have tried placing both the server certificate and the intermediate certificate in the same file. OpenLDAP won't start if I put the intermediate certificate first, and openssl fails to verify the certificate chain if I put the server certificate first in the file.
Have I missed something obvious or has OpenLDAP really forced me into the position of needing to add the intermediate certificate from my SSL CA Vendor into my trusted store on all my clients?
It's a CA cert; have you tried adding it to the file specified by the TLSCACertificateFile option?
Well, I never looked at it that way. Yes, adding the intermediate certificate to the file pointed to by the TLSCACertificateFile option on the OpenLDAP server appears to have worked.
Amaazing what trouble you could save yourself if you actually read the documentation.
He told he looked at the documentation. Documentation is not a novel, things must be organized to be easily found.
If you are having trouble configuring TLS certificates on your server, and don't think to read the TLS Server Configuration section of the Guide, I doubt the problem is in the organization of the documentation.
http://www.openldap.org/doc/admin24/tls.html#Server%20Configuration Section 16.2.1.1
Actual OpenLDAP configuration would be to place B (and maybe B1) certificate in TLSCACertificateFile/Path element, to be able to verify the Client certificate. The Server must also place A1 in this element, so it can be sent to the Client to help it verify the Server certificate.
So, during the TLS negotiation, B, A1, maybe B1, maybe A are sent to the Client for it to verify the Server certificate? (remember, this certificate is signed by A1, and A must already be known by the Client). That's a waste of bandwidth.
The TLS library doesn't do anything so stupid, it only sends the certificates that are part of the chain from the subject's cert up to the root CA.
On 2011-07-30 14:14, Howard Chu wrote:
Erwann ABALEA wrote:
Actual OpenLDAP configuration would be to place B (and maybe B1) certificate in TLSCACertificateFile/Path element, to be able to verify the Client certificate. The Server must also place A1 in this element, so it can be sent to the Client to help it verify the Server certificate.
So, during the TLS negotiation, B, A1, maybe B1, maybe A are sent to the Client for it to verify the Server certificate? (remember, this certificate is signed by A1, and A must already be known by the Client). That's a waste of bandwidth.
The TLS library doesn't do anything so stupid, it only sends the certificates that are part of the chain from the subject's cert up to the root CA.
I think the real question here is if the CA chain that the server sends and the CA chain that the server uses to verify client certificates can be different.
In Apache, this is done with the SSLCertificateChainFile and SSLCACertificateFile directives. This makes it possible to have the server send a certificate chain that differs from the CAs it uses to verify clients. This is useful if you want to have a server certificate signed by one CA, but only accept client certificates signed by another CA.
This sounds like an OpenLDAP feature request to me.
David Hawes wrote:
On 2011-07-30 14:14, Howard Chu wrote:
Erwann ABALEA wrote:
Actual OpenLDAP configuration would be to place B (and maybe B1) certificate in TLSCACertificateFile/Path element, to be able to verify the Client certificate. The Server must also place A1 in this element, so it can be sent to the Client to help it verify the Server certificate.
So, during the TLS negotiation, B, A1, maybe B1, maybe A are sent to the Client for it to verify the Server certificate? (remember, this certificate is signed by A1, and A must already be known by the Client). That's a waste of bandwidth.
The TLS library doesn't do anything so stupid, it only sends the certificates that are part of the chain from the subject's cert up to the root CA.
I think the real question here is if the CA chain that the server sends and the CA chain that the server uses to verify client certificates can be different.
In Apache, this is done with the SSLCertificateChainFile and SSLCACertificateFile directives. This makes it possible to have the server send a certificate chain that differs from the CAs it uses to verify clients. This is useful if you want to have a server certificate signed by one CA, but only accept client certificates signed by another CA.
This sounds like an OpenLDAP feature request to me.
Think about why you would configure such a setup, and what it actually means. When you have a certificate of your own, signed by a particular CA, that obviously means that you must trust that CA. If you're going to accept a cert from another party that is signed by a different CA that obviously means that you must also trust the other CA. There is absolutely nothing gained from isolating these two CAs, on either side of the session.
OpenSSL (e.g.) already sends only the chain of certificates relevant to its own subject cert. The fact that all CAs are tossed into a single file (or directory) together is irrelevant; in memory it's all managed as a database and only the certs that it needs are accessed.
If there were indeed anything to be gained by such a feature, it would also need to be implemented on clients. Look around - do any web browsers allow you to isolate CAs like this?
It's utter nonsense.
On 2011-08-01 13:07, Howard Chu wrote:
David Hawes wrote:
On 2011-07-30 14:14, Howard Chu wrote:
Erwann ABALEA wrote:
Actual OpenLDAP configuration would be to place B (and maybe B1) certificate in TLSCACertificateFile/Path element, to be able to verify the Client certificate. The Server must also place A1 in this element, so it can be sent to the Client to help it verify the Server certificate.
So, during the TLS negotiation, B, A1, maybe B1, maybe A are sent to the Client for it to verify the Server certificate? (remember, this certificate is signed by A1, and A must already be known by the Client). That's a waste of bandwidth.
The TLS library doesn't do anything so stupid, it only sends the certificates that are part of the chain from the subject's cert up to the root CA.
I think the real question here is if the CA chain that the server sends and the CA chain that the server uses to verify client certificates can be different.
In Apache, this is done with the SSLCertificateChainFile and SSLCACertificateFile directives. This makes it possible to have the server send a certificate chain that differs from the CAs it uses to verify clients. This is useful if you want to have a server certificate signed by one CA, but only accept client certificates signed by another CA.
This sounds like an OpenLDAP feature request to me.
Think about why you would configure such a setup, and what it actually means. When you have a certificate of your own, signed by a particular CA, that obviously means that you must trust that CA. If you're going to accept a cert from another party that is signed by a different CA that obviously means that you must also trust the other CA. There is absolutely nothing gained from isolating these two CAs, on either side of the session.
What is gained is that the server can be explicit about what client certificates it will accept. This is useful if you want to use a separate CA for client auth and do not want to accept certs from the CA that signed the server's cert.
Suppose my server has a Verisign cert. If I add the Verisign CA chain to TLSCACertificateFile, I have just allowed all certs signed by any CA in that chain to do TLS client auth. If I want to allow clients signed by my own CA and not those signed by Verisign, I'm out of luck.
Again, Apache does this by having separate directives for assembling the certificate chain and specifying which CAs to trust for clients.
If there were indeed anything to be gained by such a feature, it would also need to be implemented on clients. Look around - do any web browsers allow you to isolate CAs like this?
In my example above it is not necessary to do anything on the client side. I am strictly talking about the server and what CAs it trusts for TLS client auth.
David Hawes wrote:
On 2011-08-01 13:07, Howard Chu wrote:
David Hawes wrote:
On 2011-07-30 14:14, Howard Chu wrote:
Erwann ABALEA wrote:
Actual OpenLDAP configuration would be to place B (and maybe B1) certificate in TLSCACertificateFile/Path element, to be able to verify the Client certificate. The Server must also place A1 in this element, so it can be sent to the Client to help it verify the Server certificate.
So, during the TLS negotiation, B, A1, maybe B1, maybe A are sent to the Client for it to verify the Server certificate? (remember, this certificate is signed by A1, and A must already be known by the Client). That's a waste of bandwidth.
The TLS library doesn't do anything so stupid, it only sends the certificates that are part of the chain from the subject's cert up to the root CA.
I think the real question here is if the CA chain that the server sends and the CA chain that the server uses to verify client certificates can be different.
In Apache, this is done with the SSLCertificateChainFile and SSLCACertificateFile directives. This makes it possible to have the server send a certificate chain that differs from the CAs it uses to verify clients. This is useful if you want to have a server certificate signed by one CA, but only accept client certificates signed by another CA.
This sounds like an OpenLDAP feature request to me.
Think about why you would configure such a setup, and what it actually means. When you have a certificate of your own, signed by a particular CA, that obviously means that you must trust that CA. If you're going to accept a cert from another party that is signed by a different CA that obviously means that you must also trust the other CA. There is absolutely nothing gained from isolating these two CAs, on either side of the session.
What is gained is that the server can be explicit about what client certificates it will accept. This is useful if you want to use a separate CA for client auth and do not want to accept certs from the CA that signed the server's cert.
Suppose my server has a Verisign cert. If I add the Verisign CA chain to TLSCACertificateFile, I have just allowed all certs signed by any CA in that chain to do TLS client auth. If I want to allow clients signed by my own CA and not those signed by Verisign, I'm out of luck.
Again, Apache does this by having separate directives for assembling the certificate chain and specifying which CAs to trust for clients.
Irrelevant. You're taking a mechanism designed for authentication and trying to use it for authorization, which is clearly a misuse of the technology.
A certificate is merely an assertion that an entity is the user they claim to be, nothing more. If you trust a given CA to issue certs at all, then you must trust users presenting certs issued by that CA are who they claim to be. That says nothing about whether they have any privileges on a system, only that their identity has been proven.
2011/8/2 Howard Chu hyc@symas.com:
David Hawes wrote:
[...]
What is gained is that the server can be explicit about what client certificates it will accept. This is useful if you want to use a separate CA for client auth and do not want to accept certs from the CA that signed the server's cert.
Suppose my server has a Verisign cert. If I add the Verisign CA chain to TLSCACertificateFile, I have just allowed all certs signed by any CA in that chain to do TLS client auth. If I want to allow clients signed by my own CA and not those signed by Verisign, I'm out of luck.
Again, Apache does this by having separate directives for assembling the certificate chain and specifying which CAs to trust for clients.
Irrelevant. You're taking a mechanism designed for authentication and trying to use it for authorization, which is clearly a misuse of the technology.
Who's talking about authorization? Here, the pointed problem is that you cannot have a CA used to prove the server's identity to clients, and a different CA so that clients can prove their identity. In your scheme, all the CAs are of equal value/trust.
The clients trust a set of CAs, your server needs to have a certificate signed by one of them. If your server accepts clients authenticated by a CA, they have to get a certificate delivered by that CA. Who decided that the CA used to identify the server must be the very same CA used to identify the clients?
A certificate is merely an assertion that an entity is the user they claim to be, nothing more. If you trust a given CA to issue certs at all, then you must trust users presenting certs issued by that CA are who they claim to be. That says nothing about whether they have any privileges on a system, only that their identity has been proven.
Again, nowhere in the message you're replying to is mentioned "authorization". Everything we're talking about is authentication. I can have a server identified by a Comodo/VeriSign/GoDaddy certificate, while in the same time accept only clients authenticated by my own CA. The X.509 model doesn't prevent this. Your construction does. And as a side effect, even if I use the same CA for both uses, OpenLDAP will send the root CA to clients in the TLS negociation phase, and this is absolutely useless (some milliseconds lost for each TLS (re)negociation).
2011/8/1 Howard Chu hyc@symas.com: [...]
If there were indeed anything to be gained by such a feature, it would also need to be implemented on clients. Look around - do any web browsers allow you to isolate CAs like this?
Yes. You can basically isolate CAs into 3 categories (they can interleave): - CAs trusted to issue server certs - CAs trusted to issue email certs - CAs trusted to issue code signing certs
It's utter nonsense.
What is non-sense is having a bag full of CAs for mixed usage. More, you even mix CAs that need to be sent to the client (so it can build a certificate path) with CAs that the server trust (to verify client certs).
Erwann ABALEA wrote:
2011/8/1 Howard Chuhyc@symas.com: [...]
If there were indeed anything to be gained by such a feature, it would also need to be implemented on clients. Look around - do any web browsers allow you to isolate CAs like this?
Yes. You can basically isolate CAs into 3 categories (they can interleave):
- CAs trusted to issue server certs
- CAs trusted to issue email certs
- CAs trusted to issue code signing certs
Again, nonsense. It's not up to the end-user to configure such things, it's up to the parent CA to set the appropriate keyUsage bits in the CA cert. Again *if you trust the CA in the first place* then you trust it, period. If you don't trust the CA to issue correctly generated certs, then that's a completely separate problem and you shouldn't be dealing with that CA anyway.
It's utter nonsense.
What is non-sense is having a bag full of CAs for mixed usage. More, you even mix CAs that need to be sent to the client (so it can build a certificate path) with CAs that the server trust (to verify client certs).
2011/8/2 Howard Chu hyc@symas.com:
Erwann ABALEA wrote:
2011/8/1 Howard Chuhyc@symas.com: [...]
If there were indeed anything to be gained by such a feature, it would also need to be implemented on clients. Look around - do any web browsers allow you to isolate CAs like this?
Yes. You can basically isolate CAs into 3 categories (they can interleave): - CAs trusted to issue server certs - CAs trusted to issue email certs - CAs trusted to issue code signing certs
Again, nonsense. It's not up to the end-user to configure such things, it's up to the parent CA to set the appropriate keyUsage bits in the CA cert. Again *if you trust the CA in the first place* then you trust it, period. If you don't trust the CA to issue correctly generated certs, then that's a completely separate problem and you shouldn't be dealing with that CA anyway.
Have you ever been involved in having your CA certificate accepted by a browser vendor? Do you really think that because the CA has set the basicConstraints and keyUsage extensions to become a CA, then it is equally trustful for whatever use? Have you ever read a CP and its associated CPS, to verify what the CA performs to validate an identity? Do you really think Mozilla CA Policy people, Microsoft Roiot CA program people, Opera equivalent team, CABForum members are all X.509 illiterate guys?
I replied to your question: "Look around - do any web browsers allow you to isolate CAs like this?". You can find this by yourself in your browser. Display the list of CAs included, chose one, and edit its "trust bits", you'll find at least the 3 presented categories. After that, go to the Mozilla CA Policy set of web pages, and read about it. It's public.
2011/8/1 Howard Chu hyc@symas.com:
David Hawes wrote:
[...]
Think about why you would configure such a setup, and what it actually means. When you have a certificate of your own, signed by a particular CA, that obviously means that you must trust that CA. If you're going to accept a cert from another party that is signed by a different CA that obviously means that you must also trust the other CA. There is absolutely nothing gained from isolating these two CAs, on either side of the session.
You've never been into such a situation. That doesn't mean such an isolation is irrelevant.
In a project I'm working on (that doesn't mean I'm the only guy who produced the certificates, in my basement, etc), servers have a certificate signed by a public CA, but can accept connections from client signed by their own CA. The servers and clients are disseminated all over the world, and are "country-level" (sorry for my bad english, I don't know how to translate it). For example, consider some countries: DE, US, UK, AU, ... Each of these countries have a server, signed by a public CA (so that everybody, even anonymous users, can connect and trust the server), but they deliver client auth certificates to other countries participants (verified by diplomatic means), signed by their own CA. That way, the German server only trusts German-CA-issued client certificates, and all the other country participants, when connecting to the German server, need to select the right client certificate.
OpenSSL (e.g.) already sends only the chain of certificates relevant to its own subject cert. The fact that all CAs are tossed into a single file (or directory) together is irrelevant; in memory it's all managed as a database and only the certs that it needs are accessed.
In "the certs that it needs", who is "it"? The server? How can the server know what are the needed certs for the client to build a certificate chain joining a trust anchor *he* (the client) only knows about?
I verified that on a GnuTLS-enabled OpenLDAP, the behavior you described is what happens, but I haven't tested with a more complicated chain (for example a cross certified CA certificate, which could then attach to several trust anchors). I also saw that because you place everything in the same file, the server sends the root CA to the client, which is useless (and therefore is a waste).
Erwann ABALEA wrote:
2011/8/1 Howard Chuhyc@symas.com:
David Hawes wrote:
[...]
Think about why you would configure such a setup, and what it actually means. When you have a certificate of your own, signed by a particular CA, that obviously means that you must trust that CA. If you're going to accept a cert from another party that is signed by a different CA that obviously means that you must also trust the other CA. There is absolutely nothing gained from isolating these two CAs, on either side of the session.
You've never been into such a situation. That doesn't mean such an isolation is irrelevant.
Go and read the X.509 spec. Go and read the TLS RFC (2246). You're spouting nonsense.
2011/8/2 Howard Chu hyc@symas.com:
Erwann ABALEA wrote:
2011/8/1 Howard Chuhyc@symas.com:
David Hawes wrote:
[...]
Think about why you would configure such a setup, and what it actually means. When you have a certificate of your own, signed by a particular CA, that obviously means that you must trust that CA. If you're going to accept a cert from another party that is signed by a different CA that obviously means that you must also trust the other CA. There is absolutely nothing gained from isolating these two CAs, on either side of the session.
You've never been into such a situation. That doesn't mean such an isolation is irrelevant.
Go and read the X.509 spec. Go and read the TLS RFC (2246). You're spouting nonsense.
I read it really often, as I'm involved in X.509 PKI since 1998, working for a large PKI operator, starting by being an SET CA operator for 8 banks and 3 brands. We host dozens of CAs on our facility; we deploy new ones everywhere in the world, auditing people, writing CP/CPS; we produced tens of millions of certificates; we produce millions of OCSP replies every day, and a lot of other services around PKI. I know X.509, and I know RFC2246/4346/5246, among others. Go tell Apache, Sun, Mozilla, Opera, Microsoft, and a bunch of other vendors that isolation of CAs is irrelevant, and come here after.
openldap-technical@openldap.org
-
David Hawes -
Erwann ABALEA -
Francis Swasey -
Frank Swasey
-
Howard Chu -
Philip Guenther