Re: DigiCert-Symantec Announcement

[Peter Gutmann via dev-security-policy]

Peter Bowen  writes:

>Gerv's email was clear that sale to DigiCert will not impact the plan,
>saying: "any change of control of some or all of Symantec's roots would not
>be grounds for a renegotiation of these dates."
>
>So the sanctions are still intact.

Ah, I phrased my question a bit unclearly, what I meant was that the existing
certs, which now chain up to to-be-untrusted Symantec roots, can be moved
across to trusted DigiCert roots and continue as before.  I'm assuming that
was the intent of exercise, that it's business as usual, just the name has
changed.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert-Symantec Announcement

[Peter Bowen via dev-security-policy]

On Wed, Aug 2, 2017 at 8:10 PM, Peter Gutmann via dev-security-policy
 wrote:
> Jeremy Rowley via dev-security-policy  
> writes:
>
>>Today, DigiCert and Symantec announced that DigiCert is acquiring the
>>Symantec CA assets, including the infrastructure, personnel, roots, and
>>platforms.
>
> I realise this is a bit off-topic for the list but someone has to bring up the
> elephant in the room: How does this affect the Google vs. Symantec situation?
> Is it pure coincidence that Symantec now re-emerges as DigiCert, presumably
> avoiding the sanctions since now things will chain up to DigiCert roots?

Peter,

On topic for this list is Mozilla policy.  Gerv's email was clear that
sale to DigiCert will not impact the plan, saying: "any change of
control of some or all of Symantec's roots
would not be grounds for a renegotiation of these dates."

So the sanctions are still intact.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert-Symantec Announcement

[Peter Gutmann via dev-security-policy]

Jeremy Rowley via dev-security-policy  
writes:

>Today, DigiCert and Symantec announced that DigiCert is acquiring the
>Symantec CA assets, including the infrastructure, personnel, roots, and
>platforms.

I realise this is a bit off-topic for the list but someone has to bring up the
elephant in the room: How does this affect the Google vs. Symantec situation?
Is it pure coincidence that Symantec now re-emerges as DigiCert, presumably
avoiding the sanctions since now things will chain up to DigiCert roots?

Just curious here, this seems like a bit too much of a coincidence.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert-Symantec Announcement

[Jeremy Rowley via dev-security-policy]

 

 

* Will there be other players in Symantec's SubCA plan or is DigiCert the only 
one?

 

[DC] Only DigiCert.

 

* ‎Is DigiCert prepared (yet?) to commit to a "first day of issuance" under the 
SubCA plan? That is, when is the earliest date that members of the general 
public may purchase certs that chain up through the new "DigiCert SubCA" to any 
of the Symantec roots? I hope that, for issues that may arise under the new 
system, there is sufficient time to identify and resolve them prior to the 
2017-12-01 deadline.

 

[DC] Not yet. That’s an ongoing discussion.  



* I think the idea of a smart segregation plan for the roots and intermediates 
is a must-have. Such a plan should factor in the clientele who are using the 
different roots and the environments in which they operate. Given how important 
the "ubiquitous roots" are, I would hope to see community involvement and 
"sign-off", if you will.

 

[DC] Okay. We plan to update the community as things solidify.

 

* I think it's appropriate to re-think some of the deadlines, given that we're 
talking less about a carrots-and-sticks model and more of one based on smart 
decision-making, good risk management, and sticks.


[DC] I’ll leave that open to the community discussion, although anything sooner 
than the current deadlines might not have as satisfactory results as the 
current proposal.



Finally, when I went to read the DigiCert blog post, I noticed that John 
Merrill's link for the agreement announcement was a dud. I don't know why but I 
really don't care either. I think it serves as a reminder ‎that mistakes are 
going to be made during this process so it's best to make allowances for that 
in the plans going forward. That, and attention to detail is important.

 

[DC] Egg on my face there. Thanks for finding that.  We’re getting it updated.

 



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert-Symantec Announcement

