[Freeipa-devel] [PATCHES] 295-299 Allow changing chaining of the IPA CA certificate

[Jan Cholasta]

On 28.6.2014 00:19, Rob Crittenden wrote:
>
> I'm going to consolidate all reviews for 241 - 303 here. I'm not doing
> this in any particular order.

OK, I will send further patches only in this thread.

>
> --------
>
> Missing man page for ipa-certupdate

I did not want to delay the patch, so I have sent it without man page. 
Will fix.

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

Right. Fixed.

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

The problem is not in the missing external CA cert (the CA always worked 
fine without it for me, so I never bothered adding it). The problem is 
that Dogtag can't connect to DS, because it does not like its server 
certificate. Which is weird, because when I try doing the same using 
ldapsearch everything seems to work fine:

     # LDAPTLS_CACERTDIR=/etc/pki/pki-tomcat/alias 
LDAPTLS_CERT='subsystemCert cert-pki-ca' ldapsearch -H ldaps://$HOSTNAME 
-Y EXTERNAL -b o=ipaca -s base
     Please enter pin, password, or pass phrase for security token 
'ldap(0)':
     SASL/EXTERNAL authentication started
     SASL username: cn=CA Subsystem,o=EXAMPLE.COM
     SASL SSF: 0
     # extended LDIF
     #
     # LDAPv3
     # base <o=ipaca> with scope baseObject
     # filter: (objectclass=*)
     # requesting: ALL
     #

     # ipaca
     dn: o=ipaca
     objectClass: top
     objectClass: organization
     o: ipaca

     # search result
     search: 3
     result: 0 Success

     # numResponses: 2
     # numEntries: 1

Adding the old CA cert back to /etc/pki/pki-tomcat/alias does not fix 
this, although the error is different (ipa cert-show fails with internal 
error caused by "XMLSyntaxError: None", pki cert-find fails with 
"PKIException: Error searching certs in CertService.searchCerts!"). 
Adding the external CA cert does not fix this either.

I'm pretty sure chaining change from self-signed to signed by external 
CA worked for me the last time I have tested it, but it has been some 
time. Maybe something changed in Dogtag? I don't know. Any ideas?

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

Good.

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

OK, thanks.

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

I doubt this ever worked, as there can be only one certificate in 
cn=CAcert. Can't do much about this, unless you want to fix it in RHEL 5.

>
> Similarly /etc/ipa/ca.crt on the master contains only the IPA CA while
> /usr/share/ipa/html/ca.crt contains the full chain.

Right, will fix.

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

That's expected, it also uses cn=CAcert. Any idea why it works on RHEL 6 
but not on RHEL 5?

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

There are conflicting certificates with the same nickname in the PKCS#12 
file and the certificate store, which causes the error. Will fix.

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

Right, fixed.

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

Yes, I can add the out-of-band trust policy as well as nicknames to the 
certificates this way. Also, it is easier to manage one file rather than 
a bunch of them.

>
> Patch 294
>
> I think the git commit should include the bit about using the CA file
> from the replica config as well.

OK.

>
> Patch 303.
>
> Is the context as cli_installer a cut-n-paste or a conscious choice?

It is indeed copy-paste. Is it wrong?

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

This is all handled by admintool, including an option for verbose output 
(-v).

>
> In update_client() should it be paranoid enough to have a try/except
> around the reads and writes?

Sure, why not.

>
> 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 agree: <https://fedorahosted.org/freeipa/ticket/4416>.

>
> I still need to do more chain-updating and upgrade testing.
>
> rob
>
>

On 30.6.2014 19:36, Rob Crittenden wrote:
> A few more things after more testing.
>
> If one renews an externally-issued CA then you can end up with multiple
> certs for the IPA CA in /etc/pki/nssdb (for each issued cert). These do
> not seem to be cleaned up on uninstall.

Right, you need to call "certutil -D" multiple times if there are 
multiple certs with the same nick. Fixed.

>
> On upgrade from 3.3.5 seeing:
> Unexpected error - see /var/log/ipaupgrade.log for details:
> InvalidSyntax: object class ipaCertificate: Unknown required attribute
> type "ipaPublicKey": Invalid syntax.
>
> /var/log/ipaupgrade ends with:
>
> 2014-06-30T15:03:11Z DEBUG wait_for_open_ports: localhost [389] timeout 300
> 2014-06-30T15:08:12Z DEBUG   File
> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py",
> line 640, in run_script
>      return_value = main_function()
>
>    File "/usr/sbin/ipa-upgradeconfig", line 1171, in main
>      ds.start(ds_serverid)
>
>    File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> line 297, in start
>      self.service.start(instance_name, capture_output=capture_output,
> wait=wait)
>
>    File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py",
> line 262, in start
>      self.wait_for_open_ports(self.service_instance(instance_name))
>
>    File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py",
> line 228, in wait_for_open_ports
>      self.api.env.startup_timeout)
>
>    File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line
> 1153, in wait_for_open_ports
>      raise socket.timeout()
>
> 2014-06-30T15:08:12Z DEBUG The ipa-upgradeconfig command failed,
> exception: timeout:
>
> Turns out it blew up so badly that it didn't restore dse.ldif when the
> upgrade finished, something I thought was impossible. This is a pretty
> serious problem in itself (and likely unrelated to these patches).

This might be related to the fact that I accidentally left an unresolved 
merge conflict in 60basev3.ldif. Fixed.

>
> rob
>


-- 
Jan Cholasta