Re: Which fields containing email addresses need to be validated?
On Thursday, February 6, 2020 at 6:05:20 PM UTC-5, Ryan Sleevi wrote: > (Replying from the correct e-mail) > > On Thu, Feb 6, 2020 at 3:55 PM Doug Beattie via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > We should clarify the Mozilla policy to more clearly define list of fields > > containing email address (those 3 listed above) must be validated in > > section > > 2.2 so that this is clear and concise. > > > > Doug, > > Is the proposal that, similar to how TLS defines that domain names MUST > appear within the SAN:dNSName, that emailAddresses MUST appear within one > of those three fields (that is: subject:commonName, subject:emailAddress, > subjectAltName:rfc822Name), that any value in the subject MUST also appear > in the subjectAltName, and an emailAddress MUST NOT appear in any other > field? I agree with your description of where S/MIME email addresses must go, but I don't agree with your last statement that an email address "MUST NOT appear in any other field". More below. > That would address the concern, correct? > > Wayne opened this issue in December and I just replied with a comment > > related to the validation requirements of SAN/Other Name/UPN: > > > > https://github.com/mozilla/pkipolicy/issues/200 > > > I'm not sure I understand your question on this issue, and was hoping you > could expand. As you note, it's not used within S/MIME, so presumably, it's > not necessary for an S/MIME certificate, and thus MUST NOT be included. > That would resolve the ambiguity, correct? While it's not necessary for S/MIME, it's common to use an S/MIME certificate for both secure mail and client authentication (and even other things like ipSEC, file encryption etc). 1) Many/most CAs include both secure mail and client auth EKUs to permit such use. Is including the client auth EKU not permitted because it's not needed for S/MIME? 2) When using this S/MIME certificate for client authentication to a corporate system, the subjectAltName:UPN may be needed. The UPN typically contains an email address which may be the same, or may be different from the one in subjectAltName:rfc822Name. Since the UPN is not used for S/MIME, then its value should be opaque to S/MIME clients and the validation of this field should not need to follow the Mozilla policy for email validation. 3) Is including an email within a private extension not permitted, perhaps for a special usecase outside of S/MIME? 4) Is including an email address in any other subject field (there is a long list of subject fields in https://tools.ietf.org/html/rfc4519) not validated in accordance with the policy prohibited in S/MIME certificates? Since S/MIME applications use the email address only in the 3 fields you listed, is including it elsewhere an issue? Given there are no standards for the validation or use of an email address in any field (including the 3 used for S/MIME) when the secure mail EKU is NOT included, is there an issue when including email addresses in fields outside of those 3 when the certificate contains the secure mail EKU? I posted my proposed change to the Mozilla policy here: https://github.com/mozilla/pkipolicy/issues/200 Maybe this will be addressed as part of the S/MIME Certificate working group and we can wait until then. > Are you aware of any system that requires a single certificate contain both > in order to be used for S/MIME? If I understood your question right, it's > not required. No, not for S/MIME. Yes for when an S/MIME certificate is used for S/MIME and other purposes. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Question about the issuance of OCSP Responder Certificates by technically constrained CAs
Ryan, Given the recent announcement "SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responded Cert", how does you discussion in this thread relate to this? Are your responses here to a different question, because it appears (likely my misinterpretation) from this thread it's OK to include OCSP-signing into a CA certificate? https://groups.google.com/d/msg/mozilla.dev.security.policy/EzjIkNGfVEE/XSfw4tZPBwAJ On Wednesday, September 4, 2019 at 11:01:36 AM UTC-4, Ryan Sleevi wrote: > On Wed, Sep 4, 2019 at 9:47 AM Peter Mate, Erdosi via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > My question is the following: is it allowed to issue an OCSP Responder > > certificate with "id-kp-OCSPSigning" EKU from a technically constrained CA > > if the "id-kp-OCSPSigning" EKU is not listed in the CA certificate, > > > This will fail, not because of policy reasons, but because of technical > reasons (not Firefox). > > The code (for Firefox) is > https://dxr.mozilla.org/mozilla-central/rev/fd891e83a7cd54038b0bcebb3ab85b6818e2550e/security/nss/lib/mozpkix/lib/pkixcheck.cpp#819-888 > , > with the most salient logic at > https://dxr.mozilla.org/mozilla-central/rev/fd891e83a7cd54038b0bcebb3ab85b6818e2550e/security/nss/lib/mozpkix/lib/pkixcheck.cpp#873-884 > , > although the explanation in > https://dxr.mozilla.org/mozilla-central/rev/fd891e83a7cd54038b0bcebb3ab85b6818e2550e/security/nss/lib/mozpkix/lib/pkixcheck.cpp#863-869 > explains > the technical reasons. > > > > in other words, is the inclusion of the "id-kp-OCSPSigning" EKU a > > possible, mandatory or forbidden option for such CAs? > > > > This is not forbidden by policy. That is, a technically constrained > subordinate CA certificate can have id-kp-OCSPSigning and id-kp-serverAuth. > > As I see in the practice, if a technically constrained CA signs the OCSP > > response itself, it can be done without the "id-kp-OCSPSigning" EKU but > > with the "digitalSignature" KU bit in the CA certificate. > > > > Correct, if the id-kp-OCSPSigning EKU is missing from the technically > constrained intermediate, direct signing still works. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Suspicious test.com Cert Issued By GlobalSign
On Monday, February 27, 2017 at 11:04:53 AM UTC-5, Gervase Markham wrote: > Hi Doug, > > On 15/02/17 17:09, Gervase Markham wrote: > > But currently GlobalSign employees still are? > > > > If so, can you help us understand why that's necessary? Given that you > > control the domains used for testing, you should be able to set them up > > to auto-pass some form of automated validation, so imposing a validation > > requirement for every addition would not, at least on a superficial > > understanding, lead to increased friction in testing. > > It's been quite some time since this question was posed; when might you > have a response? Sorry, I missed the last request. As outlined above, this domain was added to this account for only a very short period of time and then it was removed, so it's no longer being used. Further, we've educated the groups involved that they must use real domains that are then properly verified in accordance with the CPS and BRs. > Thanks, > > Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)
On Tuesday, February 28, 2017 at 7:29:30 AM UTC-5, Itzhak Daniel wrote: > On Tuesday, February 28, 2017 at 1:38:25 PM UTC+2, Gervase Markham wrote: > > I think that without more evidence we must assume that GlobalSign > > validated this domain correctly at a time when it existed. > > There are many more test*.* domains, non of those (about 10) I checked exist. > I will compose a full list and reply. > > I also would like to have an official reply from GlobalSign saying that "on > the date they issue the certificate the domain exists". On the date that the certificate was issued it was verified in accordance with the Domain Verification requirements in the BRs. Doug Beattie GlobalSign ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GlobalSign BR violation
On Monday, February 27, 2017 at 4:05:09 PM UTC-5, Jakob Bohm wrote: > On 27/02/2017 01:53, Itzhak Daniel wrote: > > How those lines are parsed? what happens when a client reaches a > > whitespace? Will this allow 'vietnamairlines.com' to use 'owa', 'mail' and > > 'autodiscover' in their internal infrastructure? > > > > Programs don't parse the text lines from the crt.sh website. They > parse the clearly delimited binary (DER encoded) certificate. > > Looking at a more detailed dump of the actual certificate shows that > those are indeed spaces and not a parsing error by crt.sh though. > > I don't know if owa.m.vietnamairlines.com ever existed, but I happen to > know that GlobalSign provides the 3 exchange-related DNS SANs at no > extra charge when ordering an EV certificate, so maybe those invalid > DNS SAN entries were simply never used or discovered. > > From all of this, it looks like a technical processing error when > generating the SAN attribute, as the primary name > (m.vietnamairlines.com) was emitted correctly. The certificate is > *currently* used by https://m.vietnamairlines.com and may never have > been intended (by the airline) for use with the 3 exchange names that > were incorrectly encoded (such as owa.m.vietnamairlines.com, not > owa.vietnamairlines.com). > > But really, GlobalSign should reach out to the airline and reissue the > certificate without the stray space characters, then revoke the broken > cert after the webserver has switched (within reasonable time). Yes, we're working to do just this now. > GlobalSign should also check if other EV certificates were issued with > the same processing bug and arrange to have any such certificates > similarly fixed. > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GlobalSign BR violation
Ryan, GlobalSign certificate issuance has been referenced in several different threads recently and I think most of them are closed; however, if you feel otherwise, let me know. Suspicious Test certificate https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/-gaS1p3vrXc I provided a formal response in that thread that I believe closes this issue. Incapusla certifciates with SANs for domains that don't currently exist https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/l1mDdCL8LlU This is not an issue as all SANs were validated in accordance with the BRs when the domain was verified, thus no formal response is needed. And lastly this ticket. The Domain name was validated in accordance with the BRs, but there was a bug that allowed a user entered space to be included in some of the SAN values. While the value is not compliant with RFC 5280 or the BRs, there was no security issue with the certificate that was issued (it was likely not able to secure the intended subdomains). We'll provide an incident report for this. If this isn't sufficient for some reason, I'm sure you will let us know. Doug On Tuesday, February 28, 2017 at 1:06:57 PM UTC-5, Ryan Sleevi wrote: > On Tue, Feb 28, 2017 at 8:53 AM, douglas.beattie--- via dev-security-policy > wrote: > > > > > Yes, we're working to do just this now. > > > While that's good and well, I do hope GlobalSign will produce an incident > report regarding this matter, as to how the situation in > https://groups.google.com/d/msg/mozilla.dev.security.policy/luxlU5TL2ew/qkL1ZdThAQAJ > came to be in the first place. > > I think GoDaddy's recent explanation - > https://groups.google.com/d/msg/mozilla.dev.security.policy/Htujoyq-pO8/uRBcS2TmBQAJ > - may provide a model for GlobalSign here. > > The intent is that we don't just deal with the symptom, but that we work to > understand the root cause, the scope of impact, and the opportunities for > improvement. > > I look forward to reading GlobalSign's analysis of both this and other > recent issues. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)
On Wednesday, March 1, 2017 at 8:26:34 AM UTC-5, Peter Kurrasch wrote: > Would it be possible to get a more precise answer other than "in accordance > with"? I am left to assume that in fact no verification was performed because > the previous verification was in the 39 month window. For this SSL product, customers place orders which are vetted to the OV level with normally just a single SAN. Once the order has been approved they can add SANs by verifying domain control via DNS or File based verificaton options. Over time they add and remove SANs as their customer base changes. They can re-issue the certificate which keeps the expiration date and the subject DN the same, but they add and remove SANs. In this case they did not remove SAN which are clearly not functional and are for domains which have expired. The reissueance process does not require the re-verification of the domain control, thus the certificate was reissued with these SANs. Subscribers are required to tell us when the certificate contents is no-longer accurate so appropriate action can be taken, but clearly this customer did not inform us. We'll be talking with them about this to find out why. Doug > > Original Message > From: douglas.beattie--- via dev-security-policy > Sent: Tuesday, February 28, 2017 6:46 AM > > ...snip... > > > I also would like to have an official reply from GlobalSign saying that "on > > the date they issue the certificate the domain exists". > > On the date that the certificate was issued it was verified in accordance > with the Domain Verification requirements in the BRs. > > Doug Beattie > GlobalSign > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)
I wanted to send out a short update of were we are on looking into the reported Incapusla/testslsslfeb20.me certificate and the thread of comments and questions above. In this specific case the domain was verified within 39 months of issuance/reissuance (no difference as Ryan pointed out). In general, when we receive new orders and issue certificates, the vetting is done just prior to issuance time which permits the certificate to be replaced up until expiration. We're looking into cases where new "orders" may have used certificate data that was done prior and then verifying that the domains (and enterprise data on the subject DN) are re-verified at the applicable intervals. I'll send out an update as soon I have more information. Doug ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Suspicious test.com Cert Issued By GlobalSign
On Thursday, March 16, 2017 at 6:59:41 AM UTC-4, Gervase Markham wrote: > Hi Doug, > > On 03/03/17 11:17, Gervase Markham wrote: > > That's lovely, but it doesn't answer my question. Let me restate it: why > > does GlobalSign believe it is necessary to give employees the power to > > add arbitrary domains to accounts without going through ownership > > validation? > Hi Gerv, For the record, we don't think it's necessary (or permissible) to give employees (RAs) the power to add arbitrary domains to accounts without proper vetting. This was a breakdown in the vetting process whereby this "test" domain was added in order to issue a certificate in production. When this was done the cert was revoked and the vetting for the domain was disabled. After this happened back in 2015 all of the RAs were instructed to follow production vetting procedures in production (obviously) and to not bend or break them when doing "testing". ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Suspicious test.com Cert Issued By GlobalSign
On Thursday, March 16, 2017 at 11:49:44 AM UTC-4, Gervase Markham wrote: > Why does GlobalSign believe it is necessary for employees to have the > technical capability to add arbitrary domains to accounts without going > through ownership validation? > > I mean, clearly they did back in 2015, because that's exactly what > happened. Do they still have the technical capability (ignoring policy > and set procedures for a moment) or not? Yes, RAs (trusted role employees) need to have the technical ability to manually add domains to accounts. They can verify domains in one of the 10 different methods and some of those involve manually looking in who-is for registrant info, using a DAD or in calling the contact. When one of these is used, we collect the vetting data then the RA can add/approve that domain. > Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Suspicious test.com Cert Issued By GlobalSign
On Friday, March 17, 2017 at 5:37:38 AM UTC-4, Gervase Markham wrote: > On 16/03/17 17:20, douglas beattie wrote: > > Yes, RAs (trusted role employees) need to have the technical ability > > to manually add domains to accounts. They can verify domains in one > > of the 10 different methods and some of those involve manually > > looking in who-is for registrant info, using a DAD or in calling the > > contact. When one of these is used, we collect the vetting data then > > the RA can add/approve that domain. > > But is the addition of the domain gated on the > uploading/attachment/submission of what could plausibly be vetting data? It's gated on the RA following the correct process which is uploading the documents in one system and then approving the domain in a different system. > I mean, I understand you can't programmatically check that a person has > made a phone call. But you can require them to write a report of the > results of that phone call and not allow addition of the domain until > they've done it. Yes, they could just put "flibbertigibbet" into the > text box, but that at least shows they are deliberately bypassing the > process. > > If the addition is so gated, what did the employee in this case do? Did > they upload bogus data? No bogus data was uploaded. Doug ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GlobalSign BR violation
Attachment was stripped, here it the content: GlobalSign BR violation: EV Certificate with dNSName containing a space On February 26, 2017, we received a report that there were multiple SANs in an EV SSL Certificate that contained a space within it. Spaces are not permitted characters, per RFC 5280. We notified the customer on March 1, 2017 and revoked the certificate the next day on March 2, 2017. How this happened: A customer ordered a certificate with CN of m.vietnamairlines.com and requested 3 additional SANs as listed below. The base domain, “vietnamairlines.com”, was vetted and the certificate was then approved and issued. When they ordered this 2 year certificate in August 2015 they entered a space (likely via copy/paste) in the SAN fields and this was not obvious the vetting team when they were reviewing the request. Our ordering application did not properly strip out the spaces and the vetting team did not notice the space in the middle of these SANs. The result was this set of invalid SAN values: * owa. m.vietnamairlines.com * mail. m.vietnamairlines.com * autodiscover. m.vietnamairlines.com Scope of the problem: As part of this problem investigation, we went back and searched for DNSNames with characters that don’t comply with RFC 5280 in active certificates. We found 11 orders (each with 1 active certificate) that contained values non-compliant with the RFC and we found one order with 34 active certificates (due to many certificate updates/reissuances for this order). All have been revoked. In February 2016, we put in more comprehensive data validation for SANs and CNs and have not issued any non-compliant dNSName values in SSL Certificates since that time, until last week on March 21, 2017. We issued a Wildcard OV SSL Certificate with a SAN of the format www.*.domain.com. It has been since revoked. The issue here is that the updated logic released in February 2016 was not applied to a certain case for a certain language specific validation routines (we have unique server side validation routines for different languages and one was missed). Plans for Remediation: GlobalSign is continuing to improve automated compliance checking services to catch issues prior to issuance in a centralized location as a standard compliance process that all certificates will need to pass. In addition to checking data when we receive new orders, we will be adding independent, redundant checks as follows: * By the end of May 2017, we’ll be adding an independent post issuance check for 100% of issued SSL Certificates. This centralized check can be more robust and will proactively detect errors so we can address them immediately. * By the end of July 2017, we’ll be adding the same independent pre-issuance check in-line with the issuance process at the very last step prior to issuance to check issues before issuance. We feel that adding these 2 additional levels of checking we will eliminate issuance of certificates with CommonName and SAN values that do not comply with RFC 5280. We plan to add redundant pre- and post-issuance validation for additional fields later this year. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Email sub-CAs
On Thursday, April 13, 2017 at 10:49:17 AM UTC-4, Gervase Markham wrote: > On 13/04/17 14:23, Doug Beattie wrote: > > In 3.2 the term Technically Constrained is not defined to be any > > different than the BRs (or perhaps even less restrictive). > > You mean 2.3, right? Yes, 2.3. > I would say Inclusion section, bullet 9 gives the definition of > technically constrained. For email certs, because of the bug described > in issue #69, it basically just says that it has to have the > id-kp-emailProtection EKU. It should say more, but it doesn't. That's > problematic, because just having an EKU isn't really a technical > constraint in the "TCSC" sense. > > > In 3.2 > > this is all I can find regarding CAs that are capable of signing > > secure email certificates, section 9: "If the certificate includes > > the id-kp-emailProtection extended key usage, then all end-entity > > certificates MUST only include e-mail addresses or mailboxes that the > > issuing CA has confirmed (via technical and/or business controls) > > that the subordinate CA is authorized to use." > > > > There is no statement back to scope or corresponding audits. Were > > secure email capable CAs supposed to be disclosed and audited to > > Mozilla under 2.3? > > If they did not include id-kp-serverAuth, I would not have faulted a CA > for not disclosing them if they met the exclusion criteria for email > certs as written. OK. > > and how it applies to Secure email, I don't see how TCSCs with secure > > email EKU fall within the scope of the Mozilla Policy 2.3. Can you > > help clarify? > > I think this is basically issue #69. > https://github.com/mozilla/pkipolicy/issues/69 OK, I look forward to a conclusion on that. I hope that name constraining a secure email CA (either technically in the CA certificate or via business controls) is sufficient to avoid WebTrust Audits. If Public disclosure helps get us there then that would be acceptable. > I don't think it was supposed to be the case that intermediates with > id-kp-emailProtection alone were supposed to be considered TCSCs. After > all, certs with id-kp-serverAuth alone are not TCSCs; they need to have > Name Constraints as well. But you are right, that's what the policy says. > > > OK, you're right, the number of negatives in that section got me. > > So, even when EKU permits just secure email, having name constraints > > does not exempt a CA from the Mozilla policy. It does for BRs since > > email is not within scope (and discussed on the link you included in > > the response). When I saw TCSC references I personally didn't > > realize that this was different than the BR definition of TCSC (maybe > > should have called this something different). > > > > Section 3.1.2.1 specifies that any CA capable of issuing secure email > > certificates must have a "WebTrust for CAs" audit (or corresponding > > ETSI audit). This is a huge change from 3.2 and I wonder if all CAs > > understand this. Even the Blog about this version does not highlight > > this substantial change: > > https://blog.mozilla.org/security/2017/04/04/mozilla-releases-version-2-4-ca-certificate-policy/ > > I didn't realise it _was_ a substantial change. Are you saying that you > used to think it was fine for email-only sub-CAs to have no audits at > all? Is this because you considered all such CAs to be TCSCs (by the > Mozilla definition)? Yes, we've been working hard to technically constrain all CAs and especially those operated outside of our infrastructure. We've been following the BR definition: Include EKUs in all CAs, and for those that include server auth or secure email, include name constraints. > Even if we didn't require it in our policy, I'm very surprised that > no-one else does. Which other root store policies have requirements on > email-only sub-CAs? Not that I know of. > > Obviously there are a lot of technically constrained CAs issued to > > organizations to run their own CAs for issuing secure email and > > client auth certificates. In order for them to continue operations > > they now every organization needs to be publicly reported and audited > > (a new requirement for 2.4.1 as far as I can tell), is that right? > > This is issue #36 :-) > https://github.com/mozilla/pkipolicy/issues/36 > > Do the CAs you are thinking of in this category have name constraints, > or not (either actually in the cert, or via business controls)? Yes - they are all either name constrained either via the certificate name constraints or via business controls. > > When did (does) this take effect? Is this for new CAs, existing or > > both? When would the Audit Period for these CAs need to begin? > > > > This is a side question, but does the Mozilla policy require that > > these CAs meet the Network Security Requirements? > > https://github.com/mozilla/pkipolicy/issues/70 :-) Not at the moment. OK > > Section 5.3.2 says that all CAs of the type I'm discussing must be in > > the CCADB.
Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)
Misissuance Report On February 25th 2017, we received a report that there was a SAN in an Incapsula OV certificate (specifically an OV certificate issued via the GlobalSign CloudSSL product) for a domain that is no longer registered (testsslfeb20.me). 1) GlobalSign CloudSSL product description To help clarify what we mean by GlobalSign CloudSSL product we wanted to describe the different operations CloudSSL customers can perform. CloudSSL supports New, Update, Reissue and Renew operations which all result in a new certificate being created. * New: We perform a manual organization validation on the initial CloudSSL OV certificate and CommonName. We assign a new OrderID. * Update: Customers can request the addition and removal of SANs. When a SAN is added, it is validated (in accordance with one of the approved domain validation methods) and then when the Update command is called, a new certificate with the requested changes is issued. The issued certificate has the same Subject DN, expiration date and OrderID. * Renew: When a CloudSSL order is renewed, it retains the same OrderID and Subject DN but the validity period is extended by 1-2 years. * Reissue: When a CloudSSL certificate is Reissued, it receives a new OrderID, but contains the same Subject DN, cert expiration date and SANs. * Revocation: The GlobalSign CA performs revocation by OrderID. This revokes all certificates in the Order which could be hundreds for CloudSSL orders. CloudSSL is the only GlobalSign SSL product where multiple certificates are issued against the same OrderID. In general, CloudSSL customers need large multi-domain SSL certificates which have SANs added and removed to support their changing customer needs. As such, updating certificates is a more frequent activity that with any other GlobalSign SSL products. 2) Incapsula certificates issued with testslsslfeb20.me We investigated this order and determined that this domain was verified when the certificate was first issued on 3/31/2014. While this order was issued and subsequently updated and reissued a number of times without breaking the 39 month certificate data re-use period, it’s clear that based on this report the domain is no longer controlled by Incapsula. At the conclusion of this analysis we revoked two OrderIDs that contained this SAN which resulted in the revocation of 26 certificates with this SAN. All unexpired certificates with this SAN are now revoked as can be seen on the page: https://crt.sh/?dNSName=testslsslfeb20.me 3) Research to verify all domains are being validated every 39 months After this initial review, we further investigated the time between the initial SAN approval and inclusion of the SAN in future certificates. We found that not all SANs have been validated within the prior 39 months due to a product bug. CloudSSL was not updated in February 2015 when the 39 month certificate data re-use policy was added to the BRs, thus domains were being included in reissued certificates without having updated domain verification checks performed. This product was launched in late 2011, so some SANs had reached their 39 month limit in February 2015, and some of those continued to be included in certificates through March 2017. 4) Resolution As soon as this was discovered, the system was patched on 3/16 to prevent additional certificates from being issued with SANs not validated within the prior 39 months. 5) Follow-up tasks The reporting interface and capabilities of the CA system to identify and revoke the impacted certificates was inadequate to properly locate impacted customers and OrderIDs which we needed to process. While some of them were identified and revoked relatively quickly, it took several weeks to set up a new database and reporting infrastructure which could be used to load and then correlate all of the certificates and SANs with the SAN approval dates and then notify customers and perform the revocations. Several rounds of reporting uploads, reporting and customer revocation updates were needed to completely capture the list of non-compliant certificates and revoke them. In summary the following are the final statistics: * 7 customers * 79 OrderIDs had certificates revoked * 945 unique SANs were included in certificates where the domain was not verified within the prior 39 months. * 905 Certificates were issued containing one or more SANs that has not been verified within the prior 39 months. These SANs were either removed from future certificates or they were re-validated. We've been actively working with 17 customers on 146 Orders and about 4000 SANs which expired on April 22 in order to comply with the 825 day data reuse policy. Checks were put in place to prevent certificates from being issued that contain SANs not validated within the prior 825 days prior to April 20th effective date. 6) Future Mitigation plans While we've put checks in place
Re: Incident Report : GlobalSign certificates with ROCA Fingerprint
Here is the final incident report 1) How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, via a discussion in mozilla.dev.security.policy, or via a Bugzilla bug), and the time and date. We became aware of the issue on October 16th. 2) A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done. Timeline: 10/16: Became aware of the ROCA issue via a post to mdsp list 10/17: Created an internal ticket to run report of over all active certificates 10/18: The report showed there were 53 vulnerable SSL certificates. They are all from one customer and they are all under the ".apsch.by" domain. 10/18: Received link with a list of 35 GlobalSign issued SSL certificates, all of which were on our report, https://misissued.com/batch/28/ 10/19: Customer was contacted and we let them know about the issue. These are used within a Tolling system which, if revoked, would result in substantial disruption of commercial services. They immediately initiated process to get them replaced; however, due to the location of the devices and the need to generate the keys using a new process (which is not vulnerable), they need approximately 2 weeks to perform the replacement. They have firm plans to complete this by November 3rd. 11/3: By the end of the day, all 53 certificates will be revoked. By 10/28 we had requested and received recent certificates from our Trusted Root Customers (AT&T, Virginia tech and others) and verified that there were no vulnerable SSL certificates issued by them. 3) Whether your CA has stopped, or has not yet stopped, issuing TLS/SSL certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation. We're working on a fix to block issuance of further certificates with this vulnerability which we will have implemented no later than 11/10. In the mean time we run a report every few days to verify no new certificates were issued. To date, no new ROCA certificates have been issued. 4) A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued. The fingerprints of 53 certificates are included here. The first one was issued on 2/25/2016 and the last one on 9/28/2017 01bcd319e84e198694bb986b72ab0b277ee4c357cf9a3b362541f4cb74b36f6d 061229b59546d9d81be0ffcfc04d3d72fca3d81abf98df2bd24872c3aa4d258b 065a097016e51a358f8766abb51a90ad22833bc68f3af3365ecca072029d7fb4 06d5eb043ea45e5846ad4f0b04006f3631a7dd0ec73230cb22bead450951e51a 0f78122cc28cd99618ddbf89a0c9e35eb8b73e4b1bf411369b0bb88b8a0f81ce 1084fe1f6b84bd1ac932a1433a467e127b1dc8ec328cf4aeab12a50b1fbc4b5f 17ba6090b8ef681f139796d903f984ef86d7d1949777bfa8b584c962a449b58f 18df028017a78c292bc9b6a53fe9466a9f8fd2b9e21bb05ccfad235c389f94ca 1b3afa0bfee9a48aa95867a37721f44a5e54592746159865b380f73e05aee476 1e7d489215dad2f31ed8ab240969f516cf49d5ef42ad354cb20356d671c43a2c 1ea84a84819494d7c04fc5219f7f1f0b57850f82203fe2c00fff16124a1a38c5 29f1bfad08982fceb58aa840594f52fd59593c452ec252311544e34a7faf9aee 2e442de2a9d3829151c2263d8e0da84f39a9cc09215c856dfa6d1c56a5511f6f 3057b0a731c5d18186648ef859d46dc40e163a700fdc7c5e4729d7bf1b485c7d 32ebc9849ff889a8f37b145605dede7af0bf736890ccef7a59c3d513e4efe9dc 3a3050a78cd8da38e008278458d4cad95270875bcf00c4e73cb27f390d585824 3c535de462caebd35b5bad2362ee4877fc76fe753bb1a02fbceb0c34892eb220 3fd7be044d5c67e48c62b5c739c3184408c8ca6d02b39f48612c64d4f84b3b13 4312ca0e6ed629149b4540475b0cf7aecc6fe8e99a2d95e4246e506bf731ed8e 45e786cccd940d25cb4abc0ba9155784e2dc652df8e4dd8708fd9a23e32e96ec 4639cfb1fa26a4912d2291ee92d27417a30e0f8049ac6ff8370424bec785deff 4b95a396aeb84f0397db72682a497c07b2705edbfb9990330be2c83244205b10 554f921e7086f6a6847ff7400c15c69aeca0ed8a65413efceb6abd3811ee65fc 59e3fb3644ff108d18ca6c0ceda7da0ea3d28c69a51fe33d4cffc5ba8f712aac 5a31f164d9cbe2098357c5cda18718a8f1c72f7ffb93e52064b8dac44473b398 5d40407e1cc32e9f36a490c1593f1eec04bda4924aee02e3ead97454dc0e3ed0 7152f9f0662cf24dd3e575fe62e684d388ee7ae3ae69c7529c0e2d73e9ecf2e7 742a55a6be533b24a41100867648d848cc79a885a0da2c4259c051bfd8f8c64d 755ae52776fe485bdacb7731f2cca8497b7ffa3d0e50ba933a434988e5b8b8e4 7b9891b7f0e6e4b410c27e00b4372ce35795a3439a187397853fe9f789e817f7 7f7f16754b3f8548d691ccee64864bc020159720608d09c627b68b7bdef33546 9656ae85659c4ae3514c4b1a9a6e78d167c280f6df861cc270d516530f8823b7 9a7f721fd5a3c96ce91a23d61a7abccc20cbc2260bd74ddbd643ef9aa672b79d a096d3ec93b81750d101e612e8569064a525d0c0890208bd8a10105f4f220b38 a441dcc2a2224e8cd4d1d4eaad7297cbdfc0a7bca3942783a8bb8a6c7f3d7ed3 ab4c44eb79ee0d898a78cf02d2346e41b5ff130b04c14feaef87c843acf8bace ad6d92f5f8fec8786089
Re: .tg Certificates Issued by Let's Encrypt
On Monday, November 6, 2017 at 6:40:58 AM UTC-5, Ben Laurie wrote: > On 4 November 2017 at 19:54, Kathleen Wilson via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On 11/4/17 5:36 AM, Daniel Cater wrote: > > > > I think those CAs need to re-validate their recently issued SSL certs that > > contain any *.tg domains, and possibly revoke such certs and send us the > > info so corresponding entries can be added to OneCRL. But, as this is new > > to me, I will appreciate thoughtful and constructive input in this. > > > Since CT is not (yet) compulsory, it seems you probably have to contact all > CAs, doesn't it? Do we believe that this issue has been resolved by the Registry and issuance an resume as normal, or are there ongoing concerns which CAs should be aware of when issuing certificates to .tg domains? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Anomalous Certificate Issuances based on historic CAA records
Hi Quirin, I'm curious about how you recorded the historical information from DNS, can you explain how this was requested and logged? We logged the data used for issuance of the GlobalSign certificate at the time of issuance and it's different from what you recorded. We logged that there was no “issuewild” entry and that "digicert.com", "globalsign.com", "letsencrypt.org" and "rapidssl.com" are all defined as “issue” at time of issuance. Doug On Friday, November 24, 2017 at 7:23:25 AM UTC-5, Gervase Markham wrote: > Hi Quirin, > > Thank you for your work on this topic. I would be grateful if you could > file Bugzilla bugs in the Misissuance component as follows, giving your > evidence of misissuance: > > On 22/11/17 23:50, Quirin Scheitle wrote: > > 1) Mix of wildcard and non-wildcard DNS names in SAN > > Batch: https://misissued.com/batch/32/ > > Description: best confer > > https://groups.google.com/d/msg/mozilla.dev.security.policy/O9HZPMvHMY8/HtXR8S-1AAAJ > > One bug per CA, please. > > > 4) Apparent non-evaluation of CAA records > > Batch: https://misissued.com/batch/33/ > > Description: These cases appear as pretty straight-forward that they > > should not have been issued, but > > there might be good explanations > > One bug for the two Comodo certs, one for the Camerfirma cert. > > Thank you, > > Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
