Sigbjorn Lie wrote:




On Fri, February 14, 2014 17:18, Rob Crittenden wrote:
Sigbjorn Lie wrote:




On Fri, February 14, 2014 15:29, Rob Crittenden wrote:

Sigbjorn Lie wrote:




It would seem like we're still encountering some issues. The date has now 
passed for when
the old certificate expired, and the "ipa" cli command no longer works. The 
webui is still
working just fine.

These are the errors I receive.



$ ipa user-find
ipa: ERROR: cert validation failed for 
"CN=serveripa03.example.com,O=EXAMPLE.COM"
((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not 
trusted by
the user.) ipa: ERROR: cert validation failed for 
"CN=serveripa01.example.com,O=EXAMPLE.COM"
  ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as 
not trusted by
the user.) ipa: ERROR: cert validation failed for 
"CN=serveripa02.example.com,O=EXAMPLE.COM"
  ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as 
not trusted by
the user.) ipa: ERROR: cannot connect to Gettext('any of the configured 
servers',
domain='ipa', localedir=None): https://serveripa03.example.com/ipa/xml,
https://serveripa01.example.com/ipa/xml,
https://serveripa02.example.com/ipa/xml



This seems more like a client-side issue. Can you confirm that
/etc/ipa/ca.crt is correct and that the NSS database in /etc/pki/nssdb
contains the CA?

certutil -L -d /etc/pki/nssdb -n 'IPA CA'



The CA seem to be available. I ran the command on ipa01. See below for the 
output.


The issue happens when I'm logged on to any of the ipa servers, and if I'm 
running the ipa
command from a remote machine.


]$ sudo certutil -L -d /etc/pki/nssdb -n 'IPA CA'
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Issuer: "CN=Certificate Authority,O=EXAMPLE.COM"
Validity:
Not Before: Thu Jan 19 19:44:21 2012
Not After : Sun Jan 19 19:44:21 2020
Subject: "CN=Certificate Authority,O=EXAMPLE.COM"
Subject Public Key Info:
Public Key Algorithm: PKCS #1 RSA Encryption
RSA Public Key:
Modulus:


Perhaps we can brute force things to see what is going on. We can pass
some extra options to the ipa tool to get ultra verbose output:

$ ipa -vv -e debug=True user-show admin


The thing to do is to check the server that it is communicating with and
check /var/log/httpd/errors to see if there is an equivalent error logged there.


I've sent you the full output in private.  Could this be the reason for why it 
fails?

ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False

         Name:     Certificate Key Usage
         Critical: True
         Usages:
             Digital Signature
             Non-Repudiation
             Key Encipherment
             Data Encipherment


No, that is normal for a server cert.

This pretty clearly looks like an SSL trust issue. Is this happening on every client machine you run the ipa tool or just one?

You might want to compare the cert in /etc/pki/nssdb with the one on the Apache server.

# certutil -L -d /etc/httpd/alias -n 'EXAMPLE.COM IPA CA'

# certutil -L -d /etc/pki/nssdb -n 'IPA CA'

The trust on each should be CT,C,C and can be checked with:

# certutil -L -d /etc/pki/nssdb

rob

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to