1353838 - Trustis: SHA-1 serverAuth cert issued in November 2016

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Kathleen Wilson]

Reported in the mozilla.dev.security.policy forum:
https://groups.google.com/d/msg/mozilla.dev.security.policy/w_FCLt4XWBU/BI0scuXiEAAJ

This currently unrevoked cert has a SHA-1/RSA signature, the serverAuth
EKU and CN=hmrcset.trustis.com:
https://crt.sh/?id=50773741&opt=cablint

It lacks the SAN extension, but that doesn't excuse it from the ban on
SHA-1!

Its issuer is trusted for serverAuth by Mozilla:
https://crt.sh/?caid=920&opt=mozilladisclosure


Update from Trustis on Feb 16:
Trustis has now revoked the SHA-1 Certificate for hmrcset.trustis.com and replaced it with a SHA-256 Certificate.  This status is reflected in the latest CRL. 

Incident report provided by Trustis on Feb 24:
https://groups.google.com/d/msg/mozilla.dev.security.policy/w_FCLt4XWBU/TUF0Ds1eAQAJ

Immediately followed by a report of another SHA-1 serverAuth cert:
... an unrevoked SHA-1 serverAuth certificate for getset.trustis.com issued from this CA with a Not Before date of 2016-11-07. 
https://crt.sh/?sha256=bb0835a27459d0b02aa797f3f35b02457ac07b57497aa0266677708c7b20fb20

Question from Gerv to CA on Feb 24:
Have you deleted, locked or otherwise made unavailable all SHA-1 profiles which relate to intermediates which chain up to publicly trusted roots? 
...
In reply to the incident report:
It seems this investigation was not full enough to discover the existence of a second SHA-1 certificate issued 20 minutes after the first one for a very similar domain, presumably by the same operator and using the same processes? 

Trustis reply on March 2:
We have engaged with our external auditors in relation to this and the
previous certificate that was reported. Once that activity has concluded we will be providing further information.


Status: Still waiting for full incident report from Trustis.

Comment 1

[Blake Morgan]

(In reply to Kathleen Wilson from comment #0)
> Reported in the mozilla.dev.security.policy forum:
> https://groups.google.com/d/msg/mozilla.dev.security.policy/w_FCLt4XWBU/
> BI0scuXiEAAJ
> 
> This currently unrevoked cert has a SHA-1/RSA signature, the serverAuth
> EKU and CN=hmrcset.trustis.com:
> https://crt.sh/?id=50773741&opt=cablint
> 
> It lacks the SAN extension, but that doesn't excuse it from the ban on
> SHA-1!
> 
> Its issuer is trusted for serverAuth by Mozilla:
> https://crt.sh/?caid=920&opt=mozilladisclosure
> 
> 
> Update from Trustis on Feb 16:
> Trustis has now revoked the SHA-1 Certificate for hmrcset.trustis.com and
> replaced it with a SHA-256 Certificate.  This status is reflected in the
> latest CRL. 
> 
> Incident report provided by Trustis on Feb 24:
> https://groups.google.com/d/msg/mozilla.dev.security.policy/w_FCLt4XWBU/
> TUF0Ds1eAQAJ
> 
> Immediately followed by a report of another SHA-1 serverAuth cert:
> ... an unrevoked SHA-1 serverAuth certificate for getset.trustis.com issued
> from this CA with a Not Before date of 2016-11-07. 
> https://crt.sh/
> ?sha256=bb0835a27459d0b02aa797f3f35b02457ac07b57497aa0266677708c7b20fb20
> 
> Question from Gerv to CA on Feb 24:
> Have you deleted, locked or otherwise made unavailable all SHA-1 profiles
> which relate to intermediates which chain up to publicly trusted roots? 
> ...
> In reply to the incident report:
> It seems this investigation was not full enough to discover the existence of
> a second SHA-1 certificate issued 20 minutes after the first one for a very
> similar domain, presumably by the same operator and using the same
> processes? 
> 
> Trustis reply on March 2:
> We have engaged with our external auditors in relation to this and the
> previous certificate that was reported. Once that activity has concluded we
> will be providing further information.
> 
> 
> Status: Still waiting for full incident report from Trustis.

Following further discussion with, and guidance from Mozilla, it has been determined that the getset.trustis.com certificate issued in November 2016 was a mis-issuance.  This incident has highlighted an ambiguity arising from the mismatch of scope between CAB Forum BRs v1.3 and Mozilla CP v2.3.  It is useful to note that the Mozilla CP v2.4 provides revised wording which represents an improvement in this regard. 

However, it is suggested that careful attention is given when issuing certificates which fall outside the scope of CAB Forum BRs, but may nevertheless be subject to provisions of the CAB Forum BRs under the Mozilla CP.  

In support of improving clarity Mozilla has posted an issue here https://github.com/mozilla/pkipolicy/issues/72.

It is therefore believed that this bug can now be closed.