[Freeipa-users] can't register new clients
Megan .
nagemnna at gmail.com
Tue Dec 9 14:57:15 UTC 2014
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 <rcritten at 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 at dir1 ipa]# openssl verify -verbose -CAFile ca.crt
>> .
>> .
>> Authority Information Access:
>> OCSP - URI:http://dir1.example.com:80/ca/ocsp
>> .
>>
>>
>>
>> [root at 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 at 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 at data2-uat ipa]# cd /tmp
>> [root at 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 <mkosek at 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 . <nagemnna at gmail.com> wrote:
>>>>> It failed again.
>>>>>
>>>>>
>>>>> [root at cache2-uat ~]# certutil -L -d sql:/etc/pki/nssdb
>>>>>
>>>>> Certificate Nickname Trust Attributes
>>>>> SSL,S/MIME,JAR/XPI
>>>>> [root at 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 <rcritten at 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" <rcritten at redhat.com
>>>>>>> <mailto:rcritten at 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 at data2-uat ipa]# certutil -L -d /etc/pki/nssdb
>>>>>>> >
>>>>>>> >
>>>>>>> > Certificate Nickname Trust
>>>>>>> Attributes
>>>>>>> >
>>>>>>> >
>>>>>>> SSL,S/MIME,JAR/XPI
>>>>>>> >
>>>>>>> >
>>>>>>> > [root at 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 at data2-uat ipa]# ls
>>>>>>> >
>>>>>>> > [root at data2-uat ipa]# pwd
>>>>>>> >
>>>>>>> > /etc/ipa
>>>>>>> >
>>>>>>> > [root at 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 at 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
>>>>>>> <rcritten at redhat.com <mailto:rcritten at 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
>>>>>>> >>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>
More information about the Freeipa-users
mailing list