[Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate
Rob Crittenden
rcritten at redhat.com
Fri Jun 27 22:19:25 UTC 2014
Jan Cholasta wrote:
> On 26.6.2014 20:05, Rob Crittenden wrote:
>> Jan Cholasta wrote:
>>> On 16.6.2014 15:35, Jan Cholasta wrote:
>>>> Hi,
>>>>
>>>> the attached patches implement
>>>> <https://fedorahosted.org/freeipa/ticket/3737>.
>>>>
>>>> My patches 241-253 and 262-294 are required for this
>>>> (<http://www.redhat.com/archives/freeipa-devel/2014-June/msg00276.html>,
>>>>
>>>> <http://www.redhat.com/archives/freeipa-devel/2014-June/msg00307.html>).
>>>>
>>>>
>>>> The installation/testing guidelines from
>>>> <http://www.redhat.com/archives/freeipa-devel/2014-March/msg00385.html>
>>>> apply here as well.
>>>>
>>>> Honza
>>>
>>> Rebased on top of current master.
>>
>> 295 ACK
>>
>> 296, 297 & 299
>>
>> TBD, need to test but no problems seen so far.
>>
>> 298
>>
>> The man page, if not usage, should include what the valid trust flags
>> are or point to NSS documentation.
>
> OK.
>
>>
>> rob
>>
>
> Updated rebased patches attached. Also attaching all the required patches.
>
I'm going to consolidate all reviews for 241 - 303 here. I'm not doing
this in any particular order.
--------
Missing man page for ipa-certupdate
--------
Not a very nice error from ipa-cacert-manage install when loading a bad
cert:
# ipa-cacert-manage install /etc/group
Installing CA certificate, please wait
(SEC_ERROR_INVALID_ARGS) security library: invalid arguments.
The ipa-cacert-manage makes no mention of changing the cert chaining. It
just adds the options, not what they do. Here is what happened when I
tried it:
# ipa-cacert-manage renew --external-ca
Exporting CA certificate signing request, please wait
The next step is to get /var/lib/ipa/ca.csr signed by your CA and re-run
ipa-cacert-manage as:
ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate
--external-ca-file=/path/to/external_ca_certificate
The ipa-cacert-manage command was successful
[ go off and sign it ]
# ipa-cacert-manage renew --external-cert-file=/home/rcrit/ca_db/ipa.crt
--external-ca-file=/home/rcrit/ca_db/ca.crt
Importing the renewed CA certificate, please wait
Resubmitting certmonger request '20140627134654' timed out, please check
the request manually
The request was actually in MONITORING, so ok.
But the CA is now not working
# ipa cert-request --principal test/`hostname` csr
ipa: ERROR: Certificate operation cannot be completed: Unable to
communicate with CMS (Internal Server Error)
# ipa cert-show 1
ipa: ERROR: Certificate operation cannot be completed: Unable to
communicate with CMS (Internal Server Error)
The CA database doesn't have my external CA
# certutil -Ld /etc/pki/pki-tomcat/alias/
Certificate Nickname Trust
Attributes
SSL,S/MIME,JAR/XPI
Server-Cert cert-pki-ca u,u,u
auditSigningCert cert-pki-ca u,u,Pu
caSigningCert cert-pki-ca CTu,Cu,Cu
ocspSigningCert cert-pki-ca u,u,u
subsystemCert cert-pki-ca u,u,u
Not sure if this is related:
# pki cert-find
PKIException: Internal Server Error
--------
Note that I tried again with a fresh external install, this time without
the --external-ca flag and it basically went through the same steps but
this time it was successful.
--------
I did a re-install and tried a renewal (with just ipa-server-install). I
moved time forward and saw this:
Request ID '20140627150913':
status: MONITORING
ca-error: Server at
"https://sif.greyoak.com:8443/ca/agent/ca/profileProcess" replied: 1:
Invalid Credential.
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS Certificate DB',pin='323234924210'
certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=GREYOAK.COM
subject: CN=CA Audit,O=GREYOAK.COM
expires: 2016-06-16 15:08:34 UTC
key usage: digitalSignature,nonRepudiation
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
"auditSigningCert cert-pki-ca"
track: yes
auto-renew: yes
How it is monitoring with a ca-error I don't know.
I forced a resubmit and it renewed ok. Chances are certmonger would have
taken care of this automatically.
I leaped forward 2 more times and had to restart certmonger a few times
to kick things but again, it did eventually renew as expected.
So that looks ok and covers much of the first patch set.
---------------
ipa-client-install still fails for me in RHEL-5 with an external CA:
2014-06-27 14:04:31,202 DEBUG trying to retrieve CA cert via LDAP from
ldap://sif.greyoak.com
2014-06-27 14:04:32,312 INFO Successfully retrieved CA cert
Subject: /O=GREYOAK.COM/CN=Certificate Authority
Issuer: /CN=External Authority
2014-06-27 14:04:32,467 DEBUG args=/usr/sbin/ipa-join -s sif.greyoak.com
-b dc=greyoak,dc=com
2014-06-27 14:04:32,467 DEBUG stdout=
2014-06-27 14:04:32,467 DEBUG stderr=libcurl failed to execute the HTTP
POST transaction. SSL certificate problem, verify that the CA cert is
OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
verify failed
This is the query that is being done:
[27/Jun/2014:14:04:31 -0400] conn=18 op=3 SRCH
base="CN=CAcert,CN=ipa,CN=etc,dc=greyoak,dc=com" scope=0
filter="(objectClass=pkiCA)" attrs="cacertificate;binary"
It returns a single object, the dogtag-issued CA certificate, not the
entire chain, hence the failure.
Similarly /etc/ipa/ca.crt on the master contains only the IPA CA while
/usr/share/ipa/html/ca.crt contains the full chain.
This works:
# wget -O /tmp/ca.crt http://sif.greyoak.com/ipa/config/ca.crt
# ipa-client-install --server=sif.greyoak.com --domain=greyoak.com -p
admin -w password -U --ca-cert-file=/tmp/ca.crt
--------
Enrollment on RHEL-6 also puts a single CA in /etc/ipa/ca.crt but
enrollment succeeds.
Enrollment on F-20 puts all certs into /etc/ipa/ca.crt. My last test was
re-freshing the CA cert from an external and I confirmed that both the
IPA CA certs are in /etc/ipa/ca.crt and in LDAP.
--------
Ok, so I took my working, renewed Externally-issued CA install and
generated a PKCS#12 for another host. Using that I did a CA-less install.
I tried ipa-ca-install on that and it failed. The log is attached,
though it shouldn't be called ipareplica-ca-install.log in this case.
--------
Installing a replica and adding a CA to it using ipa-replica-ca-install
worked fine.
--------
I renewed the CA once again using ipa-cacert-manage then used
ipa-certupdate to apply the result successfully on the replica except
for the CA itself. It is still has the serial number it was installed
with and not the updated value in caSigningCert cert-pki-ca.
--------
Patch 293
Just curious, but what is the advantage of writing out the certificates
in pk11-kit format when you can drop the cert(s) and call
update-ca-trust? Is it a control thing, particularly for the
trusted/untrusted?
Patch 294
I think the git commit should include the bit about using the CA file
from the replica config as well.
Patch 303.
Is the context as cli_installer a cut-n-paste or a conscious choice?
Should there be some logging in here? What happens if the kinit fails,
or something else goes bump? There is no debug/verbose output option to
see what is going on.
In update_client() should it be paranoid enough to have a try/except
around the reads and writes?
I'm assuming that the certutil call in update_db() is because the other
cert management we have is in ipaserver, right? Perhaps certs.py needs
to be moved to ipapython (and maybe renamed)? A patch for another day if
you agree and please file a ticket.
I still need to do more chain-updating and upgrade testing.
rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipareplica-ca-install.log
Type: text/x-log
Size: 104613 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140627/274cb7a2/attachment.bin>
More information about the Freeipa-devel
mailing list