Re: Doubt regarding the cert that signs the CRL

["Peter A. Savitch" <spam4octan@highway.ru>]

Hello Chandra,

Saturday, August 10, 2002, 5:30:46 PM, you wrote:

CSS> I have a doubt regarding the certificate that signs the CRL.

I can tell You my practice. I post this kind of tutorial on LDAP/TLS
for all people interested. You may skip several parts.

First, I've made my own CA.
Then I've made certificate(s) for the LDAP server(s) and signed it
with my CA. And for client(s), also signed with my CA (You should make
different certificates for each client, and sign them with the same
CA). Then I deployed my CA certificate across all my network. I put my
CA key in some place outside the network (well, I print it on a plain
paper, delete the file and wiped out my HDD several times ;-)
I use FQDN for `Common Name' when generating server certificates.
I set 400 mode for keys and 444 for the certificates.

OpenLDAP settings follow. I declare my CA as the only one trusted CA
and set `hard' client verification:

=begin slapd.conf
TLSCipherSuite                  HIGH
TLSCACertificateFile            /home/ldap/etc/MY-CA-CERT
TLSCertificateFile              /home/ldap/etc/server.crt
TLSCertificateKeyFile           /home/ldap/etc/server.key
TLSVerifyClient                 hard
=end slapd.conf

I run slapd with only `secure' listeners, ldaps:// and ldapi://.

Now, every LDAP client must check server's CA (`hard' server
verification):

=begin ldaprc
TLS_CACERT      /home/ldap/etc/MY-CA-CERT
TLS_CERT        /home/ldap/etc/client.crt
TLS_KEY         /home/ldap/etc/client.key
TLS_REQCERT     hard
=end ldaprc

Note: You can not set client key/cert in a system-wide ldap.conf,
*only* in $HOME/.ldaprc, $HOME/ldaprc, $HOME/$LDAPRC or through the
environment. See ldap.conf(5). These are `user options'.

I established two servers (A and B) and two clients (replicator A->B
and WWW management agent, PHP-enabled Apache).

This way I set replicator:

=begin slapd.conf
replica
  host = server-a.domain.org:636
=end slapd.conf
  
=begin slurpd.conf
TLS             hard
TLS_CACERT      /home/ldap/etc/MY-CA-CERT
TLS_CERT        /home/ldap/etc/client.crt
TLS_KEY         /home/ldap/etc/client.key
TLS_REQCERT     hard
=end slurpd.conf

Note that I declare port 636 explicitly and set TLS=hard to connect to
ldaps:// server. There is no way to set URL for replicator in
slapd.conf. Again, I do not use insecure ldap:// at all.
I run slurpd this way:

LDAPRC=etc/slurpd.conf /opt/ldap/libexec/slurpd \
  -f $HOME/etc/slapd.conf

Now, let's run Apache. I've built DSO Apache with it's mod_ssl and
mod_php4. I've made PHP4 `ldap' shared extension. I can only load this
extension within php.ini or dl(), not Apache php_value. It seems to be
broken.

This way I propagate my LDAP TLS settings to ldap-php-enabled Apache:

LDAPTLS_CACERT=$HOME/etc/MY-CA-CERT \
LDAPTLS_CERT=$HOME/etc/client.crt \
LDAPTLS_KEY=$HOME/etc/client.key \
LDAPTLS_REQCERT=hard \
PHPRC=$HOME/etc \
/opt/apaches/DSO/bin/httpd -d "$HOME"

I want my PHP to have it's own custom php.ini, not system-wide
(PHPRC). 

The above steps brings us the following:
 1) Client is 100% sure about the server.
 2) Server is 100% sure about the client.
 3) No plain-text information is ever transferred across the network.
 3a) Replication is done with TLS without STARTTLS also.
 4) LDAP plain text authentication can be used. Better use SASL.
 5) UNIX domain sockets can be protected by means of file system
 permissions.
 6) SSL checking is made only on CA validity and server FQDN.

Files client.crt and client.ket can be the same across all `trusted'
entities and they should be different among all others. It's better to
keep them different. If one of  Your entities gets compromised, You
can simply change the key/cert for that entity. But if Your CA key
gets compromised, You should create the new CA, and repeat all the
sequence from scratch. Compromised CA makes every certificates signed
with it compromised.

That way I start Apache can be used for every OpenLDAP-enabled client
application. Read ldap.conf(5) for details. Use manpage from
OpenLDAP-2.1, because 2.0 man is incomplete, but mostly compatible
with 2.0 `stable' release. I've made a patch for 2.0 that brings me
2.1 TLS functionality (I don't use 2.1 nor HEAD because it's
unstable).

Note: ENVIRONMENT VARIABLES IS INSECURE UNDER SOME CIRCUMSTANCES.
They can be considered `secure' only in some particular situations.

Bye.
-- 
Best regards,
 Peter                            mailto:spam4octan@highway.ru