Closed
Bug 1017127
Opened 10 years ago
Closed 10 years ago
Cybertrust: No subject alt name
Categories
(CA Program :: CA Certificate Root Program, task)
CA Program
CA Certificate Root Program
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
Reporter | ||
Comment 1•10 years ago
|
||
That should have been "without" instead of "with"
Comment 2•10 years ago
|
||
Steven, here's another one. Please respond in the bug.
Updated•10 years ago
|
Assignee: kwilson → steve.medin
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: BR Compliance
Assignee | ||
Comment 3•10 years ago
|
||
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.
Assignee | ||
Comment 4•10 years ago
|
||
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.
Updated•10 years ago
|
Blocks: BR-Compliance
(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.
Assignee | ||
Comment 6•10 years ago
|
||
@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?
Assignee | ||
Comment 8•10 years ago
|
||
The attachment is issued by the customer referenced in #4 and #6.
Comment 9•10 years ago
|
||
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
Updated•7 years ago
|
Product: mozilla.org → NSS
Updated•1 year ago
|
Product: NSS → CA Program
You need to log in
before you can comment on or make changes to this bug.
Description
•