For those of you that have been helping me...thank you!  For all those 
following along here is the status of my issues.

I ended up replacing the krbprincipal key and the user certificate in LDAP to 
match what is on the master and I am no longer getting the invalid credentials 
error!  So thanks for that!

Unfortunately, krb5kdc still will not start...

When trying to run:

ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-ITMODEV-GOV.socket -b 
"cn=ITMODEV.GOV,cn=kerberos,dc=itmodev,dc=gov" krbMKey=*

I get " ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) " 

So we did a strace on that to see if we could find anything and I found:

connect(3, {sa_family=AF_LOCAL, sun_path="/var/run/slapd-ITMODEV-GOV.socket"}, 
110) = -1 ECONNREFUSED (Connection refused)

So it looks like an issue with the listening socket.  Ran some more tests on 
the socket...

[root@comipa02 ~]# ls -lZ /var/run/slapd-ITMODEV-GOV.socket
srw-rw-rw-. root root system_u:object_r:dirsrv_var_run_t:s0 
/var/run/slapd-ITMODEV-GOV.socket

So the socket exists but " lsof -U -a -udirsrv" gives me no return...nothing.

Anybody know what I need to do to fix the socket?





-----Original Message-----
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Rob Crittenden
Sent: Thursday, November 12, 2015 11:15 AM
To: James Masson <james.mas...@jmips.co.uk>; Martin Kosek <mko...@redhat.com>; 
freeipa-users@redhat.com; Jan Cholasta <jchol...@redhat.com>; David Kupka 
<dku...@redhat.com>; Endi Sukma Dewata <edew...@redhat.com>
Subject: Re: [Freeipa-users] IPA with external CA signed certs

