Test website monitor

101 views
Skip to first unread message

Rob Stradling

unread,
Dec 13, 2018, 6:18:19 AM12/13/18
to dev-secur...@lists.mozilla.org, crt.sh, Kathleen Wilson
Thanks to Kathleen for suggesting/requesting this new crt.sh feature...

To facilitate compliance checking for the 3 test websites that BR 2.2
[1] requires for each root certificate, I've created this new report:

https://crt.sh/test-websites

Anything in red on this page represents either: a
misconfigured/non-compliant test website, a bug in my code, or an
interesting edge case worthy of further discussion.

Each test website is currently rechecked every 10 minutes. The code for
the checker application is available at [2].


[1] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.9.pdf
"2.2. PUBLICATION OF INFORMATION
...
The CA SHALL host test Web pages that allow Application Software
Suppliers to test their software with Subscriber Certificates that chain
up to each publicly trusted Root Certificate. At a minimum, the CA SHALL
host separate Web pages using Subscriber Certificates that are (i)
valid, (ii) revoked, and (iii) expired."

[2] https://github.com/crtsh/test_websites_monitor

--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

Rufus Buschart

unread,
Dec 13, 2018, 7:26:32 AM12/13/18
to r...@sectigo.com, dev-secur...@lists.mozilla.org, cr...@googlegroups.com, kwi...@mozilla.com
Very nice! Are you sure, that this requirement is only valid for "Root CAs"? I was always under the impression, that such a test web site needs to be hosted for every "Issuing CA that chains up to a publicly trusted Root CA".

/Rufus

What we do in life, echoes in eternity.
===========================================
Rufus J.W. Buschart
Anna-Pirson-Weg 1c
91052 Erlangen
Phone: +49 (0)9131 - 530 15 85
Mobile: +49 (0)152 - 228 94 134


--
You received this message because you are subscribed to the Google Groups "crt.sh" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crtsh+un...@googlegroups.com.
To post to this group, send an email to cr...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/crtsh/2615a68e-9626-8d77-86f4-78dd64c04b3d%40sectigo.com.
For more options, visit https://groups.google.com/d/optout.

Rob Stradling

unread,
Dec 13, 2018, 7:30:27 AM12/13/18
to Rufus Buschart, dev-secur...@lists.mozilla.org, cr...@googlegroups.com, kwi...@mozilla.com
Hi Rufus. I'm not aware of any root program or CABForum requirement
that supports your interpretation.

On 13/12/2018 12:26, Rufus Buschart wrote:
> Very nice! Are you sure, that this requirement is only valid for "Root
> CAs"? I was always under the impression, that such a test web site needs
> to be hosted for every "Issuing CA that chains up to a publicly trusted
> Root CA".
>
> /Rufus
>
> What we do in life, echoes in eternity.
> ===========================================
> Rufus J.W. Buschart
> Anna-Pirson-Weg 1c
> 91052 Erlangen
> Phone: +49 (0)9131 - 530 15 85
> Mobile: +49 (0)152 - 228 94 134
> Web: http://www.buschart.de
>
>
> Am Do., 13. Dez. 2018 um 12:18 Uhr schrieb Rob Stradling
> <r...@sectigo.com <mailto:r...@sectigo.com>>:
> <mailto:crtsh%2Bunsu...@googlegroups.com>.
> To post to this group, send an email to cr...@googlegroups.com
> <mailto:cr...@googlegroups.com>.
> --
> You received this message because you are subscribed to the Google
> Groups "crt.sh" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to crtsh+un...@googlegroups.com
> <mailto:crtsh+un...@googlegroups.com>.
> To post to this group, send email to cr...@googlegroups.com
> <mailto:cr...@googlegroups.com>.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/crtsh/CAFnsKvjnAT6RZohgQNUEi5%3Dzxp-qDGxCi_K5jKOjwpvA%3DPZQAA%40mail.gmail.com
> <https://groups.google.com/d/msgid/crtsh/CAFnsKvjnAT6RZohgQNUEi5%3Dzxp-qDGxCi_K5jKOjwpvA%3DPZQAA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

--
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally
privileged, confidential, or proprietary information. If you are not the
intended recipient, you are not permitted to use, copy, or forward it,
in whole or in part without the express consent of the sender. Please
notify the sender by reply email, disregard the foregoing messages, and
delete it immediately.

Rob Stradling

unread,
Dec 13, 2018, 7:42:03 AM12/13/18
to Peter Miškovič, crt.sh, Kathleen Wilson
Hi Peter.

Kathleen is also interested in roots that are not currently trusted but
that are being evaluated for inclusion in root programs. Therefore,
https://crt.sh/test-websites shows all root certificates that are
currently recorded on the CCADB.

If you want to show only those roots that are trusted by a particular
root program, you can change the "Trusted by" selection at the top of
the page and then click "Update".

