Re: crt.sh: CA Issuers monitor (was Re: CA Issuer AIA URL content types)
I've just added a "Configure for WebPKI" shortcut to the "Trust Filter", which simply links to https://crt.sh/ca-issuers?webpki. (Ditto for https://crt.sh/ocsp-responders?webpki). From: dev-security-policy on behalf of Jeremy Rowley via dev-security-policy Sent: 17 June 2020 23:13 To: r...@sleevi.com Cc: Mozilla Subject: Re: crt.sh: CA Issuers monitor (was Re: CA Issuer AIA URL content types) CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Doh - how did I miss that?! Thanks Ryan From: Ryan Sleevi Sent: Wednesday, June 17, 2020 4:11:46 PM To: Jeremy Rowley Cc: Mozilla Subject: Re: crt.sh: CA Issuers monitor (was Re: CA Issuer AIA URL content types) It's right there under "Trust Filter" . Very top of the page ;) e.g. https://crt.sh/ca-issuers?trustedExclude=expired%2Conecrl&trustedBy=Mozilla&trustedFor=Server+Authentication&dir=v&sort=2&rootOwner=&url=&content=&contentType= On Wed, Jun 17, 2020 at 5:18 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: Is there a way to filter out the revoked and non-TLS/SMIME ICAs? -Original Message- From: dev-security-policy mailto:dev-security-policy-boun...@lists.mozilla.org>> On Behalf Of Rob Stradling via dev-security-policy Sent: Wednesday, June 17, 2020 5:07 AM To: dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> Subject: crt.sh: CA Issuers monitor (was Re: CA Issuer AIA URL content types) Inspired by last month's email threads and Bugzilla issues relating to CA Issuers misconfigurations, I've just finished adding a new feature to crt.sh... https://crt.sh/ca-issuers Sadly, this highlights plenty of misconfigurations and other problems: PEM instead of DER, certs for the wrong CAs, wrong Content-Types, 404s, non-existent domain names, connection timeouts. I encourage CAs to take a look and see what they can fix. (Also, comments welcome :-) ). While I'm here, here's a quick reminder of some other crt.sh features relating to CA compliance issues: https://crt.sh/ocsp-responders https://crt.sh/test-websites https://crt.sh/mozilla-disclosures From: dev-security-policy mailto:dev-security-policy-boun...@lists.mozilla.org>> on behalf of Ryan Sleevi via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> Sent: 22 May 2020 21:52 To: Hanno Böck mailto:ha...@hboeck.de>> Cc: r...@sleevi.com<mailto:r...@sleevi.com> mailto:r...@sleevi.com>>; dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org> mailto:dev-security-policy@lists.mozilla.org>> Subject: Re: CA Issuer AIA URL content types CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I believe you've still implied, even in this reply, that this is something serious or important. I see no reason to believe that is the case, and I wasn't sure if there was anything more than a "Here's a SHOULD and here's people not doing it," which doesn't seem that useful to me. On Fri, May 22, 2020 at 2:52 PM Hanno Böck mailto:ha...@hboeck.de>> wrote: > Hi, > > On Fri, 22 May 2020 09:55:22 -0400 > Ryan Sleevi via dev-security-policy > mailto:dev-security-policy@lists.mozilla.org>> > wrote: > > > Could you please cite more specifically what you believe is wrong > > here? This is only a SHOULD level requirement. > > I think I said that more or less: > > > > I'm not going to file individual reports for the CAs. Based on > > > previous threads I don't believe these are strictly speaking rule > > > violations. > > I'm not claiming this is a severe issue or anything people should be > worried about. > It's merely that while analyzing some stuff I observed that AIA fields > aren't as reliable as one might want (see also previous mails) and the > mime types are one more observation I made where things aren't what > they probably SHOULD be. > I thought I'd share this observation with the community. > > -- > Hanno Böck > https://hboeck.de/ > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org<mailto: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<mailto:dev-security-policy@lists.mozil
Re: crt.sh: CA Issuers monitor (was Re: CA Issuer AIA URL content types)
Doh - how did I miss that?! Thanks Ryan From: Ryan Sleevi Sent: Wednesday, June 17, 2020 4:11:46 PM To: Jeremy Rowley Cc: Mozilla Subject: Re: crt.sh: CA Issuers monitor (was Re: CA Issuer AIA URL content types) It's right there under "Trust Filter" . Very top of the page ;) e.g. https://crt.sh/ca-issuers?trustedExclude=expired%2Conecrl&trustedBy=Mozilla&trustedFor=Server+Authentication&dir=v&sort=2&rootOwner=&url=&content=&contentType= On Wed, Jun 17, 2020 at 5:18 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: Is there a way to filter out the revoked and non-TLS/SMIME ICAs? -Original Message- From: dev-security-policy mailto:dev-security-policy-boun...@lists.mozilla.org>> On Behalf Of Rob Stradling via dev-security-policy Sent: Wednesday, June 17, 2020 5:07 AM To: dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> Subject: crt.sh: CA Issuers monitor (was Re: CA Issuer AIA URL content types) Inspired by last month's email threads and Bugzilla issues relating to CA Issuers misconfigurations, I've just finished adding a new feature to crt.sh... https://crt.sh/ca-issuers Sadly, this highlights plenty of misconfigurations and other problems: PEM instead of DER, certs for the wrong CAs, wrong Content-Types, 404s, non-existent domain names, connection timeouts. I encourage CAs to take a look and see what they can fix. (Also, comments welcome :-) ). While I'm here, here's a quick reminder of some other crt.sh features relating to CA compliance issues: https://crt.sh/ocsp-responders https://crt.sh/test-websites https://crt.sh/mozilla-disclosures From: dev-security-policy mailto:dev-security-policy-boun...@lists.mozilla.org>> on behalf of Ryan Sleevi via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> Sent: 22 May 2020 21:52 To: Hanno Böck mailto:ha...@hboeck.de>> Cc: r...@sleevi.com<mailto:r...@sleevi.com> mailto:r...@sleevi.com>>; dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org> mailto:dev-security-policy@lists.mozilla.org>> Subject: Re: CA Issuer AIA URL content types CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I believe you've still implied, even in this reply, that this is something serious or important. I see no reason to believe that is the case, and I wasn't sure if there was anything more than a "Here's a SHOULD and here's people not doing it," which doesn't seem that useful to me. On Fri, May 22, 2020 at 2:52 PM Hanno Böck mailto:ha...@hboeck.de>> wrote: > Hi, > > On Fri, 22 May 2020 09:55:22 -0400 > Ryan Sleevi via dev-security-policy > mailto:dev-security-policy@lists.mozilla.org>> > wrote: > > > Could you please cite more specifically what you believe is wrong > > here? This is only a SHOULD level requirement. > > I think I said that more or less: > > > > I'm not going to file individual reports for the CAs. Based on > > > previous threads I don't believe these are strictly speaking rule > > > violations. > > I'm not claiming this is a severe issue or anything people should be > worried about. > It's merely that while analyzing some stuff I observed that AIA fields > aren't as reliable as one might want (see also previous mails) and the > mime types are one more observation I made where things aren't what > they probably SHOULD be. > I thought I'd share this observation with the community. > > -- > Hanno Böck > https://hboeck.de/ > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org<mailto: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<mailto: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<mailto: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: crt.sh: CA Issuers monitor (was Re: CA Issuer AIA URL content types)
It's right there under "Trust Filter" . Very top of the page ;) e.g. https://crt.sh/ca-issuers?trustedExclude=expired%2Conecrl&trustedBy=Mozilla&trustedFor=Server+Authentication&dir=v&sort=2&rootOwner=&url=&content=&contentType= On Wed, Jun 17, 2020 at 5:18 PM Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Is there a way to filter out the revoked and non-TLS/SMIME ICAs? > > -Original Message- > From: dev-security-policy > On Behalf Of Rob Stradling via dev-security-policy > Sent: Wednesday, June 17, 2020 5:07 AM > To: dev-security-policy > Subject: crt.sh: CA Issuers monitor (was Re: CA Issuer AIA URL content > types) > > Inspired by last month's email threads and Bugzilla issues relating to CA > Issuers misconfigurations, I've just finished adding a new feature to > crt.sh... > > https://crt.sh/ca-issuers > > Sadly, this highlights plenty of misconfigurations and other problems: PEM > instead of DER, certs for the wrong CAs, wrong Content-Types, 404s, > non-existent domain names, connection timeouts. I encourage CAs to take a > look and see what they can fix. (Also, comments welcome :-) ). > > While I'm here, here's a quick reminder of some other crt.sh features > relating to CA compliance issues: > https://crt.sh/ocsp-responders > https://crt.sh/test-websites > https://crt.sh/mozilla-disclosures > > > From: dev-security-policy > on behalf of Ryan Sleevi via dev-security-policy < > dev-security-policy@lists.mozilla.org> > Sent: 22 May 2020 21:52 > To: Hanno Böck > Cc: r...@sleevi.com ; > dev-security-policy@lists.mozilla.org < > dev-security-policy@lists.mozilla.org> > Subject: Re: CA Issuer AIA URL content types > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you recognize the sender and know > the content is safe. > > > I believe you've still implied, even in this reply, that this is something > serious or important. I see no reason to believe that is the case, and I > wasn't sure if there was anything more than a "Here's a SHOULD and here's > people not doing it," which doesn't seem that useful to me. > > On Fri, May 22, 2020 at 2:52 PM Hanno Böck wrote: > > > Hi, > > > > On Fri, 22 May 2020 09:55:22 -0400 > > Ryan Sleevi via dev-security-policy > > wrote: > > > > > Could you please cite more specifically what you believe is wrong > > > here? This is only a SHOULD level requirement. > > > > I think I said that more or less: > > > > > > I'm not going to file individual reports for the CAs. Based on > > > > previous threads I don't believe these are strictly speaking rule > > > > violations. > > > > I'm not claiming this is a severe issue or anything people should be > > worried about. > > It's merely that while analyzing some stuff I observed that AIA fields > > aren't as reliable as one might want (see also previous mails) and the > > mime types are one more observation I made where things aren't what > > they probably SHOULD be. > > I thought I'd share this observation with the community. > > > > -- > > Hanno Böck > > https://hboeck.de/ > > > ___ > 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 > > ___ > 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: crt.sh: CA Issuers monitor (was Re: CA Issuer AIA URL content types)
Is there a way to filter out the revoked and non-TLS/SMIME ICAs? -Original Message- From: dev-security-policy On Behalf Of Rob Stradling via dev-security-policy Sent: Wednesday, June 17, 2020 5:07 AM To: dev-security-policy Subject: crt.sh: CA Issuers monitor (was Re: CA Issuer AIA URL content types) Inspired by last month's email threads and Bugzilla issues relating to CA Issuers misconfigurations, I've just finished adding a new feature to crt.sh... https://crt.sh/ca-issuers Sadly, this highlights plenty of misconfigurations and other problems: PEM instead of DER, certs for the wrong CAs, wrong Content-Types, 404s, non-existent domain names, connection timeouts. I encourage CAs to take a look and see what they can fix. (Also, comments welcome :-) ). While I'm here, here's a quick reminder of some other crt.sh features relating to CA compliance issues: https://crt.sh/ocsp-responders https://crt.sh/test-websites https://crt.sh/mozilla-disclosures From: dev-security-policy on behalf of Ryan Sleevi via dev-security-policy Sent: 22 May 2020 21:52 To: Hanno Böck Cc: r...@sleevi.com ; dev-security-policy@lists.mozilla.org Subject: Re: CA Issuer AIA URL content types CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I believe you've still implied, even in this reply, that this is something serious or important. I see no reason to believe that is the case, and I wasn't sure if there was anything more than a "Here's a SHOULD and here's people not doing it," which doesn't seem that useful to me. On Fri, May 22, 2020 at 2:52 PM Hanno Böck wrote: > Hi, > > On Fri, 22 May 2020 09:55:22 -0400 > Ryan Sleevi via dev-security-policy > wrote: > > > Could you please cite more specifically what you believe is wrong > > here? This is only a SHOULD level requirement. > > I think I said that more or less: > > > > I'm not going to file individual reports for the CAs. Based on > > > previous threads I don't believe these are strictly speaking rule > > > violations. > > I'm not claiming this is a severe issue or anything people should be > worried about. > It's merely that while analyzing some stuff I observed that AIA fields > aren't as reliable as one might want (see also previous mails) and the > mime types are one more observation I made where things aren't what > they probably SHOULD be. > I thought I'd share this observation with the community. > > -- > Hanno Böck > https://hboeck.de/ > ___ 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
crt.sh: CA Issuers monitor (was Re: CA Issuer AIA URL content types)
Inspired by last month's email threads and Bugzilla issues relating to CA Issuers misconfigurations, I've just finished adding a new feature to crt.sh... https://crt.sh/ca-issuers Sadly, this highlights plenty of misconfigurations and other problems: PEM instead of DER, certs for the wrong CAs, wrong Content-Types, 404s, non-existent domain names, connection timeouts. I encourage CAs to take a look and see what they can fix. (Also, comments welcome :-) ). While I'm here, here's a quick reminder of some other crt.sh features relating to CA compliance issues: https://crt.sh/ocsp-responders https://crt.sh/test-websites https://crt.sh/mozilla-disclosures From: dev-security-policy on behalf of Ryan Sleevi via dev-security-policy Sent: 22 May 2020 21:52 To: Hanno Böck Cc: r...@sleevi.com ; dev-security-policy@lists.mozilla.org Subject: Re: CA Issuer AIA URL content types CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. I believe you’ve still implied, even in this reply, that this is something serious or important. I see no reason to believe that is the case, and I wasn’t sure if there was anything more than a “Here’s a SHOULD and here’s people not doing it,” which doesn’t seem that useful to me. On Fri, May 22, 2020 at 2:52 PM Hanno Böck wrote: > Hi, > > On Fri, 22 May 2020 09:55:22 -0400 > Ryan Sleevi via dev-security-policy > wrote: > > > Could you please cite more specifically what you believe is wrong > > here? This is only a SHOULD level requirement. > > I think I said that more or less: > > > > I'm not going to file individual reports for the CAs. Based on > > > previous threads I don't believe these are strictly speaking rule > > > violations. > > I'm not claiming this is a severe issue or anything people should be > worried about. > It's merely that while analyzing some stuff I observed that AIA fields > aren't as reliable as one might want (see also previous mails) and the > mime types are one more observation I made where things aren't what they > probably SHOULD be. > I thought I'd share this observation with the community. > > -- > Hanno Böck > https://hboeck.de/ > ___ 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