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 <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 <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 <dev-security-policy-boun...@lists.mozilla.org>
> 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 <ha...@hboeck.de>
> Cc: r...@sleevi.com <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 <ha...@hboeck.de> wrote:
>
> > Hi,
> >
> > On Fri, 22 May 2020 09:55:22 -0400
> > Ryan Sleevi via dev-security-policy
> > <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
> 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

Reply via email to