[Peter Kurrasch via dev-security-policy]

  This certainly shakes things up! I've had my concerns that Symantec's plan was complicated and risky, but now I'm wondering if this new path will be somewhat simpler--yet even more risky? I'm not suggesting we shouldn't take this path but I am hoping we make smart, well-thought-out decisions along the way.Some thoughts:* Will there be other players in Symantec's SubCA plan or is DigiCert the only one?* ‎Is DigiCert prepared (yet?) to commit to a "first day of issuance" under the SubCA plan? That is, when is the earliest date that members of the general public may purchase certs that chain up through the new "DigiCert SubCA" to any of the Symantec roots? I hope that, for issues that may arise under the new system, there is sufficient time to identify and resolve them prior to the 2017-12-01 deadline.* I think the idea of a smart segregation plan for the roots and intermediates is a must-have. Such a plan should factor in the clientele who are using the different roots and the environments in which they operate. Given how important the "ubiquitous roots" are, I would hope to see community involvement and "sign-off", if you will.* I think it's appropriate to re-think some of the deadlines, given that we're talking less about a carrots-and-sticks model and more of one based on smart decision-making, good risk management, and sticks.Finally, when I went to read the DigiCert blog post, I noticed that John Merrill's link for the agreement announcement was a dud. I don't know why but I really don't care either. I think it serves as a reminder ‎that mistakes are going to be made during this process so it's best to make allowances for that in the plans going forward. That, and attention to detail is important.Thanks.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert-Symantec Announcement

[Peter Bowen via dev-security-policy]

On Wed, Aug 2, 2017 at 2:12 PM, Jeremy Rowley via dev-security-policy
 wrote:
> Today, DigiCert and Symantec announced that DigiCert is acquiring the
> Symantec CA assets, including the infrastructure, personnel, roots, and
> platforms.  At the same time, DigiCert signed a Sub CA agreement wherein we
> will validate and issue all Symantec certs as of Dec 1, 2017.  We are
> committed to meeting the Mozilla and Google plans in transitioning away from
> the Symantec infrastructure. The deal is expected to close near the end of
> the year, after which we will be solely responsible for operation of the CA.
> From there, we will migrate customers and systems as necessary to
> consolidate platforms and operations while continuing to run all issuance
> and validation through DigiCert.  We will post updates and plans to the
> community as things change and progress.
>
> Thanks a ton for any thoughts you offer.

Jeremy,

A while ago I put together a list of all the certificates that are or
were included in trust stores that were known to be owned by Symantec
or companies that Symantec acquired.  The list is in Google Sheets at
https://docs.google.com/spreadsheets/d/1piCTtgMz1Uf3SHXoNEFYZKAjKGPJdRDGFuGehdzcvo8/edit?usp=sharing

Can you confirm that DigiCert will be "solely responsible for
operation" of all of these CAs once the deal closes?

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom cross-signs disclosed by Certinomis

[Matt Palmer via dev-security-policy]

On Wed, Aug 02, 2017 at 06:38:44PM -0400, Jonathan Rudenberg via 
dev-security-policy wrote:
> I think the correct response is to add both intermediates to OneCRL
> immediately, especially given the historic issues with StartCom.

+1.  Also a strongly worded letter of "are you f%*king kidding me?!?" to
Certinomis.  Everyone even ephemerally involved in the WebPKI should know by
now that StartCom/WoSign are viewed with deep suspicion, and blithely
signing an intermediate for them is not a smart move.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom cross-signs disclosed by Certinomis

[Kathleen Wilson via dev-security-policy]

Jonathan, Thank you for bringing this to our attention.

I have filed two bugs...

1) https://bugzilla.mozilla.org/show_bug.cgi?id=1386891
Certinomis: Cross-signing of StartCom intermediate certs, and delay in 
reporting it in CCADB

2) https://bugzilla.mozilla.org/show_bug.cgi?id=1386894
Add "StartCom BR SSL ICA” and "StartCom EV SSL ICA” intermediate certs to OneCRL

We will look into this further, and will appreciate any further relevant 
information. 

I will also appreciate explanation from Certinomis and StartCom.

Thanks,
Kathleen

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert-Symantec Announcement

[Jeremy Rowley via dev-security-policy]

Hey Nick - I plan to include all relevant OIDs in the cert. I figured that
way relying parties understand the total risk associated with verification
of the certificate, even if they don't know exactly the methods tied to each
listed domain. If a method is eventually deemed less desirable (*cough*
domain authorization letters *cough*), then the entire cert would need to be
replaced anyway to reflect deprecation of that method.

Jeremy 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Nick Lamb via dev-security-policy
Sent: Wednesday, August 2, 2017 4:57 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert-Symantec Announcement

On the use of OIDs to signify the Blessed Method used for validation I
thought it can't hurt to mention the first obstacle for this idea which
occurred to me in respect of Let's Encrypt (and more generally any CA
importing ACME I think)

