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 <jchol...@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 <pvikt...@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                       or...@nwra.com
Boulder, CO 80301                   http://www.nwra.com

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