James Masson wrote:
>
>
> On 12/11/15 15:21, Rob Crittenden wrote:
>> James Masson wrote:
>>>
>>>
>>> On 30/10/15 13:52, Rob Crittenden wrote:
>>>> James Masson wrote:
>>>>>
>>>>>
>>>>> On 26/10/15 16:11, Martin Kosek wrote:
>>>>>> On 10/26/2015 04:05 PM, James Masson wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 19/10/15 21:06, Rob Crittenden wrote:
>>>>>>>> James Masson wrote:
>>>>>>>>>
>>>>>>>>> Hi list,
>>>>>>>>>
>>>>>>>>> I successfully have IPA working with CA certs signed by an 
>>>>>>>>> upstream Dogtag.
>>>>>>>>>
>>>>>>>>> Now I'm trying to use a CA cert signed by a different type of 
>>>>>>>>> CA - Vault.
>>>>>>>>>
>>>>>>>>> Setup fails, using the same 2 step IPA setup process as used 
>>>>>>>>> with upstream Dogtag. I've also tried the external-ca-type option.
>>>>>>>>>
>>>>>>>>> Likely, IPA doesn't like the certificate - however, I can't 
>>>>>>>>> pinpoint why.
>>>>>>>>
>>>>>>>> I'm guessing you don't include the entire CA certchain of Vault.
>>>>>>>> Dogtag
>>>>>>>> is failing to startup because it can't verify its own cert chain:
>>>>>>>>
>>>>>>>> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1]
>>>>>>>> CAPresence:  CA is present
>>>>>>>> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1]
>>>>>>>> SystemCertsVerification: system certs verification failure
>>>>>>>> 0.localhost-startStop-1 - [15/Oct/2015:14:39:27 UTC] [20] [1]
>>>>>>>> SelfTestSubsystem: The CRITICAL self test plugin called 
>>>>>>>> selftests.container.instance.SystemCertsVerification running at 
>>>>>>>> startup FAILED!
>>>>>>>>
>>>>>>>> rob
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi Rob,
>>>>>>>
>>>>>>> Thanks for the reply.
>>>>>>>
>>>>>>> I do present the IPA installer with both the CA and the IPA cert 
>>>>>>> - the IPAs python-based install code is happy with the cert 
>>>>>>> chain, but the Java based dogtag code chokes on it.
>>>>>>>
>>>>>>> OpenSSL is happy with it too.
>>>>>>>
>>>>>>> #####
>>>>>>> [root@foo ~]# openssl verify ipa.crt
>>>>>>> ipa.crt: O = LOCAL, CN = Certificate Authority error 20 at 0 
>>>>>>> depth lookup:unable to get local issuer certificate
>>>>>>>
>>>>>>> [root@foo ~]# openssl verify -CAfile vaultca.crt ipa.crt
>>>>>>> ipa.crt: OK
>>>>>>> ###
>>>>>>>
>>>>>>> Any hints on how to reproduce this with more debug output? I'd 
>>>>>>> like to know exactly what Dogtag doesn't like about the 
>>>>>>> certificate.
>>>>>>>
>>>>>>> thanks
>>>>>>>
>>>>>>> James M
>>>>>>
>>>>>> Let me CC at least Jan Ch. and David, they may be able to help 
>>>>>> and should also make sure FreeIPA gets better in validating the 
>>>>>> certs, as appropriate.
>>>>>>
>>>>>
>>>>> Any thoughts guys?
>>>>
>>>> I cc'd one of the dogtag guys to see if he knows.
>>>>
>>>> You might also try using certutil to validate the certificates, it 
>>>> might give you some hints to what is going on.
>>>>
>>>> I'm assuming your certdb (it can vary by version) is in 
>>>> /var/lib/pki/pki-tomcat/alias
>>>>
>>>> certutil -L -d /var/lib/pki/pki-tomcat/alias will give you the list 
>>>> of certificates installed. You can verify each one to see what is 
>>>> going on.
>>>> The -u flag specfies usage. See the certutil man page for a full 
>>>> set of options.
>>>>
>>>> For example:
>>>>
>>>> # certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n 
>>>> 'auditSigningCert cert-pki-ca'
>>>> certutil: certificate is valid
>>>>
>>>> rob
>>>>
>>>
>>> Hi All,
>>>
>>> I've created a ticket to track this
>>>
>>> https://fedorahosted.org/pki/ticket/1697
>>>
>>> Rob - certutil output:
>>>
>>> Some certificates types seem not to be approved. Not sure if this is 
>>> a red herring.
>>>
>>> ##############
>>> [root@foo ~]# certutil -L -d /var/lib/pki/pki-tomcat/alias
>>>
>>> Certificate Nickname                                         Trust
>>> Attributes
>>>
>>> SSL,S/MIME,JAR/XPI
>>>
>>> caSigningCert cert-pki-ca                                    CTu,Cu,Cu
>>> root.com                                                     CT,c,
>>> ocspSigningCert cert-pki-ca                                  u,u,u
>>> subsystemCert cert-pki-ca                                    u,u,u
>>> Server-Cert cert-pki-ca                                      u,u,u
>>> auditSigningCert cert-pki-ca                                 u,u,Pu
>>> [root@foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n 
>>> 'caSigningCert cert-pki-ca'
>>> certutil: certificate is valid
>>> [root@foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n 
>>> 'root.com'
>>> certutil: certificate is invalid: Certificate type not approved for 
>>> application.
>>> [root@foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n 
>>> 'ocspSigningCert cert-pki-ca'
>>> certutil: certificate is invalid: Certificate type not approved for 
>>> application.
>>> [root@foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n 
>>> 'subsystemCert cert-pki-ca'
>>> certutil: certificate is valid
>>> [root@foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n 
>>> 'Server-Cert cert-pki-ca'
>>> certutil: certificate is invalid: Certificate type not approved for 
>>> application.
>>> [root@foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n 
>>> 'auditSigningCert cert-pki-ca'
>>> certutil: certificate is valid
>>> #############
>>
>> That's why I pointed you to the certutil man page to find out the 
>> differnet usages to test. The C usage is SSL client usage. Depending 
>> on the cert the usage may be different.
>>
>> rob
>
> Missed that. Here are those commands again with different certusage 
> checking
>
> In short, they're all superficially valid.
>
> ##########
> [root@foo ~]# certutil -V -u C -d /var/lib/pki/pki-tomcat/alias -n 
> 'caSigningCert cert-pki-ca'
> certutil: certificate is valid
>
> [root@foo ~]# certutil -V -u Y -d /var/lib/pki/pki-tomcat/alias -n 
> 'root.com'
> certutil: certificate is valid
>
>
> [root@foo ~]# certutil -V -u O -d /var/lib/pki/pki-tomcat/alias -n 
> 'ocspSigningCert cert-pki-ca'
> certutil: certificate is valid
>
> [root@foo ~]# certutil -V -u V -d /var/lib/pki/pki-tomcat/alias -n 
> 'subsystemCert cert-pki-ca'
> certutil: certificate is valid
>
> [root@foo ~]# certutil -V -u V -d /var/lib/pki/pki-tomcat/alias -n 
> 'Server-Cert cert-pki-ca'
> certutil: certificate is valid
>
> [root@foo ~]# certutil -V -u J -d /var/lib/pki/pki-tomcat/alias -n 
> 'auditSigningCert cert-pki-ca'
> certutil: certificate is valid
> ####
>
>
> However, the debug logs seem to indicate the 'caSigningCert cert-pki-ca'
> is the one it has problems with.
>
> ####
> [12/Nov/2015:12:41:35][localhost-startStop-1]: CertUtils:
> verifySystemCerts() cert tag=signing
> [12/Nov/2015:12:41:35][localhost-startStop-1]: CertUtils:
> verifySystemCertByTag(signing)
> [12/Nov/2015:12:41:35][localhost-startStop-1]: CertUtils:
> verifySystemCertByNickname(caSigningCert cert-pki-ca,SSLCA)
> [12/Nov/2015:12:41:35][localhost-startStop-1]: CertUtils:
> verifySystemCertByNickname(): calling isCertValid()
> [12/Nov/2015:12:41:35][localhost-startStop-1]: CertUtils:
> verifySystemCertByNickname() failed: caSigningCert cert-pki-ca
> [12/Nov/2015:12:41:35][localhost-startStop-1]: SignedAuditEventFactory:
> create()
> message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcom
> e=Failure][CertNickName=caSigningCert
> cert-pki-ca] CIMC certificate verification #########
>
> But further checking seems to indicate the cert passes the relevant 
> checks ( Y A L )
>
> ######
> [root@foo ~]# certutil -V -u Y -d /var/lib/pki/pki-tomcat/alias -n 
> 'caSigningCert cert-pki-ca'
> certutil: certificate is valid
> [root@foo ~]# certutil -V -u A -d /var/lib/pki/pki-tomcat/alias -n 
> 'caSigningCert cert-pki-ca'
> certutil: certificate is valid
> [root@foo ~]# certutil -V -u L -d /var/lib/pki/pki-tomcat/alias -n 
> 'caSigningCert cert-pki-ca'
> certutil: certificate is valid
> #####
>

Ok, yeah, we'll need to wait for the dogtag guys to chime in here or on the 
ticket. Note that validity also depends on valid to/from dates so you might 
check that too, but it's a stretch to suggest that's the problem.

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


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