Suppose an applicant asks for www.example.com, images.example.com and
www.example.org. They demonstrate control over www.example.com using files
in .well-known/ (sorry I'm writing this on my phone in a hotel room, don't
have BR section numbers in front of me) but use DNS to show control over
www.example.org...

Which OID goes in this certificate? Both of them? There are arbitrarily more
complicated examples along these lines, all worth a bit of thought before
setting off I think.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert-Symantec Announcement

[Jeremy Rowley via dev-security-policy]

Thanks Kathleen. We already offer short-lived certs (anywhere from 8 hours
up), but they are not issued off a dedicated intermediate. It's a great
suggestion, and we'll add it to the DigiCert plan.

Jeremy 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Kathleen Wilson via dev-security-policy
Sent: Wednesday, August 2, 2017 4:07 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert-Symantec Announcement

On Wednesday, August 2, 2017 at 2:13:40 PM UTC-7, Jeremy Rowley wrote:
> Today, DigiCert and Symantec announced that DigiCert is acquiring the 
> Symantec CA assets, including the infrastructure, personnel, roots, 
> and platforms.  At the same time, DigiCert signed a Sub CA agreement 
> wherein we will validate and issue all Symantec certs as of Dec 1, 2017.


Thanks for posting this information here.

Pointer to DigiCert's blog:

https://www.digicert.com/blog/digicert-to-acquire-symantec-website-security-
business/



> Two things I can say we plan on doing (following closing) to address 
> concerns are:
> 
> a.We plan to segregate certs by type on each root. Going forward, we
> will issue all SSL certs from a root while client and email come from 
> different roots.


I would like to see all CAs move in this direction.


> We also plan on limiting the number of organizations on each issuing 
> CA.  We hope this will help address the "too big to fail" issue seen 
> with Symantec.  By segregating end entities into roots and sub CAs, 
> the browsers can add affected Sub CAs to their CRL lists quickly and 
> without impacting the entire ecosystem.  This plan is very much in 
> flux, and we'd love to hear additional recommendations.


I greatly appreciate your consideration in this area!

Perhaps there can be different subCAs for large organizations versus
smaller/individual site operators (that might be covered as different
brands). Of course, I'm always in favor of technically-constrained subCAs
for the large organizations.

And perhaps one (or more) of the subCAs can be dedicated to short-lived SSL
certs, similar to Let's Encrypt?


> b.Another thing we are doing is adding a validation OID to all of our
> certificates that identifies which of the BR methods were used to 
> issue the cert. This way the entire community can readily identify 
> which method was used when issuing a cert and take action if a method 
> is deemed weak or insufficient.  We think this is a huge improvement 
> over the existing landscape, and I'm very excited to see that OID rolled
out.

I would like to see all CAs move in this direction as well.


Looks like you are going to be very busy! :-)

Thanks, and good luck!

Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert-Symantec Announcement

[Kathleen Wilson via dev-security-policy]

On Wednesday, August 2, 2017 at 2:13:40 PM UTC-7, Jeremy Rowley wrote:
> Today, DigiCert and Symantec announced that DigiCert is acquiring the
> Symantec CA assets, including the infrastructure, personnel, roots, and
> platforms.  At the same time, DigiCert signed a Sub CA agreement wherein we
> will validate and issue all Symantec certs as of Dec 1, 2017. 


Thanks for posting this information here.

Pointer to DigiCert's blog:

https://www.digicert.com/blog/digicert-to-acquire-symantec-website-security-business/



> Two things I can say we plan on doing (following closing) to address
> concerns are:
> 
> a.We plan to segregate certs by type on each root. Going forward, we
> will issue all SSL certs from a root while client and email come from
> different roots. 


I would like to see all CAs move in this direction.


> We also plan on limiting the number of organizations on
> each issuing CA.  We hope this will help address the "too big to fail" issue
> seen with Symantec.  By segregating end entities into roots and sub CAs, the
> browsers can add affected Sub CAs to their CRL lists quickly and without
> impacting the entire ecosystem.  This plan is very much in flux, and we'd
> love to hear additional recommendations. 


I greatly appreciate your consideration in this area!

Perhaps there can be different subCAs for large organizations versus 
smaller/individual site operators (that might be covered as different brands). 
Of course, I'm always in favor of technically-constrained subCAs for the large 
organizations.

