Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)
On Wed, Mar 1, 2017 at 12:12 PM, douglas.beattie--- via dev-security-policy wrote: > 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, A few follow-ups: This description is somewhat concerning in its omission - namely, whether or not GlobalSign revalidates this information on the 39 month period required by the Baseline Requirements. Q1) Can you confirm that this system ensures that all domains are revalidated if the validation occurred more than 39 months prior, as per the Baseline Requirements, v1.4.2, Section 4.2.1 Q2) If, in the process of confirming a, deficiencies are noted in the enforcement of this, can you provide details as to how many certificates this issue might affect? The Baseline Requirements, v1.4.2, Section 9.6.3 details obligations with respect to the Subscriber Agreements that CAs SHALL require. As part of this, Item 5, (b) notes that the Subscriber Agreement includes "An obligation and warranty to: ... (b) promptly request revocation of the Certificate, and cease using it, if any information in the Certificate is or becomes incorrect or inaccurate." Per Section 4.9.1.1 of the Baseline Requirements, "The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs:" ... "The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use". Given that GlobalSign has acknowledged that the Subscriber has failed to abide by the required Subscriber Agreement, and given that GlobalSign acknowledged this at Tue, 28 Feb 2017 04:46:25 -0800 (PST), it would appear that this certificate is not revoked, however, my attempts at confirming with your OCSP server seem to at least produce issues on the several Windows devices I tried. Q3) Can you confirm that this certificate (and all related certificates) are revoked, as per Section 4.9.1.1 of the Baseline Requirements? Q4) Can you confirm that your OCSP responder is properly available? For your ease of diagnostic, the Windows command is "certutil -f -urlfetch -verify [certificatefile]", which other CAs' revoked and unrevoked certificates are working fine with. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On 2017-03-01T12:22:32-0800, "Martin Heaps via dev-security-policy" wrote: > On Tuesday, 28 February 2017 17:45:19 UTC, Santhan Raj wrote: > > > WebTrustfor Certification Authorities , SSL > > BaselinewithNetwork Security, Version 2.0,available > > at > > http://www.webtrust.org/homepage‐documents/item79806.pdf. > > 404 - File or directory not found. http://www.webtrust.org/homepage-documents/item79806.pdf The U+2010 in the link Santhan Raj posted should have been U+002D. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Misissued/Suspicious Symantec Certificates
On Tuesday, 28 February 2017 17:45:19 UTC, Santhan Raj wrote: > WebTrust for Certification Authorities , SSL > BaselinewithNetwork Security, Version 2.0,available > at > http://www.webtrust.org/homepage‐documents/item79806.pdf. 404 - File or directory not found. ___ 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: Intermediates Supporting Many EE Certs
On 01/03/2017 12:43, Gervase Markham wrote: On 13/02/17 12:23, Gervase Markham wrote: The GoDaddy situation raises an additional issue. What can be done about the potential future issue (which might happen with any large CA) of the need to untrust a popular intermediate? Suggestions welcome. Reviewing the discussion, I unfortunately don't see any workable solutions proposed yet. I think AIA chasing is a red herring. Jeremy's engagement on intermediate rotation was illuminating, but it seems to me that having multiple intermediates in play at the same time over an extended period is very likely not to solve the problem, because any issuance problem would cut across them all. If customers tend to renew annually, one could imagine a "January intermediate", "February intermediate" and so on, and one uses the former every January, etc. This might reduce the need for an intermediate change when an EE cert changes, as CA's tend to encourage ahead-of-time annual renewals, offering to add the leftover days to the validitiy period of the replacement certificate (this is presumably also the reason BR max validity periods are slightly more than a whole number of years, for example a 3 year certificate renewed 2½ month ahead of expiry would have a validity of 38.5 months, which is less than 39). I have sympathy for the view that in today's world changing intermediate does make the process a little more error prone. (Although it shouldn't, and that's a technology fail I hope can be addressed.) Then, if you have an issuance problem which persisted for a month but which has led to a situation where you can't trust anything off the intermediates used during those times, only 1/6th of your outstanding certs from that root are at risk of needing immediate change rather than all of them. I would say a lot could be improved if certificate issuance customer messages provided the *relevant* chains and their individual certificates directly and with human-friendly names, it would greatly reduce the confusion compared to the common practice of asking each EE to manually navigate disorganized support pages for individual certificates with semi-numerical names such as "Foo intermediate G3" For example the confirmation mail or individualized web page could be something like this: --- Begin example for an OV SSL cert validated by the Joe's certs RA --- Here is your new SSL/TLS certificate for www.example.com, example.com and static.example.com (serial number 1231231421432453255268924750932758934750): example_com_2017_03_17.cer (PEM format). Needed intermediary certificates to put on your server: All in one file (including your certificate): example_com_2017_03_17_with_chain.pem (PEM format as needed by most servers) Or example_com_2017_03_17_with_chain.p7 (PKCS#7 for Microsoft IIS, Exchange etc.) One at a time (These are included in the all-in-one files above except the ones marked with an X, which your server shouldn't send) NiceCA-via-JoeRA-SSL-Regular-March-2017.cer (PEM format) X NiceCA-SHA256RSA-Root-2016.cer (PEM format) NiceCA-SHA256RSA-Root-2016-cross-by-UserFirst.cer (PEM format) X UserFirst-ancient-root.cer (PEM format) --- End example --- 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: SHA1 root CA
On 01/03/17 10:36, benjaminp...@gmail.com wrote: > screenshot of the error message: http://imgur.com/a/BIQUm That error message will not occur if only the root CA is SHA-1 signed, because Firefox does not check the signatures on root CAs. There must be some other certificate in the chain that Firefox has built which is SHA-1 signed. You will need to provide the full certificate chain as constructed by Firefox. If you get the error by visiting the site, then click "Advanced" then "Add Exception" then "View" then the "Details" tab, then select all the certificates in the chain in turn and click Export, making sure you save them as PEM files, you can paste them into a message to this group. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Let's Encrypt appears to issue a certificate for a domain thatdoesn't exist
What you've stumbled into is the unspoken truth that CA's want to have their cake and eat it too. Specifically, they market themselves and their products under the umbrella of security: "You want to be secure on the Internet, right? We can help you do that!" Then, most all CA's will turn around and say: "Oh by the way, if you encounter a situation in which something bad happens it's not our fault because we couldn't possibly confirm that what we say is secure is in fact secure." Let's Encrypt is not unique as I think most CA's express this viewpoint in one form or another. This may be acceptable from a legal or compliance standpoint but not in terms of reputation. As people find themselves in bad situations because of a malicious site that used one of their certs, they very well might blame the CA. Certainly a CA does not want the reputation of being "the preferred cert vendor for malicious sites everywhere" so whatever principles they try to espouse, the reality will be more complicated. Original Message From: wuyi via dev-security-policy Sent: Friday, February 24, 2017 1:57 AM To: vtlynch; dev-security-policy Reply To: wuyi Subject: Re: Let's Encrypt appears to issue a certificate for a domain thatdoesn't exist Exactly that’s the meaning of “entitle”. Based on the interpretation, I understand that when a firefighter is on a vocation, even a fire breaks next to him, it’s of his choice to go hiking, fly kites whatever as he may only be entitled on weekdays rather than in a vocation. IMO, the point of the Let’s Encrypt’ CP 9.6.3 is to ensure that the CA has privilege to revoke certificate when certain issue happens as it describes. The deeper meaning of it is that it ensures the CA has ability to maintain online security anytime, but it’s enough. I am not going to debate here, I would rather go and teach my grandfather those green lock icons from some certain CA means anything but online security they states. Nio SZU 发自我的iPhone -- Original -- From: Vincent Lynch via dev-security-policy Date: Fri,Feb 24,2017 15:10 To: dev-security-policy , wuyi <594346...@qq.com> Subject: Re: Let's Encrypt appears to issue a certificate for a domain thatdoesn't exist As you have quoted it, Let's Encrpyt's CPS says: "the CA is *entitled* to revoke the certificate" The key word is "entitled." Meaning that Let's Encrypt may revoke the certificate if they chose, but are not required to. Therefore not revoking the certificate is compatible with their CPS. It's important to realize this is not an argument about what *should* be done or what we think is right, but what *can* be done under the current rules and regulations. The fact is that the CAB/F BR's are so (intentionally) ambiguous about "high risk" certificates that there is no real way meaning to that section and no real way for a CA to violate said section. As others have mentioned, please can we stop writing unrelated comments on this thread. This thread is about a specific report about a DV cert being issued to a non-existent domain. That report turned out to be false. Unless comments are about that report, this is the wrong thread to post in. I would also encourage anyone interested in the topic of high risk requests and certs being issued to phishing sites to see Eric Mill's comment in this thread. He has provided a link to past discussion on this topic, and I can promise you that however displeasing and shocking this practice may be, it has already been considered and debated. On Fri, Feb 24, 2017 at 12:36 AM wuyi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > According to what I’ve known, > > > “Acknowledgment and Acceptance: An acknowledgment and acceptance that the > CA is entitled to revoke the certificate immediately if the Applicant were > to violate the terms of the Subscriber or Terms of Use Agreement or if the > CA discovers that the Certificate is being used to enable criminal > activities such as phishing attacks, fraud, or the distribution of > malware.” (Let’s Encrypt’ CP 9.6.3) > > > > > Now that a phishing site has been detected with a valid certificate, but > no immediate action was taken on it. I don’t think that this is what a CA, > who states to “Support a more secure and privacy-respecting Web” is > supposed to do. > > > > > Quoted from Google’s Policy, “it would be no different than a firefighter > who was not responding to fires in which people died.” > > > It may be difficult to sort what types of domains are high risk, but when > a certificate was used in this way without being revoked, it was no > difference from the Google CP’s metaphor. As an Internet user I was > disappointed about that, and those in the LE’ CP above can be treated as > nonsense. > > > Nio > SZU > > > On Fri, Feb 24, 2017 at 01:12:38AM +, Richard Wang via > dev-security-policy wrote: > > > > >I am sure this site: https://www.microsoftonline.us.com/ is a ph
Re: Incapsula via GlobalSign issued[ing] a certificate for non-existing domain (testslsslfeb20.me)
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. 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: Intermediates Supporting Many EE Certs
On Wednesday, 1 March 2017 12:44:16 UTC+1, Gervase Markham wrote: > On 13/02/17 12:23, Gervase Markham wrote: > > The GoDaddy situation raises an additional issue. > > > What can be done about the potential future issue (which might happen > > with any large CA) of the need to untrust a popular intermediate? > > Suggestions welcome. > ... > If customers tend to renew annually, one could imagine a "January > intermediate", "February intermediate" and so on, and one uses the > former every January, etc. > ... Or a different intermediate each day? ;-) I guess what you really are looking for is being able to distrust a CA for a date range. Any requirement that doesn't produce that is probably not worth the effort. CU Hans ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Intermediates Supporting Many EE Certs
On 13/02/17 12:23, Gervase Markham wrote: > The GoDaddy situation raises an additional issue. > What can be done about the potential future issue (which might happen > with any large CA) of the need to untrust a popular intermediate? > Suggestions welcome. Reviewing the discussion, I unfortunately don't see any workable solutions proposed yet. I think AIA chasing is a red herring. Jeremy's engagement on intermediate rotation was illuminating, but it seems to me that having multiple intermediates in play at the same time over an extended period is very likely not to solve the problem, because any issuance problem would cut across them all. If customers tend to renew annually, one could imagine a "January intermediate", "February intermediate" and so on, and one uses the former every January, etc. This might reduce the need for an intermediate change when an EE cert changes, as I have sympathy for the view that in today's world changing intermediate does make the process a little more error prone. (Although it shouldn't, and that's a technology fail I hope can be addressed.) Then, if you have an issuance problem which persisted for a month but which has led to a situation where you can't trust anything off the intermediates used during those times, only 1/6th of your outstanding certs from that root are at risk of needing immediate change rather than all of them. I guess the question is: is it worth it? Are the chances of this proving useful in an actual scenario high enough compared to the cost and hassle of imposing such a scheme on all CAs? If we decide to dis-trust the intermediate under such a scheme, is the CA practically as stuffed as it would be if it had just used one intermediate? :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA1 root CA
On Wed, 1 Mar 2017 02:36:22 -0800 (PST) benjaminpill--- via dev-security-policy wrote: > when connecting to a webserver > > screenshot of the error message: http://imgur.com/a/BIQUm It would be helpful if you told us which webserver. The error message looks to me that it's web webpages certificate, not the root, that's signed with sha1. But I may be wrong, would have to check. Sometimes error messages are misleading and sometimes strange things happen when websites send all kinds of wrong certs within a chain. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA1 root CA
[2017-03-01 11:21] benjaminpill--- via dev-security-policy: > so why is Firefox complaining with this error message: > > SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED Check the about:config setting "security.pki.sha1_enforcement_level". Valid values currently range from 0 to 4, with the following meanings: > enum class SHA1Mode { > Allowed = 0, > Forbidden = 1, > // There used to be a policy that only allowed SHA1 for certificates > issued > // before 2016. This is no longer available. If a user has selected this > // policy in about:config, it now maps to Forbidden. > UsedToBeBefore2016ButNowIsForbidden = 2, > ImportedRoot = 3, > ImportedRootOrBefore2016 = 4, > }; Source: https://dxr.mozilla.org/mozilla-central/source/security/certverifier/CertVerifier.h#164 You'll probably want either value 3 or value 4. regards Pascal ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA1 root CA
Am Mittwoch, 1. März 2017 11:31:20 UTC+1 schrieb Hanno Böck: > On Wed, 1 Mar 2017 02:21:21 -0800 (PST) > benjaminpill--- via dev-security-policy > wrote: > > > so why is Firefox complaining with this error message: > > > > SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED > > Can you be more specific? Where are you seeing that error message? > > -- > Hanno Böck > https://hboeck.de/ > > mail/jabber: ha...@hboeck.de > GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 when connecting to a webserver screenshot of the error message: http://imgur.com/a/BIQUm ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA1 root CA
On Wed, 1 Mar 2017 02:21:21 -0800 (PST) benjaminpill--- via dev-security-policy wrote: > so why is Firefox complaining with this error message: > > SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED Can you be more specific? Where are you seeing that error message? -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA1 root CA
Am Mittwoch, 1. März 2017 11:18:48 UTC+1 schrieb Hanno Böck: > On Wed, 1 Mar 2017 00:44:54 -0800 (PST) > benjaminpill--- via dev-security-policy > wrote: > > > are root (Enterprise) CA certificates wich are based on SHA1 handled > > as untrusted by Firefox 51? The end certificate is sign using sha256 > > and trusted by a intermidiate ca wich uses also sha256. Only the root > > ca is based on sha1. Chrome and IE are not complaining about the root > > cert. > > The signatures on root certificates are mostly irrelevant, as they're > pure self-signatures that have no real meaning. I think they're > only there because the certificate format X.509 requires certificates to > have a signature on themselve. > > Therefore afaik it's generally considered okay if root certificates have > SHA1 signatures. You probably wouldn't create new ones with such > signatures, but there is no risk for the ecosystem in keeping existing > ones. > > -- > Hanno Böck > https://hboeck.de/ > > mail/jabber: ha...@hboeck.de > GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 so why is Firefox complaining with this error message: SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA1 root CA
On Wed, 1 Mar 2017 00:44:54 -0800 (PST) benjaminpill--- via dev-security-policy wrote: > are root (Enterprise) CA certificates wich are based on SHA1 handled > as untrusted by Firefox 51? The end certificate is sign using sha256 > and trusted by a intermidiate ca wich uses also sha256. Only the root > ca is based on sha1. Chrome and IE are not complaining about the root > cert. The signatures on root certificates are mostly irrelevant, as they're pure self-signatures that have no real meaning. I think they're only there because the certificate format X.509 requires certificates to have a signature on themselve. Therefore afaik it's generally considered okay if root certificates have SHA1 signatures. You probably wouldn't create new ones with such signatures, but there is no risk for the ecosystem in keeping existing ones. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
SHA1 root CA
Hello, are root (Enterprise) CA certificates wich are based on SHA1 handled as untrusted by Firefox 51? The end certificate is sign using sha256 and trusted by a intermidiate ca wich uses also sha256. Only the root ca is based on sha1. Chrome and IE are not complaining about the root cert. Thanks! ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy