#1316 Allow adding SAN to server cert during the install process
Closed: Fixed None Opened 9 years ago by dminnich.

We are trying to set subjectaltnames on CA's, OCSPs and possibly KRAs
server certs since we will be having masters and clones and a
loadbalancer VIP that points at the pools. It looks like when
you spin up a clone CA or a OCSP using pkispawn the single upstream CA generates a
server certificate for your component using the
normal profiles/ca/caInternalAuthServerCert profile.

This creates a problem for us because now we either have to give the caInternalAuthServerCert all the SANs we want for all of our components ahead of time-- meaning kra01.example.com would answer for ca02.example.com which is dirty but works with configuration managment systems like puppet templates. OR we hand edit the profile before each component install so that the new component will only get the SANs it needs. This is doable and is dogtag working as designed, it just creates more manual steps during environment buildouts since config management templates or similar couldn't do what we need them to do.

Is there a way to have multiple caInternalAuthServerCert profiles that
the CA or pkispawn knows how to use differently?


So, you wish to have one server cert profile per subsystem (CA, kra, ocsp), or do you mean per host? Please clarify.
Yes, it is currently hardcoded to caInternalAuthServerCert.

We have multiple CA and OCSP subsystem tiers

int-ca01 and int-ca02 need SAN set A
op-ca01 and op-ca02 need SAN set B
int-ocsp01 and int-ocsp02 need SAN set C
op-ocap01 and op-ocsp02 need SAN set D
kra01 and kra02 need SAN set E

so per-host will likely be needed. The ability to choose what profile the upstream CA uses by passing a pkisapwn option on the downstream component would be cool if possible.

Would it help if you could just create separate profiles and point CS.cfg to the appropriate one before each run of pkispawn?

From looking at the code, it appears it works like the following:

  • if it's a CA clone, the sslserver cert is hard-coded to use caInternalAuthServerCert (ConfigurationUtils.java). To make the profile configurable, we could change it to use preop_cert_sslserver_profile...However, since this is one case, you could try updating the caInternalAuthServerCert directly.
  • for the rest of the cases, I think it otherwise uses the preop.cert.sslserver.profile setting, which is set to
    serverCert.profile on ca (see /usr/share/pki/ca/conf/CS.cfg)
    caInternalAuthServerCert on kra (see /usr/share/pki/kra/conf/CS.cfg)
    caInternalAuthServerCert on ocsp (see /usr/share/pki/ocsp/conf/CS.cfg)

So for these you could modify (make a copy before you do that) the CS.cfg source to point to your own profiles before running pkispawn.

If the above works for you, then no code changes will be required.

==
another way (requiring more work) would be to use the SubjectAltNameExtInput, which takes subjAltExtPattern's from the caller
so for example, if you set profile to contain the following:
policyset.serverCertSet.9.constraint.class_id=noConstraintImpl
policyset.serverCertSet.9.constraint.name=No Constraint
policyset.serverCertSet.9.default.class_id=subjectAltNameExtDefaultImpl
policyset.serverCertSet.9.default.name=Subject Alternative Name Extension Default
policyset.serverCertSet.9.default.params.subjAltExtGNEnable_0=true
policyset.serverCertSet.9.default.params.subjAltExtPattern_0=$request.req_san_pattern_0$
policyset.serverCertSet.9.default.params.subjAltExtType_0=DNSName
policyset.serverCertSet.9.default.params.subjAltExtGNEnable_1=true
policyset.serverCertSet.9.default.params.subjAltExtPattern_1=$request.req_san_pattern_1$
policyset.serverCertSet.9.default.params.subjAltExtType_1=DNSName
policyset.serverCertSet.9.default.params.subjAltExtGNEnable_2=true
policyset.serverCertSet.9.default.params.subjAltExtPattern_2=$request.req_san_pattern_2$
policyset.serverCertSet.9.default.params.subjAltExtType_2=DNSName
policyset.serverCertSet.9.default.params.subjAltNameExtCritical=false
policyset.serverCertSet.9.default.params.subjAltNameNumGNs=3

You can call by adding something like "&request.req_san_pattern_0=ca02.example.com" etc. in the calling url. However, although I checked in SubjectAltNameExtInput over from 8.1 to upstream, I was told that the installation wizard part of it (the calling part) wasn't.

Thanks for your input cfu.

