dogtagpki

#2956 Missing constraint & agent verification of Subject Alternative Name (SAN) extension
Closed: migrated by dmoluguw. Opened by tokred.

Closed: migrated
Reopen Issue

Currently, I am implementing Dogtag PKI 10.4 on Centos 7.3 in my company environment, primarily for TLS server certificates based on provided CSRs using caServerCert profile.

DNS FQDN in the subject's CN is deprecated for ages (RFC 2818 from '00), instead there is the Subject Alternative Name (SAN) extension with dNSName type. Fallback to CN is also deprecated since RFC 6125. Therefore, we need full SAN support.

I had to find out that there are two major features missing regarding the handling of SAN extensions:

  • a constraint class for SAN, similar to subjectNameConstraint
  • agent verification of the SAN content prior to approval (i.e. displaying in approval form), also similar to subject, to control issuing of certificates

This is really unfortunate, especially due to the increased (and legitimate) enforcement of proper SAN handling of Google Chrome, various libraries, etc.

Developing commonNameToSANDefault was great, but without the abovementioned functionality I am afraid it's only of little use. userExtensionDefault for OID 2.5.29.17 doesn't solve this either.

Any ideas for pragmatic solutions?

Best regards

Metadata Update from @mharmsen:
- Custom field component adjusted to None
- Custom field feature adjusted to None
- Custom field origin adjusted to None
- Custom field proposedmilestone adjusted to None
- Custom field proposedpriority adjusted to None
- Custom field reviewer adjusted to None
- Custom field type adjusted to None
- Custom field version adjusted to None
- Issue set to the milestone: 0.0 NEEDS_TRIAGE

Hi @tokred. Yes, this is a missing feature. The only practical workaround is if you use a profile
with no way to directly input a SAN, then use CommonNameToSANDefault, and rely on SubjectNameConstraint to also validate the SAN. That means that there would be a maximum of one SAN dnsName, so this approach is of limited use.

Because you want a solution today, the only other approach I can suggest is to implement the constraint class yourself, and configure Dogtag to use it. We'll be happy to assist and you are welcome to contribute the code upstream.

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

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.

Metadata Update from @dmoluguw:
- Issue close_status updated to: migrated
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
None
None
None
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.