Ok, Thank you for the information. During the restore i ran into https://fedorahosted.org/freeipa/ticket/4726 and sudo -u apache kdestroy fixed it. I think there was also something else minor that i was able to fix by running a command differently.
I had two clients that I HAD to get online due to a deadline, so i manually configured the clients using (http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/linux-manual.html) and they work fine now. I have a third client that I'm working with where i have some more time. This one is on the same VLAN as the directory server, so that eliminates and network related issues as a possibility. I ran openssl s_client -host dir1.example.com -port 443 -CAfile ca.crt against the ca.crt that was left from the failed install and it looks fine. I might try to regenerate the certificate and see if that helps although it looks like a real pain for verso 3 according to http://www.freeipa.org/page/Howto/CA_Certificate_Renewal#Procedure_in_IPA_.3C_4.0 [root@walker ipa]# openssl s_client -host dir1.example.com -port 443 -CAfile ca.crt CONNECTED(00000003) depth=1 O = example.com, CN = Certificate Authority verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/O=example.com/CN=dir1.example.com i:/O=example.com/CN=Certificate Authority 1 s:/O=example.com/CN=Certificate Authority i:/O=example.com/CN=Certificate Authority --- Server certificate -----BEGIN CERTIFICATE----- Masdfasdf more stuff here -----END CERTIFICATE----- subject=/O=example.com/CN=dir1.example.com issuer=/O=example.com/CN=Certificate Authority --- No client certificate CA names sent --- SSL handshake has read 2095 bytes and written 591 bytes --- New, TLSv1/SSLv3, Cipher is AES128-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.1 Cipher : AES128-SHA Session-ID: 22BBDF13AA4DDFFF7562A624D0A6B1B35B9999CE727FD59AFF1572B4928851DFB91B Session-ID-ctx: Master-Key: 9EF37866161FD89469DD5631744051123456788F5C035CB8F5E8A85F9B2FAAE96698F48559D1338C42B4F20FC Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1418237923 Timeout : 300 (sec) Verify return code: 19 (self signed certificate in certificate chain) --- <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="https://dir1.example.com/ipa/ui";>here</a>.</p> <hr> <address>Apache/2.2.15 (CentOS) Server at dir1.example.com Port 443</address> </body></html> closed On Wed, Dec 10, 2014 at 3:19 AM, Martin Kosek <mko...@redhat.com> wrote: > On 12/09/2014 03:57 PM, Megan . wrote: >> This is happening with all new clients. I had to rebuild the LDAP >> server onto new hardware and the network team put us on a new VLAN. >> so my physical server and IP changed. I was previously able to >> register clients, but after all of the changes, i can no longer >> register them. At this point i'm not sure if there is a network issue >> or something wrong with the IPA server. The existing clients are >> communicating fine, no errors or complains. I have two new clients to >> add and both have the same symptoms. >> >> I used these procedures to backup then restore onto the new host >> http://www.freeipa.org/page/V3/Backup_and_Restore >> >> To change the IP i just updated /etc/hosts and pushed it out to the clients > > This may be related. Did the backup and restore really go correctly? AFAIK, > this feature did not go through more heavy testing in the community yet, so > there may be rough edges. There were several bug fixes to backup and restore > scripts in FreeIPA 4.1.x releases already. > > But if the hostname is the same, A/AAAA and PTR DNS records are still valid > and > your other clients work fine, it should be OK. > > So you are saying that installation still fails with the NSS error -8054? I am > thinking that the next step should be to run ipa-client-install with --force > flag to make sure that it does not clean the certificate downloaded from LDAP > and check that the cert downloaded to /ect/ipa/ca.crt is indeed OK (you > already > tested the one downloaded by wget, but theoretically, the one in LDAP could be > different). > >> On Tue, Dec 9, 2014 at 9:05 AM, Rob Crittenden <rcrit...@redhat.com> wrote: >>> Megan . wrote: >>>> Everything looks ok. >>>> >>>> Our Networks team only opened 443 from the client to the server. is >>>> 80 required to be open too for registration? 80 is a lot harder for >>>> me to request on our network. >>>> >>>> I think I might have found the issue. Maybe it can't verify the CA >>>> because its pointing to port 80, and 80 isn't open. Is it possible to >>>> change the certificate so this information is available via 443 or >>>> does that not make sense since its trying to get information about the >>>> secure connection in the first place. >>> >>> I don't think port 80 is the problem and in any case, it is just a >>> fallback in case the client can't get it via LDAP which in new installs >>> shouldn't be an issue. You'd get an error that the CA couldn't be >>> retrieved at all and not that a duplicate serial existed. >>> >>> Is this happening on every client or just one? >>> >>> Did you have a previous IPA install and you are re-enrolling this >>> client(s) into the new one? >>> >>> rob >>> >>>> >>>> from the server: >>>> [root@dir1 ipa]# openssl verify -verbose -CAFile ca.crt >>>> . >>>> . >>>> Authority Information Access: >>>> OCSP - URI:http://dir1.example.com:80/ca/ocsp >>>> . >>>> >>>> >>>> >>>> [root@data2-uat ipa]# wget https://dir1.example.com/ipa/config/ca.crt >>>> -O /tmp/ipa.crt >>>> --2014-12-09 13:21:32-- https://dir1.example.com/ipa/config/ca.crt >>>> Resolving dir1.example.com... 172.28.27.170 >>>> Connecting to dir1.example.com|172.28.27.170|:443... connected. >>>> ERROR: cannot verify dir1.example.com’s certificate, issued by >>>> “/O=EXAMPLE.COM/CN=Certificate Authority”: >>>> Self-signed certificate encountered. >>>> To connect to dir1.example.com insecurely, use ‘--no-check-certificate’. >>>> [root@data2-uat ipa]# wget https://dir1.example.com/ipa/config/ca.crt >>>> -O /tmp/ipa.crt --no-check-certificate >>>> --2014-12-09 13:22:11-- https://dir1.example.com/ipa/config/ca.crt >>>> Resolving dir1.example.com... 172.28.27.170 >>>> Connecting to dir1.example.com|172.28.27.170|:443... connected. >>>> WARNING: cannot verify dir1.example.com’s certificate, issued by >>>> “/O=EXAMPLE.COM/CN=Certificate Authority”: >>>> Self-signed certificate encountered. >>>> HTTP request sent, awaiting response... 200 OK >>>> Length: 1357 (1.3K) [application/x-x509-ca-cert] >>>> Saving to: “/tmp/ipa.crt” >>>> >>>> 100%[================================================>] 1,357 >>>> --.-K/s in 0.005s >>>> >>>> 2014-12-09 13:22:11 (246 KB/s) - “/tmp/ipa.crt” saved [1357/1357] >>>> >>>> [root@data2-uat ipa]# cd /tmp >>>> [root@data2-uat tmp]# openssl s_client -host dir1.example.com -port >>>> 443 -CAfile /tmp/ipa.crt >>>> CONNECTED(00000003) >>>> depth=1 O = EXAMPLE.COM, CN = Certificate Authority >>>> verify return:1 >>>> depth=0 O = EXAMPLE.COM, CN = dir1.example.com >>>> verify return:1 >>>> --- >>>> Certificate chain >>>> 0 s:/O=EXAMPLE.COM/CN=dir1.example.com >>>> i:/O=EXAMPLE.COM/CN=Certificate Authority >>>> 1 s:/O=EXAMPLE.COM/CN=Certificate Authority >>>> i:/O=EXAMPLE.COM/CN=Certificate Authority >>>> --- >>>> Server certificate >>>> -----BEGIN CERTIFICATE----- >>>> ... >>>> -----END CERTIFICATE----- >>>> subject=/O=EXAMPLE.COM/CN=dir1.example.com >>>> issuer=/O=EXAMPLE.COM/CN=Certificate Authority >>>> --- >>>> No client certificate CA names sent >>>> --- >>>> SSL handshake has read 2095 bytes and written 591 bytes >>>> --- >>>> New, TLSv1/SSLv3, Cipher is AES128-SHA >>>> Server public key is 2048 bit >>>> Secure Renegotiation IS supported >>>> Compression: NONE >>>> Expansion: NONE >>>> SSL-Session: >>>> Protocol : TLSv1.1 >>>> Cipher : AES128-SHA >>>> Session-ID: >>>> F6A664BC942DF235EF546007379A79A00245G34FA7C0E6F191B911E9CFEC17D0 >>>> Session-ID-ctx: >>>> Master-Key: >>>> 8C9A5FB1DFDDA72FF09780A85A43FA3C1AA14D4FB199F510A0DC3DF0C53DFFFFCDD0F26211CA886342E84030EA891959 >>>> Key-Arg : None >>>> Krb5 Principal: None >>>> PSK identity: None >>>> PSK identity hint: None >>>> Start Time: 1418131359 >>>> Timeout : 300 (sec) >>>> Verify return code: 0 (ok) >>>> --- >>>> closed >>>> >>>> On Tue, Dec 9, 2014 at 4:18 AM, Martin Kosek <mko...@redhat.com> wrote: >>>>> On 12/08/2014 08:00 PM, Megan . wrote: >>>>>> I looked through the logs on the server and i see the below error in >>>>>> the apache error log when i try to register a client: >>>>>> >>>>>> [Mon Dec 08 12:20:38 2014] [error] SSL Library Error: -12195 Peer does >>>>>> not recognize and trust the CA that issued your certificate >>>>>> >>>>>> >>>>>> I ran ipa-getcert list and everything seems ok (nothing expired) but >>>>>> i'm not sure where to troubleshoot from here. >>>>> >>>>> The next step would be to check the actual HTTP certificate (on the client >>>>> machine) and see what's wrong. I did a simple test you can follow: >>>>> >>>>> # wget http://ipa.mkosek-f21.test/ipa/config/ca.crt -O /tmp/ipa.crt >>>>> # openssl s_client -host ipa.mkosek-f21.test -port 443 -CAfile >>>>> /tmp/ipa.crt >>>>> CONNECTED(00000003) >>>>> depth=1 O = MKOSEK-F21.TEST, CN = Certificate Authority >>>>> verify return:1 >>>>> depth=0 O = MKOSEK-F21.TEST, CN = ipa.mkosek-f21.test >>>>> verify return:1 >>>>> --- >>>>> Certificate chain >>>>> 0 s:/O=MKOSEK-F21.TEST/CN=ipa.mkosek-f21.test >>>>> i:/O=MKOSEK-F21.TEST/CN=Certificate Authority >>>>> 1 s:/O=MKOSEK-F21.TEST/CN=Certificate Authority >>>>> i:/O=MKOSEK-F21.TEST/CN=Certificate Authority >>>>> --- >>>>> Server certificate >>>>> ... >>>>> SSL-Session: >>>>> Protocol : TLSv1.2 >>>>> Cipher : AES128-SHA >>>>> Session-ID: >>>>> 5A4B326D2E8FB80408D628D1975C49C4F78D3E65F31E475F9E7B9BBBE11F576E >>>>> Session-ID-ctx: >>>>> Master-Key: >>>>> D5C31E9E36503ADC9F162439B41A7A608260D7DF5EB357FB3D79C9CFAE700912526893E7DD9AA56F5B6CD320FBA98C49 >>>>> Key-Arg : None >>>>> Krb5 Principal: None >>>>> PSK identity: None >>>>> PSK identity hint: None >>>>> Start Time: 1418073191 >>>>> Timeout : 300 (sec) >>>>> Verify return code: 0 (ok) >>>>> --- >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Dec 5, 2014 at 7:51 PM, Megan . <nagem...@gmail.com> wrote: >>>>>>> It failed again. >>>>>>> >>>>>>> >>>>>>> [root@cache2-uat ~]# certutil -L -d sql:/etc/pki/nssdb >>>>>>> >>>>>>> Certificate Nickname Trust >>>>>>> Attributes >>>>>>> >>>>>>> SSL,S/MIME,JAR/XPI >>>>>>> [root@cache2-uat ~]# >>>>>>> >>>>>>> Not sure if its related, but on the directory server in the apache >>>>>>> error.log I see the below every time a client tries to register: >>>>>>> >>>>>>> [Sat Dec 06 00:48:35 2014] [error] SSL Library Error: -12271 SSL >>>>>>> client cannot verify your certificate >>>>>>> >>>>>>> On the directory server i ran ipa-getcert list and the certs seem ok. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Dec 5, 2014 at 5:10 PM, Rob Crittenden <rcrit...@redhat.com> >>>>>>> wrote: >>>>>>>> Megan . wrote: >>>>>>>>> Sorry for being unclear. It still fails. Same error. >>>>>>>> >>>>>>>> Hmm, strange. Try being explicit about sql: >>>>>>>> >>>>>>>> # certutil -L -d sql:/etc/pki/nssdb >>>>>>>> >>>>>>>> And if there is a CA cert there, delete it. >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>>>> >>>>>>>>> On Dec 5, 2014 4:39 PM, "Rob Crittenden" <rcrit...@redhat.com >>>>>>>>> <mailto:rcrit...@redhat.com>> wrote: >>>>>>>>> >>>>>>>>> Megan . wrote: >>>>>>>>> > Thanks. >>>>>>>>> > >>>>>>>>> > I did have an issue last week where i tried to do the client >>>>>>>>> install >>>>>>>>> > and it failed because of a firewall issue. Networks has it >>>>>>>>> opened >>>>>>>>> > now. I deleted ca.crt before trying again. There doesn't seem >>>>>>>>> to be >>>>>>>>> > a certificate in /etc/pki/nssdb for it. >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > [root@data2-uat ipa]# certutil -L -d /etc/pki/nssdb >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > Certificate Nickname >>>>>>>>> Trust >>>>>>>>> Attributes >>>>>>>>> > >>>>>>>>> > >>>>>>>>> SSL,S/MIME,JAR/XPI >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > [root@data2-uat ipa]# certutil -D -n 'IPA CA' -d /etc/pki/nssdb >>>>>>>>> > >>>>>>>>> > certutil: could not find certificate named "IPA CA": >>>>>>>>> > SEC_ERROR_BAD_DATABASE: security library: bad database. >>>>>>>>> > >>>>>>>>> > [root@data2-uat ipa]# ls >>>>>>>>> > >>>>>>>>> > [root@data2-uat ipa]# pwd >>>>>>>>> > >>>>>>>>> > /etc/ipa >>>>>>>>> > >>>>>>>>> > [root@data2-uat ipa]# ls -al >>>>>>>>> > >>>>>>>>> > total 16 >>>>>>>>> > >>>>>>>>> > drwxr-xr-x. 2 root root 4096 Dec 5 21:16 . >>>>>>>>> > >>>>>>>>> > drwxr-xr-x. 82 root root 12288 Dec 5 21:16 .. >>>>>>>>> > >>>>>>>>> > [root@data2-uat ipa]# >>>>>>>>> >>>>>>>>> So trying to install the client again fails or succeeds now? >>>>>>>>> >>>>>>>>> rob >>>>>>>>> >>>>>>>>> > >>>>>>>>> > On Fri, Dec 5, 2014 at 4:03 PM, Rob Crittenden >>>>>>>>> <rcrit...@redhat.com <mailto:rcrit...@redhat.com>> wrote: >>>>>>>>> >> Rob Crittenden wrote: >>>>>>>>> >>> Megan . wrote: >>>>>>>>> >>>> Good Day! >>>>>>>>> >>>> >>>>>>>>> >>>> I am getting an error when i register new clients. >>>>>>>>> >>>> >>>>>>>>> >>>> libcurl failed to execute the HTTP POST transaction. SSL >>>>>>>>> connect error >>>>>>>>> >>>> >>>>>>>>> >>>> I can't find anything useful not the internet about the >>>>>>>>> error. Can >>>>>>>>> >>>> someone help me troubleshoot? >>>>>>>>> >>>> >>>>>>>>> >>>> CentOS 6.6 x64 >>>>>>>>> >>>> ipa-client-3.0.0-42.el6.centos.x86_64 >>>>>>>>> >>>> ipa-server-3.0.0-42.el6.centos.x86_64 >>>>>>>>> >>>> curl-7.19.7-40.el6_6.1.x86_64 >>>>>>>>> >>> >>>>>>>>> >>> Do you have NSS_DEFAULT_DB_TYPE set to sql? I don't know that >>>>>>>>> we've done >>>>>>>>> >>> any testing on the client with this set. >>>>>>>>> >> >>>>>>>>> >> Never mind, that's not it. The problem is: >>>>>>>>> >> >>>>>>>>> >> * NSS error -8054 >>>>>>>>> >> >>>>>>>>> >> Which is SEC_ERROR_REUSED_ISSUER_AND_SERIAL >>>>>>>>> >> >>>>>>>>> >> So I'd do this: >>>>>>>>> >> >>>>>>>>> >> # rm /etc/ipa/ca.crt >>>>>>>>> >> >>>>>>>>> >> You may also want to ensure that the IPA CA certificate isn't >>>>>>>>> in >>>>>>>>> >> /etc/pki/nssdb: >>>>>>>>> >> >>>>>>>>> >> # certutil -L -d /etc/pki/nssdb >>>>>>>>> >> >>>>>>>>> >> And then perhaps >>>>>>>>> >> >>>>>>>>> >> # certutil -D -n 'IPA CA' -d /etc/pki/nssdb >>>>>>>>> >> >>>>>>>>> >> rob >>>>>>>>> >> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