The first option isn't easily doable for us. The problem we are facing is when using puppet as an environment build out tool, it will lay down a file and template it to look a specific way and ensure it looks that way forever. We are currently setting policyset.serverCertSet.9.default.params.subjAltExtPattern_0 and similar in that fashion. The issue is we can't make it do "use subjAltExtPattern_0=X for the next 2 hours, then use subjAltExtPattern_0=Y for the following 2 hours, and subjAltExtPattern_0=Z after that forever". All we can do is "make it look like this forever". The same thing applies to the proposed CS.cfg changes, except actually a bit worse. Since CS.cfg stores raw and changing data that the application uses (cert serial number ranges for example) in addition to static configuration, we also can't use the standard template features of puppet to alter that file. I'd love to see that change as well (store shared data in LDAP?), but thats a much bigger and I image nightmarish feature request.

Do I understand that the 2nd option won't work in 9/10 as all the pieces aren't implemented in the new code?

Let me know your thoughts. Once again, the software is working great and as designed, its just not quite as sysadmin friendly as we'd like it to be.

Currently, the SubjectAltNameExtInput enrollment feature is actually being exercised by the TPS subsystem. TPS provides an option that allows one to specify the SAN it wishes to have and send the enrollment request to profileSubmitSSLClient servlet which in turns processes it through the caTokenUserDelegateAuthKeyEnrollment.cfg enrollment profile that has the desired generic SAN patterns specified as following:
policyset.set1.p6.default.class_id=subjectAltNameExtDefaultImpl
policyset.set1.p6.default.name=Subject Alternative Name Extension Default
policyset.set1.p6.default.params.subjAltExtGNEnable_0=true
policyset.set1.p6.default.params.subjAltExtGNEnable_1=false
policyset.set1.p6.default.params.subjAltExtGNEnable_2=false
policyset.set1.p6.default.params.subjAltExtGNEnable_3=false
policyset.set1.p6.default.params.subjAltExtGNEnable_4=false
policyset.set1.p6.default.params.subjAltExtPattern_0=(UTF8String)1.3.6.1.4.1.311.20.2.3,$request.req_san_pattern_0$
policyset.set1.p6.default.params.subjAltExtPattern_1=
policyset.set1.p6.default.params.subjAltExtPattern_2=
policyset.set1.p6.default.params.subjAltExtPattern_3=
policyset.set1.p6.default.params.subjAltExtPattern_4=
policyset.set1.p6.default.params.subjAltExtType_0=OtherName
policyset.set1.p6.default.params.subjAltExtType_1=OtherName
policyset.set1.p6.default.params.subjAltExtType_2=OtherName
policyset.set1.p6.default.params.subjAltExtType_3=RFC822Name
policyset.set1.p6.default.params.subjAltExtType_4=RFC822Name
policyset.set1.p6.default.params.subjAltNameExtCritical=false
policyset.set1.p6.default.params.subjAltNameNumGNs=1

For example, when TPS sends a request like this:
xml=true&tokencuid=A0%01%92%03%04%05%01%80%04%C0%&screenname=cfu&publickey=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDnU5wp3P79mQttS9z1azPt4rgY%0D%0AufzVyey2O6AiiKgOqSK8jKsJ5Pk69qYVAw%2BU1l8o59MYWkR0Hqt13dGls%2F%2BXoZlB%0D%0Ay6G3tIs8kfO1lNBoBQD9c4Ir9CSzCSJdK1WqBGE%2BY97kmX%2BTghKxvafopuxQwnsX%0D%0AyHNkjHXE2XE4jsJ89QIDAQAB%0D%0A&profileId=caTokenUserDelegateAuthKeyEnrollment&subject=cn%3DChristina.fu.123456789%2Ce%3Dcfu%40redhat.com%2Co%3DTMS+Org&req_san_pattern_0=999999999.BB%40EXAMPLE.com

It receives a cert containing the following SAN from CA:
Identifier: Subject Alternative Name - 2.5.29.17
Critical: no
Value:
OtherName: (UTF8String)1.3.6.1.4.1.311.20.2.3,999999999.BB@EXAMPLE.com

What you need (but is currently missing), is the part in the installation code that would allow you to do what TPS does: taking from config and composing the SAN to be sent along with your enrollment request to achieve the wanted SAN in certs.

That part of the installation code WAS actually once in one certain branch of rhcs8.1. However, certain installation code has been changed between 8.1 and Dogtag, so it's not directly portable, but it's not all that impossible.

Let me know if the below is acceptable. I know you still have to change CS.cfg , but you only need to change the profile once.

I did a port of the 8.1 (obsolete errata) installation code. The way it was designed is to allow one to change the CS.cfg in /usr/share/pki/ca/conf
e.g. add the following in that CS.cfg:
service.injectSAN=true
preop.cert.sslserver.san=host1a,host1b

