[Pki-users] Adding a signing certificate to an existing Dogtag instance

Thu Jun 13 00:52:04 UTC 2019

On Wed, Jun 12, 2019 at 10:45:52AM -0500, Allyson Bowles wrote:
> Hi Fraser,
> 
> Thanks so much for your response, this is really helpful. The primary
> reason I've been avoiding using the IPA CA as the renewing issuer for
> the EE certs is that I currently have the 'cacert' params for the
> utilities that use the certs pointed to the signing cert for
> "MyInternalCA". Assuming all of my servers are IPA enrolled, will using
> the IPA CA allow me to get rid of this parameter completely?
> 
> All my research to date on how an individual server's cert trust store works
> has been flawed at best and flat out incorrect at worst - I have found
> that update-ca-trust enable / add cert to
> /etc/pki/ca-trust/source/anchors / update-ca-trust extract does not seem
> to be applied to everything on the system. This is to say that I still
> have to specify a 'cacert' parameter for anything that uses my internal
> CA, or the EE cert is not trusted. Can I expect this to be the case with
> the IPA trust store? Any documentation you can point me to on this topic
> would be much appreciated.
> 

The IPA trust store just installs the trusted certs, as recorded in
the LDAP database, into the system trust stores under
/etc/pki/ca-trust/.

Most programs on the system should use the system trust by default,
but some programs do not, especially when it comes to validing TLS
client (not server) certificates.  I do not know the behaviour of
the utilities you use but it seems they fall into this category.
In which case you are left to manually specify the CA(s) to trust.
Or perhaps there's a way to configure / alter the utilities to use
system trust.

There is another way: cross-sign MyInternalCA with the IPA CA, and
update the programs that present certificates signed by MyInternalCA
to present the IPA-signed MyInteralCA certificate in the chain.
That should suffice to allow IPA-enrolled machines to trust those
certificates without changing anything about how those EE certs are
issued or renewed.

Cheers,
Fraser

> Thank you,
> Allyson
> 
> On  12 Jun 15:37, Fraser Tweedale wrote:
> > Hi Allyson,
> >
> > pkispawn is not the right approach.  You can't "add" a signing
> > certificate to an existing IPA / Dogtag deployment in that way.
> >
> > You could create Certmonger tracking requests for the end-entity
> > certs, configuring them to use the IPA CA when renewal is needed.
> > It is fine for a end-entity certificate to be renewed with a
> > different issuer.  As a transitional measure the current issuer
> > certificate can be added to the IPA trust store so that IPA-enrolled
> > machines will trust it.
> >
> > If you wish to continue issing those EE certs with a dedicated
> > sub-CA, create one with the 'ipa ca-add' command and use the
> > Certmonger `--issuer' option to refer to it.
> >
> > Cheers,
> > Fraser
> >
> > On Tue, Jun 11, 2019 at 02:53:57PM -0500, Allyson Bowles wrote:
> > > Hey folks,
> > >
> > > Awhile back, I set up an internal CA signing certificate for the purpose
> > > of issuing certificates used for RabbitMQ connections, Sensu, Consul,
> > > etc. I would now like to add that signing certificate to my existing
> > > Dogtag instance (created as part of an IPA server installation), so that
> > > I can configure clients to automatically renew these certificates using
> > > Certmonger. This signing certificate would not be used for anything IPA
> > > related, only the abovementioned third-party utilities requiring an
> > > internally trusted SSL certificate for authentication.
> > >
> > > I have managed to perform the pkispawn step using a PKCS12 file
> > > containing the signing certificate and key as well as a pkispawn config
> > > file that looks something like this:
> > >
> > > ####
> > > [DEFAULT]
> > > pki_instance_name=pki-tomcat
> > > pki_admin_password=secret
> > > pki_client_pkcs12_password=secret
> > > pki_ds_password=secret
> > > pki_ds_ldap_port=389
> > > pki_existing=True
> > >
> > > [CA]
> > > pki_ca_signing_nickname=MyInternalCA
> > > pki_ca_signing_csr_path=req/ca.csr
> > > pki_pkcs12_path=ca.p12
> > > pki_pkcs12_password=secret
> > > pki_serial_number_range_start=90
> > > pki_request_number_range_start=90
> > > pki_master_crl_enable=False
> > > pki_external_step_one=False
> > > pki_external_step_two=True
> > > ###
> > >
> > > The output I get is as follows:
> > >
> > > ```
> > > # pkispawn -s CA -f pkispawn.cfg
> > > Log file: /var/log/pki/pki-ca-spawn.20190611180347.log
> > > Loading deployment configuration from pkispawn.cfg.
> > > Installing CA into /var/lib/pki/pki-tomcat.
> > > ---------------
> > > Import complete
> > > ---------------
> > >
> > > Installation failed:
> > > com.netscape.certsrv.base.BadRequestException: System is already
> > > configured
> > >
> > > Please check the CA logs in /var/log/pki/pki-tomcat/ca.
> > > ```
> > >
> > > The pki-ca-spawn logfile doesn't contain anything interesting, and
> > > neither could I find anything terribly noteworthy in either
> > > /var/log/pki/pki-tomcat/ca/{debug,system}.
> > >
> > > The certificate and key do show up in certutil -L and -K, so my plan was
> > > to try carrying on with getting a client to use Certmonger to renew its
> > > certificate against this signing certificate. To do /that/, it looks
> > > like I need to create or modify an existing CA profile per
> > > https://www.dogtagpki.org/wiki/PKI_CA_Profile_CLI. However, this doc
> > > expects the operator to have a user certificate with the nickname
> > > 'caadmin' and a password. I don't seem to have a certificate with that
> > > nickname and I'm not sure which certificate to look for. Further
> > > documentation
> > > https://www.dogtagpki.org/wiki/CA_Admin_Setup#Retrieving_CA_Admin_Certificate
> > > suggests that I could create a new CA admin user...but this requires
> > > having access to the existing one.
> > >
> > > Which brings us to my actual questions.
> > >
> > > 1) Am I trying to do a reasonable thing by importing an existing signing
> > > certificate into an existing Dogtag instance? If not, what's a better
> > > way to achieve the ability to autorenew client certificates?
> > >
> > > 2) How can I either reset the existing CA admin credentials (given that
> > > I have system root) or force creation of a new user without nuking my
> > > current instance? Ideas about where I could look for the existing CA
> > > admin credentials would work as well but I understand this is highly
> > > dependent on how the system was set up initially.
> > >
> > > 3) Is there something else I should be doing, after the pkispawn partial
> > > failure, to troubleshoot? I figured attempting to carry on with an
> > > autorenew might at least get me more information about what's happening,
> > > but I'm very open to other approaches as well.
> > >
> > > Thank you for your time,
> > > Ally
> > >
> > > --
> > > Allyson Bowles | Senior Site Reliability Engineer
> > > e: abowles at hireology.com | 7C2D 671B 08A2 0D8A AD52  540E 1FB2 B534 ECD5 4608
> > > http://www.hireology.com
> >
> >
> >
> > > _______________________________________________
> > > Pki-users mailing list
> > > Pki-users at redhat.com
> > > https://www.redhat.com/mailman/listinfo/pki-users
> >
> 
> --
> Allyson Bowles | Senior Site Reliability Engineer
> e: abowles at hireology.com | 7C2D 671B 08A2 0D8A AD52  540E 1FB2 B534 ECD5 4608
> http://www.hireology.com