(In reply to Andrew Ayer from comment #6)
Could GLOBALTRUST elaborate on why a "complete run" requires using a publicly-trusted CA? Why could wildcard issuance not have been tested using an untrusted test CA? Has GLOBALTRUST considered using test CT logs, like Google Solera or Let's Encrypt Testflume?
I agree this is an extremely unlucky wording.
The emphasis should not have been on CT, nor a real CA would be necessary. However, we already know and have used test CT logs. Also,this was NOT a test certificate.
Rather it is always possible that issues occur in a real run-through, that were not yet present in test scenarios.
Also, there is no problem with the wildcard itself, but with the combination of a wildcard with a non-wildcard in case the customer specifies a wrong CN . Before this incident, we have checked at the time of order but not immediately before issuance .All test cases had a valid CN. Yes, we know that this is a serious gap - which we immediately closed as reported.
Why is it the customer's responsibility to specify a CN value? One way to avoid this error entirely would be for the system to automatically use the first SAN entry as the CN (provided it is not too long to fit in the CN).
It is rather his opportunity not his responsibility. As part of our customer journey, a customer can specify a range of SANs to be used by the machine but can choose which one he wants to be the prominent "main" name.
As described in the initial incident report, we do it vice versa and move the CN to the SAN, in case the applicant did not already specify it.
This approach has grown historically from a time when there were no SANs at all and is based, among other things, on the fact that we also have other certificate types where a CN is ordered, but (also) has to be moved somewhere else.
Or better yet, omit the CN entirely, considering it long since deprecated. Has GLOBALTRUST evaluated these options?
This is not quite as simple as abolishing the OU (no one really needs it, it doesn't hurt us, the doubts are justified.)
But of course I fully agree that abolishing the CN would immediately get to grips with all these cases! However so far we have not had any certainty how applications (beyond the major browsers) would react to a certificate without a CN in it. Do you have experience you can share with me?
Could GLOBALTRUST elaborate on precisely what happened here? What values did the customer initially provide for the CN and SANs?
The original order was:
SANs: e-rating.at, *.e-rating.at, mail.e-rating.at
Our system denied this CN because because it expected a CN to be a fully qualified domain name in the sense of having at least 2 portions other than the top level domain.
(We are aware that e-rating would have been an CN allowed by the BR)
The CN was than corrected to www.e-rating.at but the SAN was not followed up. Today this would lead to an error, in the sense that issuance is blocked, until you have a 1:1 matching of the CN and one of the SANs
If the customer had initially specified
www.e-rating.at as the CN, would the request have been properly rejected?
No, because the correct CN would have been moved to the SAN automatically.
If the customer initially provides invalid values and later corrects them, are there any other validation checks that can be, or could have been, bypassed?
Are/were domain validation and CAA checking performed on corrected values?
This constellation was only possible for issuing wildcard-certificates.
Why is this?
Historically grown, we manage wildcard domain names and defined server names differently
What new check routines have you added?
As described above and in the original report
In what format do customers specify the CN and SANs?
We require the customer to specify defined fully qualified domain names or wildcard domain names or ipv4 addresses and separate them with commas without spaces. This is not yet optimal, in the past we even required to type DNS: or IP:.
At what stage in the issuance pipeline is the customer's specification parsed into the machine representations that are ultimately placed in the certificate? Is validation (such as checking that the CN is in the SANs, domain validation, CAA) done before or after this parsing occurs?
In general every application undergoes a process that is broken down into different defined status:
- Order available
- Order collected in our system
- Order in work, this includes validation depending on certificate type
- Validation completed, approved by first operator
- Verification through second operator.
- Check of the issued certificate
- Depends on type and situation, under normal circumstances delivery to customer.
The machine represantation to be included in the certificate is created at stage 6. Issuance.
GLOBALTRUST previously stated that zlint was "under consideration". What is the current status of that consideration? Does GLOBALTRUST have a timeline for adopting zlint?
This is a matter of integration efforts and whether the technical conditions are practicable.
The specifications of the common linting tools including disucssions around them have also been part of our ongoing requirements monitoring.
In some issues, we also have to go much further then the linters would. For example, none of them checks BR 126.96.36.199.1 as an exhaustive list, or: for us the existence of both CRL and OCSP is mandatory.
We have also been learning a lot from other CA’s current and previous incidents.