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 On Tue, Dec 9, 2014 at 9:05 AM, Rob Crittenden <[email protected]> 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 <[email protected]> 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 . <[email protected]> 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 <[email protected]> >>>>> 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" <[email protected] >>>>>>> <mailto:[email protected]>> 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 >>>>>>> <[email protected] <mailto:[email protected]>> 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
