Thanks Howard... I would agree, that didn't make any sense to me not to mention didn't seem correct. Thus my question. I know you've said it before...there is a lot of misinformation out there! Thanks, John -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Tuesday, March 11, 2014 4:59 PM To: Borresen, John - 0442 - MITLL; openldap-technical@openldap.org Subject: Re: tls question Borresen, John - 0442 - MITLL wrote: > > All, > > Can the > > olcTLSCACertificateFile > and > olcTLSCertificateFile > > be the same file? Finding some "interesting" examples online (even on some openssl.org pages) and would like clarification. In one specific case, yes. That's a stupid way to configure things though. The specific case is when the file contains only a single certificate, and it means that you're using your self-signed CA cert as a server cert. Doing so is pretty far from "best-practice." > > Thanks, > John > > -----Original Message----- > From: Dieter KlÃnter [mailto:dieter@dkluenter.de] > Sent: Tuesday, March 11, 2014 2:17 PM > To: Borresen, John - 0442 - MITLL > Cc: openldap-technical@openldap.org > Subject: Re: TLS QUESTION > > Am Tue, 11 Mar 2014 13:15:21 -0400 > schrieb "Borresen, John - 0442 - MITLL" <John.Borresen@ll.mit.edu>: > >> Dieter; >> >> Now, receiving the following when attempting to sign the cert: >> >> Using configuration from /etc/pki/tls/openssl.cnf Enter pass phrase >> for /usr/local/openldap/etc/openldap/CA_test/private/cakey.pem: Error >> reading certificate request in /etc/openldap/CA_test/newreq.pem >> 2729:error:0906D06C:PEM routines:PEM_read_bio:no start >> line:pem_lib.c:647:Expecting: CERTIFICATE REQUEST Signed certificate >> is in newcert.pem > > I would sys you delete all certificates and certificate database files and restart from scratch. If you are using the openssl CA tools in order to create certificates, /etc/ssl/openssl.cnf should be modified to meet your requirements (in particular FQDN). Run ./CA.pl -newca ./CA.pl -newreq ./CA.pl -sign openssl rsa -in nrewreq.pem -out myKey.pem mv newcert.pem host.pem ./CA.pl -verify host.pem > > -Dieter > >> >> -----Original Message----- >> From: Dieter KlÃnter [mailto:dieter@dkluenter.de] >> Sent: Tuesday, March 11, 2014 9:31 AM >> To: Borresen, John - 0442 - MITLL >> Cc: openldap-technical@openldap.org >> Subject: Re: TLS QUESTION >> >> Am Tue, 11 Mar 2014 09:19:15 -0400 >> schrieb "Borresen, John - 0442 - MITLL" <John.Borresen@ll.mit.edu>: >> >>> 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 >> >> This is an error of your certificate database files index.txt and >> serial. >> >> -Dieter >> >> >> >>> -----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- >>>> ce >>>> rt >>>> 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 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Attachment:
smime.p7s
Description: S/MIME cryptographic signature