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 <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

Reply via email to