Guten morgen Dieter; I ran the openssl commands indicated below. But, ran them against my cacert.pem -- both the original and new successfully (they failed with servercrt.pem). I re-ran the CA.sh script this morning, and receiving the following errors when creating a new CA: Certificate is to be certified until Mar 8 13:09:05 2024 GMT (3650 days) failed to update database TXT_DB error number 2 -----Original Message----- From: Dieter KlÃnter [mailto:dieter@dkluenter.de] Sent: Monday, March 10, 2014 5:12 PM To: Borresen, John - 0442 - MITLL Subject: Re: TLS QUESTION Am Mon, 10 Mar 2014 16:55:04 -0400 schrieb "Borresen, John - 0442 - MITLL" <John.Borresen@ll.mit.edu>: > Vielen Danke Dieter; > > Originally my command to create the client.pem was: > > grep -A 100 CERTIFICATE cacert.pem > client.pem > > Then I scp'd that out to the clients. That worked when doing SSL on > port 636 (and not wild-card certificates), but it is not working now > on TLS over 389 to mm-server1 and mm-server3 with wild-card certs. > > The cacert.pem and client.pem is on each client. > > Doing further reading...the client.pem since it was built off the > cacert.pem (the server certificate) it should work. > > Should I use the cacert.pem or the servercrt.pem to create the > client.pem? Test this on each host openssl verify -CAfile path/to/ca client.pem servercert.pem openssl x509 -in servercert.pem -noout -text check for Common Name -Dieter > > > > > > -----Original Message----- > From: Dieter KlÃnter [mailto:dieter@dkluenter.de] > Sent: Monday, March 10, 2014 2:41 PM > To: Borresen, John - 0442 - MITLL > Subject: Re: TLS QUESTION > > Am Mon, 10 Mar 2014 13:33:53 -0400 > schrieb "Borresen, John - 0442 - MITLL" <John.Borresen@ll.mit.edu>: > > > Thanks Dieter... > > > > As I stated I saw Howard Chu's response to an individual in 2005 > > with a similar issue and he stated then, " For the slapd server you > > use the corresponding TLSCACertificateFile directive. You must use > > these configuration directives if you want to accept a self-signed > > cert." > > > > I did add the olcTLSCACertificateFile attribute (just forgot to list > > it in my original post). Was not certain at the time if the > > "olcTLSCertificateFile" should be removed so I did not remove it. > > So, before I do remove it, the attribute should be > > "olcTLSCACertificateFile" instead of "olcTLSCertificateFile" (and > > this should be removed), correct? > > > > The CA directories on all three servers look like this: > > > > # ll > > total 28 > > lrwxrwxrwx 1 root root 10 Jan 24 11:44 600f07a1.0 -> cacert.pem > > --> client hash -rw-r--r-- 1 ldap ldap 5136 Jan 17 12:15 cacert.pem > > --> Self-signed certificate -rw-r--r-- 1 ldap ldap 1090 Jan 17 > > 12:07 cert.csr --> Certificate Signing Request -rw-r--r-- 1 ldap > > ldap 1757 Jan 17 12:23 client.pem --> Client Certificate PEM > > -rw-r--r-- 1 ldap ldap 0 Jan 14 16:20 index.txt drwxr-xr-x 2 > > ldap ldap 4096 Jan 14 16:18 newcerts (empty) drwxr-xr-x 2 ldap ldap > > 4096 Jan 17 12:06 private --> server private key directory > > (cakey.pem) -rw-r--r-- 1 ldap ldap 3 Jan 17 11:59 serial > > This may sound like a dumb question... > > > > I created the client.pem from the cacert.pem (as indicated on > > openssl.org) then copied that to each client. Is there a step I > > missed in there? > > Yes, you have to create a client certificate for each host, while the > Common Name must match the FQDN of this host. my blog entry may be of > help: > > https://sys4.de/de/blog/2013/08/20/how-create-and-administer-x509-cert > ificate-chains-part-i > > -Dieter > > > If so, where? > > > > Thanks in advance > > > > John > > -----Original Message----- > > From: openldap-technical-bounces@OpenLDAP.org > > [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Dieter > > KlÃnter Sent: Monday, March 10, 2014 12:58 PM To: > > openldap-technical@openldap.org Subject: Re: TLS QUESTION > > > > Am Mon, 10 Mar 2014 11:18:14 -0400 > > schrieb "Borresen, John - 0442 - MITLL" <John.Borresen@ll.mit.edu>: > > > > > All, > > > > > > > > > > > > My set up consists of three servers each syncing with each other. > > > The host names are: > > > > > > 1) mm-server1.example.ldap > > > > > > 2) mm-server2.example.ldap > > > > > > 3) mm-server3.example.ldap > > > > > > > > > > > > Utilizing TLSv1, on all three I have: > > > > > > olcTLSCertificateFile: > > > /usr/local/openldap/etc/openldap/CA/cacert.pem > > > > this should be opcTLSCAcertificateFile > > > > > > > > olcTLSCertificateKeyFile: > > > /usr/local/openldap/etc/openldap/CA/private/cakey.pem > > > > you are misssing the host certificate, something like > > olcTLSCertificateFile /usr/local/openldap/etc/openldap/CA/host.pem > > > > > > > > olcTLSCipherSuite: HIGH:MEDIUM+TLSv1+SSLv3 > > > > > > > > > > > > Configured with self-signed wild-card certs, originally configured > > > (using openssl 0.9.8) on mm-server2 and exported to the other > > > servers. > > > > > > > > > > > > When running ldapmodify, ldapsearch, etc with a "-Z", and openssl > > > s_client on mm-server1 or mm-server3 or any client pointing back > > > to mm-server1 or 3, I receive the following error: > > > > > > > > > > > > TLS certificate verification: Error, self signed certificate > > > > > > TLS: can't connect: error:14090086:SSL > > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > > > (self signed certificate). > > > > > > ldap_start_tls: Connect error (-11) > > > > > > additional info: error:14090086:SSL > > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > > > (self signed certificate) > > > > > > > > > > > > Running any of those to mm-server2, it works with no such error. > > > > > > > > > > > > I am guessing, that since the certs were created on mm-server2, > > > originally, that is why it works this way. Also, guessing I > > > missed a step somewhere. > > > > > > > > > > > > I read online a post from 2005 with a good explanation of > > > self-signed from Howard Chu about a similar problem. > > > > > > > > > > > > What is the best procedure for creating wild-card certs and > > > sharing those out to other servers? The procedure that was used > > > was from openssl.org so it was not a fly-by-night weblog. > > > > > > > > > > > > What did I miss (besides: a lot)? > > > > > > > > > > > > Thanks in advance, > > > > > > > > > > > > > > > > > > John D. Borresen (Dave) > > > > > > Linux/Unix Systems Administrator > > > > > > MIT Lincoln Laboratory > > > > > > Surveillance Systems Group > > > > > > 244 Wood St > > > > > > Lexington, MA 02420 > > > > > > Ph: (781) 981-1609 > > > > > > Email: john.borresen@ll.mit.edu > > > > > > > > > > > > > > > > > -- > > Dieter KlÃnter | Systemberatung > > http://sys4.de > > GPG Key ID: E9ED159B > > 53Â37'09,95"N > > 10Â08'02,42"E > > > > > > -- > Dieter KlÃnter | Systemberatung > http://sys4.de > GPG Key ID: E9ED159B > 53Â37'09,95"N > 10Â08'02,42"E -- Dieter KlÃnter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53Â37'09,95"N 10Â08'02,42"E
Attachment:
smime.p7s
Description: S/MIME cryptographic signature