[Freeipa-users] ipa-replica-prepare error
Orion Poplawski
orion at cora.nwra.com
Wed Jul 8 17:31:27 UTC 2015
On 06/01/2015 08:54 AM, Rob Crittenden wrote:
> Orion Poplawski wrote:
>> On 05/28/2015 03:09 PM, Rob Crittenden wrote:
>>> Orion Poplawski wrote:
>>>> We did a CAless install:
>>>>
>>>> ipa-server-install -r NWRA.COM -n nwra.com -p `cat /etc/ldap.secret` -a `cat
>>>> /etc/ldap.secret` --root-ca-file=PositiveSSLCA2.crt
>>>> --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin=XXXX --http_pkcs12=nwra.com.p12
>>>> --http_pin=XXXX --idstart=8000
>>>>
>>>> But now when we try to setup a replica:
>>>>
>>>> # ipa-replica-prepare ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12
>>>> --dirsrv_pin=XXXX --http_pkcs12=nwra.com.p12 --http_pin=XXXX
>>>> Directory Manager (existing master) password:
>>>>
>>>> The full certificate chain is not present in nwra.com.p12
>>>>
>>>>
>>>> p12 file was created with:
>>>>
>>>> openssl pkcs12 -export -in /etc/pki/tls/certs/nwra.com.crt -inkey
>>>> /etc/pki/tls/private/nwra.com.key -certfile
>>>> /etc/pki/tls/certs/PositiveSSLCA2.crt -out nwra.com.p12
>>>>
>>>> ipa-server-4.1.0-18.sl7_1.3.x86_64
>>>>
>>>> Any thoughts?
>>>>
>>>
>>> At a glance your creation steps look ok. Strangely, the same code that loads
>>> the PKCS#12 files are used both in the server install and replica prepare, the
>>> only difference it seems is that with the server install we get a copy of the
>>> CA separately too.
>>>
>>> Can you provide the output of: pk12util -l nwra.com.p12
>>>
>>> Maybe we can work out what it thinks is missing.
>>>
>>> rob
>>
>> I think I need to redo our install with an updated (SHA-2?) certificate, but I
>> wouldn't think that would affect this issue either.
>
> I don't believe this is related to the signature.
>
> It looks like the right certs are there so I'm not sure what is going on. It
> may be that the built-ins aren't being found and this is needed because the
> AddTrust External Root isn't included, and it shouldn't need to be.
>
> What is really blowing my mind is the same function that loads the PKCS#12
> file is called both on install and replica prepare but only failing on the later.
>
> Maybe Honza has some ideas.
>
> rob
Okay, getting back to this. Looks like this behavior was introduced later. I
installed with an earlier version of IPA. Now trying to reproduce the install
with 4.1 I get the same error on ipa-server-install.
Looks like the new behavior came in:
commit 88083887c994ab505d6e07151e5dd26b56bb7732
Author: Jan Cholasta <jcholast at redhat.com>
Date: Wed Sep 24 16:41:47 2014 +0200
CA-less installer options usability fixes
The --*_pkcs12 options of ipa-server-install and ipa-replica-prepare have
been replaced by --*-cert-file options which accept multiple files.
ipa-server-certinstall now accepts multiple files as well. The files are
accepted in PEM and DER certificate, PKCS#7 certificate chain, PKCS#8 and
raw private key and PKCS#12 formats.
The --root-ca-file option of ipa-server-install has been replaced by
--ca-cert-file option which accepts multiple files. The files are
accepted in PEM and DER certificate and PKCS#7 certificate chain formats.
The --*_pin options of ipa-server-install and ipa-replica-prepare have been
renamed to --*-pin.
https://fedorahosted.org/freeipa/ticket/4489
Reviewed-By: Petr Viktorin <pviktori at redhat.com>
And is here (I added the root_logger.debug lines to figure out what is going on):
# Check we have the whole cert chain & the CA is in it
root_logger.debug('get_trust_chain for %s' % (key_nickname))
trust_chain = list(reversed(nssdb.get_trust_chain(key_nickname)))
root_logger.debug('trust_chain = %s' % (':'.join(trust_chain)))
ca_cert = None
for nickname in trust_chain[1:]:
cert = nssdb.get_cert(nickname)
if ca_cert is None:
ca_cert = cert
nss_cert = x509.load_certificate(cert, x509.DER)
subject = DN(str(nss_cert.subject))
issuer = DN(str(nss_cert.issuer))
root_logger.debug('nickname = %s, subject = %s, issuer = %s' %
(nickname, subject, issuer))
del nss_cert
if subject == issuer:
break
else:
raise ScriptError(
"The full certificate chain is not present in %s" %
(", ".join(cert_files)))
So the issue for us is as follows:
We are issued a wildcard cert for *.nwra.com from namecheap.com/COMODO SSL.
They issue us a cert and a certificate chain file that provides two certs to
chain back to:
CN=AddTrust External CA Root,OU=AddTrust External TTP Network,O=AddTrust AB,C=SE
This cert is in Firefox's certdb (and presumably other browsers) and so works.
FWIW - I don't seem to find this cert (or any AddTrust cert) in the openssl ca
certs in /etc/pki.
I'm not sure I follow the new logic. In the past with ldap SSL trusts in 389
we've always simply installed the cert that signed the DS cert as a trusted CA
cert (via /etc/openldap/{,ca}certs). I don't understand why we're now
insisting on having the issuer of the last cert in the DB.
But I am able to work with it by extracting the 'AddTrust External CA Root'
cert from firefox and then:
# openssl pkcs12 -export -in STAR_nwra_com.crt -inkey nwra.com.key -certfile
STAR_nwra_com.ca-bundle -out nwra.com.p12
(The ca-bundle is the one issued by namecheap with the two intermediate certs)
# ipa-server-install -r NWRA.COM -n nwra.com -p `cat /etc/ldap.secret` -a `cat
/etc/ldap.secret` --root-ca-file=AddTrustExternalCARoot
--dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin=XXXXXX --http_pkcs12=nwra.com.p12
--http_pin=XXXXXX --idstart=8000
But then when I go to make a replica:
# ipa-replica-prepare ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12
--dirsrv_pin=XXXXXX --http_pkcs12=nwra.com.p12 --http_pin=XXXXXX
Directory Manager (existing master) password:
(SEC_ERROR_LIBRARY_FAILURE) security library failure.
Which looks like others are experiencing (with not resolution that I could
see) https://www.redhat.com/archives/freeipa-users/2015-April/msg00514.html
Putting AddTrustExternalCARoot into nwra.com.p12 doesn't appear to help.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion at nwra.com
Boulder, CO 80301 http://www.nwra.com
More information about the Freeipa-users
mailing list