On 13/12/2018 12:26, Peter Miškovič wrote:
> Hi Rob,
> if you are quoted CAB forum Base Requirements:
>
> [1] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.9.pdf
> "2.2. PUBLICATION OF INFORMATION
> ...
> The CA SHALL host test Web pages that allow Application Software
> Suppliers to test their software with Subscriber Certificates that chain
> up to each publicly trusted Root Certificate. At a minimum, the CA SHALL
> host separate Web pages using Subscriber Certificates that are (i)
> valid, (ii) revoked, and (iii) expired."
>
> it would be fine to have in your compliance checking report only the roots which currently are part of the root programs.
> For example for the our company Disig, a.s. - roots "CA Disig" and "CA Disig Root R1" are no more in the root programs.
> Only "CA Disig Root R2" is.
>
> Thanks.
>
> Regards
> Peter Miskovic
>
> ---------------------------------
> Peter Miskovic
> CA Chief Operating Officer
>
> Disig, a.s.
> Zahradnicka 151, 821 08 Bratislava 2, Slovakia
>
> phone  +421 2 208 50 150
> cell phone +421 905 960 345
> peter.m...@disig.sk
> www.disig.sk

Rufus Buschart

unread,
Dec 13, 2018, 7:54:51 AM12/13/18
to r...@sectigo.com, cr...@googlegroups.com, kwi...@mozilla.com
Well, it seemed to be obvious to me, because there might be also a problem with one of the Issuing CAs / Intermediate CAs in the chain between the Root and the Subscriber Certificate. We at Siemens host test web sites for every single issuing CA operated by us: https://catestsite.siemens.com/

But if the requirement is not as strict as we understood it, that's fine for me too. I rather like to err to the safe side than to have a bug on MDSP list....

/Rufus

What we do in life, echoes in eternity.
===========================================
Rufus J.W. Buschart
Anna-Pirson-Weg 1c
91052 Erlangen
Phone: +49 (0)9131 - 530 15 85
Mobile: +49 (0)152 - 228 94 134

Wayne Thayer

unread,
Dec 13, 2018, 2:05:58 PM12/13/18
to ru...@buschart.de, Rob Stradling, cr...@googlegroups.com, Kathleen Wilson
Thank you Rob, this is terrific!

I would like to ask that all CAs to take a look at this report and correct any issues that are found with their test websites.

The report is flagging a number of sites as "Not HTML", which means that they are serving some content type other than text/html. While I think that Rob has correctly interpreted the meaning of "test website", Kathleen and I are not currently planning to categorize this as a policy violation. However, it would still be appreciated if CAs help to clean up the report by serving HTML on their test websites.

On Thu, Dec 13, 2018 at 5:54 AM Rufus Buschart <ru...@buschart.de> wrote:
Well, it seemed to be obvious to me, because there might be also a problem with one of the Issuing CAs / Intermediate CAs in the chain between the Root and the Subscriber Certificate. We at Siemens host test web sites for every single issuing CA operated by us: https://catestsite.siemens.com/

It is always good to hear when a CA does things because they make sense, not just to meet the minimum requirement.

But if the requirement is not as strict as we understood it, that's fine for me too. I rather like to err to the safe side than to have a bug on MDSP list....

The requirement is not as strict as you understood it, but it is only a minimum requirement. Mozilla is most concerned with the roots we're shipping, so the current requirement is satisfactory for us.

Rob Stradling

unread,
Dec 14, 2018, 5:27:46 AM12/14/18
to Wayne Thayer, ru...@buschart.de, cr...@googlegroups.com, Kathleen Wilson
On 13/12/2018 19:05, Wayne Thayer wrote:
> Thank you Rob, this is terrific!

Thanks Wayne.

> I would like to ask that all CAs to take a look at this report and
> correct any issues that are found with their test websites.

I just noticed that m.d.s.p was dropped from this sub-thread before you
wrote that, so you probably didn't reach much of your target audience.
(I would forward your message to m.d.s.p, but it's probably better if it
comes directly from you).

> The report is flagging a number of sites as "Not HTML", which means that
> they are serving some content type other than text/html.

Currently text/html and text/xml are permitted.

Webpages are "usually written in HTML or a comparable markup
language...and...Typical web pages provide hypertext that includes a
navigation bar or a sidebar menu linking to other web pages via
hyperlinks, often referred to as links"
(https://en.wikipedia.org/wiki/Web_page).

Most of the "Not HTML" errors are due to the response being classified
as text/plain, which clearly isn't a markup language and so it doesn't
contain hyperlinks.

> While I think that Rob has correctly interpreted the meaning of "test > website", Kathleen and I are not currently planning to categorize
this> as a policy violation.

That seems reasonable. The report only shows "Not HTML" when there are
no other issues.

Wayne Thayer

unread,
Dec 14, 2018, 11:00:38 AM12/14/18
to mozilla-dev-security-policy, ru...@buschart.de, cr...@googlegroups.com, Kathleen Wilson, Rob Stradling
Adding mozilla.dev.security.policy back to this thread per Rob's suggestion:
Reply all
Reply to author
Forward
0 new messages