Re: T-Systems invalid SANs
Hello Ryan, thanks for your reply. El lunes, 4 de marzo de 2019, 18:20:20 (UTC+1), Ryan Sleevi escribió: > > Just to make sure: This isn't really a question about CT at all, is it? > It's a question about CAs performing testing in production that leads to > misissuances. > Mostly is the second: I asked about the existence of good/recommended/approved practices for doing tests, that could have been discussed here in the past. > As with any system, care should be taken before doing testing in production. (...) I agree with you on all that... I just think that repeating pre-prod tests once in production, specially after big changes, is not an option but a must... And the more positively-encouraged are the CAs to make tests, even trying to break their own systems, by their own means or by hiring external hackers, the better for all. Sorry if this went off-topic. The fact that this problem occurred while a CA was doing tests raised my interest. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: T-Systems invalid SANs
On Mon, Mar 4, 2019 at 11:46 AM Pedro Fuentes via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > El lunes, 4 de marzo de 2019, 12:37:43 (UTC+1), arnold...@t-systems.com > escribió: > > The incident report can be found here, > https://bugzilla.mozilla.org/show_bug.cgi?id=1530718 > > Hello, > related to this... > > Is there a policy about test certificates and CT logs? > > Sometimes it's required to do "negative tests" to check our systems and it > can lead to a missisuance if a control fails, this typically would happen > for a test certificate that is issued for a domain owned by the CA and > revoked immediately after the test. > > It's clear that first thing is to test with a dev environment, but > sometimes it's required to do final validation tests in production, and, > let's agree, "sh*t happens" > > Now all these tests go public in the CT logs and are treated as any other > misissuance, and I don't know if it was discussed here in the past some > good practice for these test certificates and potential "controlled and > inoffensive" misissuances. Maybe a CA could disclose some "sandbox domain", > on which we can do tests without raising excessive concerns.. > Just to make sure: This isn't really a question about CT at all, is it? It's a question about CAs performing testing in production that leads to misissuances. As with any system, care should be taken before doing testing in production. If you're unable to test in a controlled environment, that likely reveals systemic flaws in how configuration deployment is managed. If "sh*t happens" in production, it's an incident, and it should be treated with the same degree of seriousness and urgency as one might expect, and I think any concerns would, by definition, not be excessive - because it reveals a real issue in production that could and should have been caught internaly beforehand. That's not to discourage testing, which I fear it might be seen as. I think CAs that do perform such tests are doing far better than CAs that do not, but if it results in misissuance, it's a misissuance all the same, and it's reasonable to be concerned and to understand. For example, incident reports would and should be expected to examine whether this was also tested on an internal system first, what and how the controls failed, and not just "The control that failed is being fixed" as a remediation, but how systemically the CA is improving their internal testing environment and production deployment to avoid divergence (and how that divergence happened in the first place). All of these things help the ecosystem improve, and don't seem unreasonable or onerous. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: T-Systems invalid SANs
El lunes, 4 de marzo de 2019, 12:37:43 (UTC+1), arnold...@t-systems.com escribió: > The incident report can be found here, > https://bugzilla.mozilla.org/show_bug.cgi?id=1530718 Hello, related to this... Is there a policy about test certificates and CT logs? Sometimes it's required to do "negative tests" to check our systems and it can lead to a missisuance if a control fails, this typically would happen for a test certificate that is issued for a domain owned by the CA and revoked immediately after the test. It's clear that first thing is to test with a dev environment, but sometimes it's required to do final validation tests in production, and, let's agree, "sh*t happens" Now all these tests go public in the CT logs and are treated as any other misissuance, and I don't know if it was discussed here in the past some good practice for these test certificates and potential "controlled and inoffensive" misissuances. Maybe a CA could disclose some "sandbox domain", on which we can do tests without raising excessive concerns.. Thanks! ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: T-Systems invalid SANs
The incident report can be found here, https://bugzilla.mozilla.org/show_bug.cgi?id=1530718 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: T-Systems invalid SANs
On 27/02/2019 09:54, michel.lebihan2...@gmail.com wrote: I also found that certificates that were issued very recently have duplicate SANs: https://crt.sh/?id=1231853308=cablint,x509lint,zlint https://crt.sh/?id=1226557113=cablint,x509lint,zlint https://crt.sh/?id=1225737388=cablint,x509lint,zlint Are duplicate SANs forbidden by any standard? (it's obviously wasteful, but RFC3280 seems to implicitly allow it). 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: T-Systems invalid SANs
I also found that certificates that were issued very recently have duplicate SANs: https://crt.sh/?id=1231853308=cablint,x509lint,zlint https://crt.sh/?id=1226557113=cablint,x509lint,zlint https://crt.sh/?id=1225737388=cablint,x509lint,zlint ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: T-Systems invalid SANs
Thank you. I have created a bug and requested a response from T-Systems: https://bugzilla.mozilla.org/show_bug.cgi?id=1530718 - Wayne On Tue, Feb 26, 2019 at 8:07 AM michel.lebihan2000--- via dev-security-policy wrote: > Hello, > > While looking at CT logs, I noticed multiple certificates issued by > T-Systems that have SANs that seem invalid. The first certificate I noticed > is https://crt.sh/?id=1044575692=ocsp,cablint,zlint The DNS name has > a leading /. That certificate was revoked, but I didn't see any report > about this on this list. Other certificates I noticed are > https://crt.sh/?id=1003197184=cablint,zlint where the CN has a > leading whitespace and the SAN is double. This one has also been revoked. > > Other certificates that seem mississued are: > https://crt.sh/?id=1044697381=cablint,zlint > https://crt.sh/?id=282646160=cablint,zlint > > They are all revoked. > ___ > 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
T-Systems invalid SANs
Hello, While looking at CT logs, I noticed multiple certificates issued by T-Systems that have SANs that seem invalid. The first certificate I noticed is https://crt.sh/?id=1044575692=ocsp,cablint,zlint The DNS name has a leading /. That certificate was revoked, but I didn't see any report about this on this list. Other certificates I noticed are https://crt.sh/?id=1003197184=cablint,zlint where the CN has a leading whitespace and the SAN is double. This one has also been revoked. Other certificates that seem mississued are: https://crt.sh/?id=1044697381=cablint,zlint https://crt.sh/?id=282646160=cablint,zlint They are all revoked. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