and then modify /usr/share/pki/ca/conf/serverCert.profile to have san patterns
(I have sample in the package, you just need to copy it over and turn it on):
e.g.
8.default.class=com.netscape.cms.profile.def.SubjectAltNameExtDefault
8.default.name=Subject Alternative Name Extension Default
8.default.params.subjAltExtGNEnable_0=true
8.default.params.subjAltExtPattern_0=$request.req_san_pattern_0$
8.default.params.subjAltExtType_0=DNSName
8.default.params.subjAltExtGNEnable_1=true
8.default.params.subjAltExtPattern_1=$request.req_san_pattern_1$
8.default.params.subjAltExtType_1=DNSName
8.default.params.subjAltExtGNEnable_2=false
8.default.params.subjAltExtPattern_2=$request.req_san_pattern_2$
8.default.params.subjAltExtType_2=DNSName
8.default.params.subjAltExtGNEnable_3=false
8.default.params.subjAltExtPattern_3=$request.req_san_pattern_3$
8.default.params.subjAltExtType_3=DNSName
8.default.params.subjAltExtType_4=OtherName
8.default.params.subjAltExtSource_4=UUID4
8.default.params.subjAltExtPattern_4=(IA5String)1.2.3.4,$server.source$
8.default.params.subjAltExtGNEnable_4=false
8.default.params.subjAltExtType_5=DNSName
8.default.params.subjAltExtPattern_5=myhost.example.com
8.default.params.subjAltExtGNEnable_5=false
8.default.params.subjAltNameExtCritical=false
8.default.params.subjAltNameNumGNs=2

for non-ca's, do similar changes in /usr/share/pki/ca/profiles/ca/caInternalAuthServerCert.cfg

The installed CA's ssl server cert will then bear (per example above):
Identifier: Subject Alternative Name - 2.5.29.17
Critical: no
Value:
DNSName: host1a
DNSName: host1b

Christina:
Thanks for looking into this some more.

Is the suggestion to change preop.cert.sslserver.san=host1a,host1b or similar in CS.cfg between every component install since caInternalAuthServerCert.cfg is signing clone CAs, and master and clone KRAs and OCSPs?

If so, that may be somewhat easier than changing the /usr/share/pki/ca/profiles/ca/caInternalAuthServerCert.cfg file before each component install and not adding any injectSAN stuff to the CS.cfg, but not by much and unfortunately it doesn't ultimately solve our problem.

Just what I thought... what I gave you was the once-upon-a-time design.

ok, so in other words, you prefer

  • making only a one time change to the basic config and profiles (they will be your "templates")
  • making changes to pkispawn config file for every instance creation

I can pass a SAN specific host name(s) from pkispawn config to achieve that. You just need to make sure you set the san hostname correctly, e.g.
pki_server_cert_san_hostnames=host1a,host1b

The limitation is that in order for the profiles to be static, the # of sans need to be the same across all instances. Also, this only applies to ssl server certs.

Will that do?

Yes. Setting something like the following in caInternalAuthServerCert.cfg

8.default.name=Subject Alternative Name Extension Default 8.default.params.subjAltExtGNEnable_0=true 8.default.params.subjAltExtPattern_0=$request.req_san_pattern_0$ 8.default.params.subjAltExtType_0=DNSName
8.default.params.subjAltExtGNEnable_2=true
8.default.params.subjAltExtPattern_2=$request.req_san_pattern_2$ 8.default.params.subjAltExtType_2=DNSName
8.default.params.subjAltNameExtCritical=false
8.default.params.subjAltNameNumGNs=2

then passing in those SANs from pkispawn installs using the same number and only for ssl server certs would meet our needs.

pushed to master:
commit e2683d6a8f6211ac58a5674aaa626814f26ebbf2

Ticket 1316 Allow adding SAN to server cert during the install process
Usage:
- under /usr/share/pki/ca/conf, you will find a new file called
serverCert.profile.exampleWithSANpattern
- copy existing serverCert.profile away and replace with
serverCert.profile.exampleWithSANpattern
- edit serverCert.profile.exampleWithSANpattern
    - follow the instruction right above 8.default.
    - save and quit
- cd /usr/share/pki/ca/profiles/ca , edit caInternalAuthServerCert.cfg
    - follow the instruction right above policyset.serverCertSet.9
    - save and quit
- save away and edit the ca config file for pkispawn: (note: you can
add multiple SAN's delimited by ',' for pki_san_server_cert
    - add the following lines, e.g.
    pki_san_inject=True
    pki_san_server_cert=host1.Example.com
    - do the same pkispawn cfg changes for kra or any other instances
that you plan on creating
- create your instance(s)
  check the sl sever cert, it should contain something like the
following:

                Identifier: Subject Alternative Name - 2.5.29.17
                    Critical: no
                    Value:
                        DNSName: host1.Example.com

Metadata Update from @dminnich:
- Issue assigned to cfu
- Issue set to the milestone: 10.2.3

7 years ago

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/1878

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.

Login to comment on this ticket.

Metadata