Hello sirex, sorry for the long wait. I investigated this ticket (and reproduced it myself) and confirmed it is really an issue.

I think it should be safe to allow subjectAltNames in the default profile given that IPA cert-request command already checks all CSR and makes sure that all subjectAltNames are hosts registered in FreeIPA and that the host requesting it is managing all these subjects. This prevents hosts to add random subjectAltNames.

Duplicate ticket: #3978

There are two ways to allow user supplied SAN extension:

A. use the userExtensionDefault profile plugin, which I think Dogtag currently supports:
https://access.redhat.com/site/documentation//en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/Certificate_and_CRL_Extensions.html#User_Supplied_Extension_Default
make sure you read the Warning and the Note so you know what you are getting into.

B. I have in some limited CS8.1 beta releases "out of band" solution. It involves a modified profile default plugin and a new input plugin. This solution allows one to specify multiple SAN's along with the CSR (READ: outside of the CSR, but along with the url to the CA as part of the HTTP request). This requires that the client of the CA to be trusted.
Again, this is not currently available in Dogtag.

Thanks for information. I read the documentation although I am not sure I understood right how the user extensions constrains work.

This is how I would imagine that dogtag would behave:

• If subjectAltNames user extension is present in the certificate request (and passes IPA checks), dogtag adds the subjectAltNames to certificate
• If the subjectAltName user extension is not specified in the request, it is not added to certificate
• Any other user certificate extension is ignored

Can dogtag be configured that way or am I misunderstanding the configuration? Also adding awnuk to CC as he is now involved in IPA/PKI integration.

I read the "NOTE" in the doc one more time, and I suspect it's talking about how it was at one point in some earlier version of RHCS. To confirm, I looked in the code and it does not seem to require having the specified OID extension. If that's true then the doc requires an update.

If you happen to have a request that contains the Subject Alternative Name extension, I can run a quick test for you and let you know the result.

Ok, following steps in #3184 I generated a CSR with a cn=client1.example.com and subjectAltName=client.example.com. I will attach it to this ticket.

CSR with subjectAltName
server-alt-names.csr

Replying to [comment:6 mkosek]:

Ok, following steps in #3184 I generated a CSR with a cn=client1.example.com and subjectAltName=client.example.com. I will attach it to this ticket.

It seems to be working fine:
...
Identifier: Subject Alternative Name - 2.5.29.17
Critical: no
Value:
DNSName: client.example.com
...

I'll attach the b64 of the cert.
It also works if I submit a CSR without SAN.

b64 of the cert for the earlier attached csr with SAN.
ipa-cert.b64

Also, you asked about constraints. Profile constraints are for policy enforcement. It is highly recommended especially when allowing for user supplied extensions. For example, it currently does not exist (though shouldn't be too hard to do), but I'd strongly recommend that you add a SAN constraint that takes a pattern to limit the domain to what you specify in the profile (e.g. *.example.com). It is much like the SubjectNameConstraint that we currently support, just that it'd be for SAN.

Of course if the client is proven trusted to generate and submit the CSR then maybe it is not as critical.

Thanks for info. About SAN constraint - it seems as a nice to have now. In IPA we already have checks for the SAN extension so that principal can only ask for allowed list of SANs (set by managedby attribute in the host entry). Maybe it is a potential optional attribute to the installation. Do I understand it right that this constrain is currently not supported in Dogtag? If yes, I can open an RFE ticket.

About Dogtag configuration - is there a configuration I could set so that the dogtag behaves as specified in comment:4? If yes, I would be interested in it. I am especially interested in making sure that other cert extensions are not just blindly copied and only SAN is allowed at this time.

It's correct that there is currently no SAN constraint as far as I know. Yes if you need it, RFE can be filed.
For configuration. The userExtOID already sets the constraint for the allowed OID.
So, in my test example, I have
policyset.otherCertSet.10.default.params.userExtOID=2.5.29.17
which is already limiting the allowed user supplied OID to be SAN.
However, to further setting constraint for the actual content of the SAN, you will need to write a constraint plugin as I suggested earlier.

Seems like this feature is needed for the OpenStack integration. Bumping the priority. And moving to December.

Honza, please check this ticket. The development should not be complicated, all the information and discussion is in the ticket already.

Hi I do not see anything about access control, but it is clear to me that it is imperative that adding subject alt names should be authorized only if the request comes from an admin/privileged account.

Has this been factored in the design ? (I do not see a design page either)

The patch on the list doesn't include additional permissions, it just modifies the profile to enable SAN.

Simo, FreeIPA cert-request command is already doing authorization via host's managedby attribute. You need to be a manager of a host to be able to state it as subjectAltName.

So we had the authorization part, but missed the actual functional part...

That's true, it would also be possible to add a virtual permission to be able to issue SAN certificates in general. That isn't something I considered when I half-implemented this before.

Replying to [comment:19 mkosek]:

Simo, FreeIPA cert-request command is already doing authorization via host's managedby attribute. You need to be a manager of a host to be able to state it as subjectAltName.

So we had the authorization part, but missed the actual functional part...

Being a manger of the host is not sufficient to give you the permission to add arbitrary names.

If I am the manager of: *.lowsecurity.systems.domain.com I must not be allowed to add a subjectaltname of supersecret.highsecurity.systems.domain.com to a low security machine, otherwise you allow a low-privileged person or host to hijack high security systems.

I repeat there must be code that porevents anyone but security admins to add arbitrary names to a certificate.

It is not clear to me if patch 210 from Jan will automatically allow to add arbitrary subject alt names, if so it must be nacked.

The patch enables setting SAN in IPA certificate profile, nothing else. The authorization is already done in cert-request, as Rob pointed out. In other words, the patch changes IPA behavior from "no one can set SAN, ever" to "authorized user can set SAN".

If the authorization policy needs to be changed, so be it, but do it in other ticket, this ticket is about the certificate profile only.

You are not. If you are a manager of a low secure host, you cannot add a certificate with arbitrary SAN. This is what happens:

# cat santest.cnf 
[req]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
encrypt_key = no

[req_distinguished_name]
countryName = LU
stateOrProvinceName = Luxembourg
localityName = Luxembourg
0.organizationName = EBRC
organizationalUnitName = EBRC
commonName = ipa.example.com
emailAddress = ccc@ebrc.com

[ v3_req ]
subjectAltName = @alt_names

[alt_names]
DNS.1 = highsecure.example.com


# openssl req -out server.csr -new -newkey rsa:2048 -nodes -keyout server.key -config santest.cnf 
Generating a 2048 bit RSA private key
.............................................................+++
.........................................................................+++
writing new private key to 'server.key'
-----

# kinit -kt /etc/krb5.keytab host/`hostname`

# ipa cert-request server.csr --principal host/`hostname`@EXAMPLE.COM
ipa: ERROR: Insufficient access: Insufficient privilege to create a certificate with subject alt name 'highsecure.example.com'.

To make it allowed, admin must run host-add-managedby or service-add-host commands to modify the hostname/service entry and add the host to the list of hostnames that can manage the service or host. There is also some note about it on original design.

Honza, it seems to me though that the logic in cert-request is reversed and it checks managedby attribute on the target host and not on the SAN hosts, is that correct?

It looks like it indeed does that, yes.

This ticket is not complete yet, moving to next month milestone.

master:

• e675e42 Allow SAN in IPA certificate profile.
• d6fb110 Support requests with SAN in cert-request.
• 8b8774d Remove GetEffectiveRights control when ldap2.get_effective_rights fails.

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1112605