[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: TLS QUESTION
Am Tue, 11 Mar 2014 15:57:54 -0400
schrieb "Borresen, John - 0442 - MITLL" <John.Borresen@ll.mit.edu>:
> 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.
You could create a pkcs12 package, but that would not be recognized,
AFAIK. And there is no configuration parameter for a openssl generated
pkcs12 file.
-Dieter
> -----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
> > >
> > >
> > >
> > > --
> > > 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
--
Dieter KlÃnter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53Â37'09,95"N
10Â08'02,42"E