And perhaps one (or more) of the subCAs can be dedicated to short-lived SSL 
certs, similar to Let's Encrypt?


> b.Another thing we are doing is adding a validation OID to all of our
> certificates that identifies which of the BR methods were used to issue the
> cert. This way the entire community can readily identify which method was
> used when issuing a cert and take action if a method is deemed weak or
> insufficient.  We think this is a huge improvement over the existing
> landscape, and I'm very excited to see that OID rolled out.

I would like to see all CAs move in this direction as well.


Looks like you are going to be very busy! :-)

Thanks, and good luck!

Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

DigiCert-Symantec Announcement

[Jeremy Rowley via dev-security-policy]

Hi everyone, 

 

Today, DigiCert and Symantec announced that DigiCert is acquiring the
Symantec CA assets, including the infrastructure, personnel, roots, and
platforms.  At the same time, DigiCert signed a Sub CA agreement wherein we
will validate and issue all Symantec certs as of Dec 1, 2017.  We are
committed to meeting the Mozilla and Google plans in transitioning away from
the Symantec infrastructure. The deal is expected to close near the end of
the year, after which we will be solely responsible for operation of the CA.
>From there, we will migrate customers and systems as necessary to
consolidate platforms and operations while continuing to run all issuance
and validation through DigiCert.  We will post updates and plans to the
community as things change and progress.  

 

I wanted to post to the Mozilla dev list to:

1.  Inform the public, 
2.  Get community feedback about the transition and concerns, and
3.  Get an update from the browsers on what this means for the plan,
noting that we fully commit to the stated deadlines. We're hoping that any
changes 

 

Two things I can say we plan on doing (following closing) to address
concerns are:

a.  We plan to segregate certs by type on each root. Going forward, we
will issue all SSL certs from a root while client and email come from
different roots. We also plan on limiting the number of organizations on
each issuing CA.  We hope this will help address the "too big to fail" issue
seen with Symantec.  By segregating end entities into roots and sub CAs, the
browsers can add affected Sub CAs to their CRL lists quickly and without
impacting the entire ecosystem.  This plan is very much in flux, and we'd
love to hear additional recommendations. 
b.  Another thing we are doing is adding a validation OID to all of our
certificates that identifies which of the BR methods were used to issue the
cert. This way the entire community can readily identify which method was
used when issuing a cert and take action if a method is deemed weak or
insufficient.  We think this is a huge improvement over the existing
landscape, and I'm very excited to see that OID rolled out.

 

Thanks a ton for any thoughts you offer. 

 

Jeremy



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate with invalid CN and dnsName issued by certSIGN

[Jonathan Rudenberg via dev-security-policy]

> On Aug 2, 2017, at 12:28, Jonathan Rudenberg via dev-security-policy 
>  wrote:
> 
> This certificate, issued on July 27 by certSIGN, has an invalid common name 
> of “todyro_2017” and an invalid SAN dnsName of “ tody.ro” (note the leading 
> space):
> 
> https://crt.sh/?q=93EACBC95AE53D57322CA9646DCF260AE240369714906CD464561402BF32CE96=cablint

The above is not the first certificate issued by certSIGN with a leading space 
in a dnsName, which points to a failure in technical controls. Here is another 
one:

https://crt.sh/?q=91782A8F1182E239D49FABA796CFDF17AFC22A0D035838FD77FDD633FC72C416=cablint

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Nick Lamb via dev-security-policy]

On Monday, 24 July 2017 17:34:03 UTC+1, Ben Wilson  wrote:
> Nick,
> We are in discussions with Intesa Sanpaolo about implementing/pursuing
> OneCRL or a similar approach (e.g. outright revocation of the CAs).
> Thanks,
> Ben

Is there any progress on this? To be honest I was more meaning that Mozilla 
(Gerv?) should just add this subCA to OneCRL and be done with it.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Certificate with invalid CN and dnsName issued by certSIGN

[Jonathan Rudenberg via dev-security-policy]

This certificate, issued on July 27 by certSIGN, has an invalid common name of 
“todyro_2017” and an invalid SAN dnsName of “ tody.ro” (note the leading space):

https://crt.sh/?q=93EACBC95AE53D57322CA9646DCF260AE240369714906CD464561402BF32CE96=cablint
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intermediates missing audit disclosures (Firmaprofesional)

[Jonathan Rudenberg via dev-security-policy]

> On Aug 2, 2017, at 12:02, Jonathan Rudenberg via dev-security-policy 
>  wrote:
> 
> There are still three intermediates (one issued by Firmaprofesional and two 
> issued by Swisscom) that are missing audit disclosures in the CCADB and do 
> not have a pending OneCRL revocation:
> 
> - 
> https://crt.sh/?sha256=cbc689c87a63fa7323a7607cc7c457b3b450572befa47470b61c35bf079b600b
>  (see https://bugzilla.mozilla.org/show_bug.cgi?id=1368171)
> 

Actually it looks like I missed that the two Swisscom intermediates are only 
trusted for email by Mozilla, so it’s just the Firmaprofesional intermediate 
that is currently in scope.

Jonathan

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Intermediates missing audit disclosures (Firmaprofesional and Swisscom)

[Jonathan Rudenberg via dev-security-policy]

There are still three intermediates (one issued by Firmaprofesional and two 
issued by Swisscom) that are missing audit disclosures in the CCADB and do not 
have a pending OneCRL revocation:

- 
https://crt.sh/?sha256=cbc689c87a63fa7323a7607cc7c457b3b450572befa47470b61c35bf079b600b
 (see https://bugzilla.mozilla.org/show_bug.cgi?id=1368171)
- 
https://crt.sh/?sha256=5299ea42b7ee3d4422be47d0bfc64217426b57ee55a8e5465836a741c97e628a
- 
https://crt.sh/?sha256=801c82cbc298c07f082b9d2d22a0f23427e638f94f75dee4d0e081abc9046e52

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Undisclosed Taiwan GRCA intermediates

[Jonathan Rudenberg via dev-security-policy]

Two intermediates were issued by the Taiwan Government Root Certification 
Authority two weeks ago and have not been disclosed in CCADB:

- 
https://crt.sh/?sha256=a423a33493b31953226df96477627dbd056756704211001b6161fb5f8299dc3a
- 
https://crt.sh/?sha256=dd9c545d6b645c2bfbe1b6ecb60376006464e97bb1304b7978cfe83a4099b227

Jonathan
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Found something I can't understand in these cerificates.

[Jakob Bohm via dev-security-policy]

On 02/08/2017 04:28, Han Yuwei wrote:

在 2017年8月1日星期二 UTC+8下午8:47:57，Nick Lamb写道：

On Tuesday, 1 August 2017 08:39:28 UTC+1, Han Yuwei  wrote:

1. the CN of two cerificates are same. So it is not necessary to issue two 
certificates in just 2 minutes.


I think the most likely explanation is the difference in signature algorithm, 
but it is also not uncommon for subscribers to have more than one certificate 
fo the same name for operational reasons, this is not prohibited although it 
can be useful to watch for the rate at which this happens to an issuing system 
as a possible sign of trouble.


2. second one used SHA1, though is consistent with BR, but first one used 
SHA256.


It is possible that a customer ordered a certificate and then, very quickly but 
alas after issuance they realised they had more specific needs, the SHA-256 
algorithm and the longer expiry date. Or maybe even they simply asked for the 
longer expiry and WoSign correctly pointed out that it would silly to use SHA-1 
with the longer expiry as it was to be (and has been) distrusted by that date.


3. first one has 39 month period of validity which is very rare.


Although rare this is permissible, and even, if the subscriber had a previous 
certificate for roughly the same name, a common business practice in order to 
secure customer loyalty.


4. Since they are issued so close they should be logged at CT same time but 
second one are too late.


CT logging was not mandatory at the time, and WoSign subsequently volunteered 
to upload all the extant certificates in mid-2016 during Mozilla's 
investigation of other (serious) problems.

I think these certificates are, though perhaps not entirely regular, not a sign 
of any problem at WoSign.


Thanks for your explanation. So maybe some devices require SHA1 certificate to 
operate normally?



This certificate was issued during the SHA-1 transition, and many
website operators probably wanted to have an SHA-1 certificate in case
some clients (web browsers etc.) were not yet ready.  This often
involved getting matching SHA-256 and SHA-1 certificates before the BR
deadline, then keeping the SHA-1 certificate "in stock" in case it was
needed during 2016 (when new SHA-1 web certs could no longer be issued,
but could still be valid if requested in 2015).

No/Little way of knowing if they ever deployed that SHA-1 certificate,
either generally (for all visitors), or behind some special logic to
only use it for some known-broken client types.


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