Closed Bug 1017127 Opened 10 years ago Closed 10 years ago

Cybertrust: No subject alt name

Categories

(CA Program :: CA Certificate Root Program, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kurt, Assigned: steve.medin)

References

Details

(Whiteboard: BR Compliance)

Attachments

(1 file)

1.54 KB, application/x-x509-ca-cert
Details
I'm seeing certificates with the subject alternative name extension from the following path:
CN = Baltimore CyberTrust Root, OU = CyberTrust, O = Baltimore, C = IE
CN = Cybertrust Public SureServer SV CA, O = Cybertrust Inc
That should have been "without" instead of "with"
Steven, here's another one. Please respond in the bug.
Assignee: kwilson → steve.medin
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: BR Compliance
We are actively retiring this subordinate CA.  Its replacements use issuance policies that copy CN to dNSName SAN and support additional SANs.

We previously received a request from a customer to suppress SAN creation when not present in the PKCS#10 and temporarily honored this practice.  This waiver was disabled, requiring SAN, as SAN presence became mandated by policy.  While our application software had a feature that allows SAN suppression on a per customer account basis, this feature is no longer enabled for any accounts.
In addition, one customer operates a different and now end of life interface with us than the platform referred to at #3.

Their usage is in the last stages of being migrated to our current platform and our current subordinate CAs.  That migration will end their issuance of certificates that omit SAN.
(In reply to Steven Medin from comment #3)
> While our application software had a feature that allows SAN
> suppression on a per customer account basis, this feature is no longer
> enabled for any accounts.

When did this occur? I have a certificate from April 16, 2014 that has no SAN.
@4, I indicated that the customer in question used our old software and was in the end stages of migrating to our current software.  They began operation on the new platform on July 22.  All customers already on the current platform faced enforced SAN in early 2013 once we reviewed the interoperability issue with our customer that faced problems with certs containing SANs.

Could you provide the DN and serial of the certificate, please?
Attached file gte_nosan.cer
The attachment is issued by the customer referenced in #4 and #6.
Resolving this bug, based on Steve's assertion that this cannot happen in future.

Although we have no specific plans to do so at the moment, Mozilla reserves the right in the future to start ignoring CN and considering only SAN. (That is the long-term goal of the all-names-must-be-in-SAN policy.)

Gerv
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: