SHA-1 serverAuth cert issued by Trustis in November 2016

[Rob Stradling]

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

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Nick Lamb]

On Wednesday, 15 February 2017 22:02:50 UTC, Rob Stradling wrote:
> 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!

At time of writing this certificate is installed on a web server, although I think only to re-direct visitors to the plain HTTP site. Whether the CA believed it would be used on a web server or not, that's what was done.

https://hmrcset.trustis.com/

It's not clear to me whether this is a brochure site, and thus can just be upgraded or if it's actually part of the described HMRC SET system itself. Either way it's on the web.

[Richard Wang]

Check the SSL Labs test: https://www.ssllabs.com/ssltest/analyze.html?d=hmrcset.trustis.com, rate F that even enabled SSL v2.


Best Regards,

Richard

On 16 Feb 2017, at 19:04, Nick Lamb via dev-security-policy <dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>> wrote:

On Wednesday, 15 February 2017 22:02:50 UTC, Rob Stradling wrote:

This currently unrevoked cert has a SHA-1/RSA signature, the serverAuth

EKU and CN=hmrcset.trustis.com<http://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!

At time of writing this certificate is installed on a web server, although I think only to re-direct visitors to the plain HTTP site. Whether the CA believed it would be used on a web server or not, that's what was done.

https://hmrcset.trustis.com/

It's not clear to me whether this is a brochure site, and thus can just be upgraded or if it's actually part of the described HMRC SET system itself. Either way it's on the web.

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

[Peter Gutmann]

Richard Wang via dev-security-policy <dev-secur...@lists.mozilla.org> writes:

>Check the SSL Labs test:
>https://www.ssllabs.com/ssltest/analyze.html?d=hmrcset.trustis.com, rate F
>that even enabled SSL v2.

Wow, no TLS 1.1 or 1.2, but in its place SSLv2 and v3. Another CA that's so
secure in the fact that it's a legislated market winner (they issue certs for
the UK national health service and tax authorities) that they don't have to
worry about security.

(Other UK CAs have done similar things, e.g. tScheme many years ago).

Peter.

[blake....@trustis.com]

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.

Kind regards,

Blake Morgan
Trustis Ltd

[Eric Mill]

On Thu, Feb 16, 2017 at 8:26 PM, blake.morgan--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
>
> 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.
>

Blake, respectfully, that's not very much detail. That doesn't describe how
the certificate was issued contrary to Mozilla policy, nor what changes
Trustis may have made to ensure it doesn't happen again.

-- Eric

>
> Kind regards,
>
> Blake Morgan
> Trustis Ltd

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy
>



--
konklone.com | @konklone <https://twitter.com/konklone>

[Gervase Markham]

On 16/02/17 18:26, blake....@trustis.com wrote:
> 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.

Hi Blake,

We are pleased to hear that, but the detail of your report compares
somewhat unfavourably with that of QuoVadis, about whom a similar
problem was raised in the same timeframe. You can find their report here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/xxtUlTOo6ak/XX6WqlEmEQAJ

We would appreciate it if Trustis could produce a similar document
within the week.

Many thanks,

Gerv

[blake....@trustis.com]

Hi Gerv,

Please see Trustis' formal report into the incident posted below:

Trustis Incident Report

Background

Trustis provides specific services for a UK government department, HMRC. This organisation acts as the only relying party and also has considerable control and influence over the nature of the service. The hmrcset.trustis.com certificate provides TLS protection for an enrolment portal which forms part of this service. It is used by a small number of applicants that have a pre-defined and established relationship with HMRC. The private keys for this certificate are managed and controlled by Trustis.

This particular certificate was approaching expiry and a replacement was issued as part of a routine renewal process.

Certificates for the HMRC SET Service are issued from the SHA-1 “FPS TT Issuing Authority”, which is now only used for this service. The replacement server certificate for hmrcset.trustis.com was issued from the FPS TT IA, via a manual process under the mistaken belief that this was necessary for this particular service to operate correctly.

Trustis has some time ago, migrated all TLS certificate production to SHA-256 Issuing Authorities. The small number of previously issued SHA-1 TLS certificates issued from “FPS TT”, that had lifetimes extending beyond 1 Jan 2017, were revoked towards the end of 2016.

Actions

Upon receiving notification of the mis-issuance, an assessment was conducted. As a result Trustis issued a replacement SHA-2 certificate and revoked the non-compliant certificate. .This was included in the CRL issued at 1806 hrs (UTC) on the 16th February 2017.

As part of the incident handling procedure, Trustis’ security management committee, commissioned a full investigation into the circumstances surrounding this incident and the details are provided below.

Investigation

The generation of the private keys and the production of the certificate in question are managed via Trustis internal procedures. These are separate to those for external Subscribers. In this case the operation was made somewhat more complex due to the transition from SHA-1 to SHA-2 and the difficulty our customer had endured as a result.

As a result of this, the operator mistakenly issued the certificate based on the customer’s SHA-1 requirements and it was subsequently issued from “FPS-TT”, under the belief that this was necessary for this particular service to operate. The operator had failed to recognise that, despite the transition difficulties for our customer, a new SHA-2 profile specification should have been used.

As a result of the investigation the security management committee has made a number of recommendations. Principal amongst these is enhanced training and oversight for technical staff that deal with unique certificates or certificate management in complex circumstances that are not part of standard operations.

Regards,

Blake Morgan
Trustis Ltd

[Andrew Ayer]

On Fri, 24 Feb 2017 07:08:54 -0800 (PST)

"blake.morgan--- via dev-security-policy"
<dev-secur...@lists.mozilla.org> wrote:

> Trustis has some time ago, migrated all TLS certificate production to
> SHA-256 Issuing Authorities. The small number of previously issued
> SHA-1 TLS certificates issued from “FPS TT”, that had lifetimes
> extending beyond 1 Jan 2017, were revoked towards the end of 2016.

Below is an unrevoked SHA-1 serverAuth certificate for
getset.trustis.com issued from this CA with a Not Before date of
2016-11-07.

Regards,
Andrew

-----BEGIN CERTIFICATE-----
MIIFYjCCBEqgAwIBAgIQXk1LkWmIzHB+YFd0TZ1TTDANBgkqhkiG9w0BAQUFADBS
MQswCQYDVQQGEwJHQjEYMBYGA1UEChMPVHJ1c3RpcyBMaW1pdGVkMSkwJwYDVQQL
EyBUcnVzdGlzIEZQUyBUVCBJc3N1aW5nIEF1dGhvcml0eTAeFw0xNjExMDcxNTE4
NTZaFw0yMDAxMTcxMTQ1NTZaMGsxCzAJBgNVBAYTAkdCMRgwFgYDVQQKEw9UcnVz
dGlzIExpbWl0ZWQxJTAjBgNVBAsTHEhNUkMgU0VUIENlcnRpZmljYXRlIFNlcnZp
Y2UxGzAZBgNVBAMTEmdldHNldC50cnVzdGlzLmNvbTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAMMvz9cWfI8vaGUdYPPr7uh41whxzhx0pFd6D0yTg2gd
MR8fqA93VViWV2XGqbFdbUnRQHksFZ0Vx6kA4BbyP/zRpaC3vOtcYpYqWnfudZLw
wRxVOwzVkz6ImhxiSWjbX1BdsDCohTmCBha4CKdtUewxeXQlIt2Cz//oxRvsZM+S
owY76YEDMF5V5lGgtYQXgyj/Oau7PAVurKtGB5IUbSBjXsfZsg4W//qsJzhlPLym
lmnWM2Yg/ykDLFKWeehRFa6jCz8w0JiRK5ynGu0aps//g65w+jeHiZyFzldWazqf
PpgvvKNtEYlT4pWc27Tk38ZzH8jNUksa9T9RBBnKUFcCAwEAAaOCAhkwggIVMB8G
A1UdIwQYMBaAFMCiJVnUHgITg9QvBIhUSiCNb43+MIIBOgYDVR0gBIIBMTCCAS0w
ggEpBgorBgEEAah1AQEDMIIBGTAtBggrBgEFBQcCARYhaHR0cDovL3d3dy50cnVz
dGlzLmNvbS9wa2kvZnBzaWEvMIHnBggrBgEFBQcCAjCB2hqB10lzc3VlZCBpbiBh
Y2NvcmRhbmNlIHdpdGggYW5kIGdvdmVybmVkIGJ5IHRoZSBUcnVzdGlzIEZQUyBJ
c3N1aW5nIEF1dGhvcml0eSBDZXJ0aWZpY2F0ZSBQb2xpY3kgd2hpY2ggY2FuIGJl
IGZvdW5kIGF0IGh0dHA6Ly93d3cudHJ1c3Rpcy5jb20vcGtpL2Zwc2lhLyAgIFRy
dXN0aXMgRlBTLCBhIGRpdmlzaW9uIG9mIFRydXN0aXMgTGltaXRlZCAod3d3LnRy
dXN0aXMuY29tKQ0KMHAGA1UdHwRpMGcwZaBjoGGGLmh0dHA6Ly93d3cudHJ1c3Rp
cy5jb20vcGtpL2Zwc2lhL2NybC90dC1lZS5jcmyGL2h0dHA6Ly9zY2NzLnRydXN0
aXMuY29tL3BraS9mcHNpYS9jcmwvdHQtZWUuY3JsMBMGA1UdJQQMMAoGCCsGAQUF
BwMBMA4GA1UdDwEB/wQEAwIFoDAdBgNVHQ4EFgQUudovYJjp2vzykUX0GuDVS6oL
hLMwDQYJKoZIhvcNAQEFBQADggEBAB/xHCvYydnefZrndUVVUMpUBCPkfmSAjWna
G/cu6xrLxy+SwNXqpUydcIKNj3MyoZCIfzzSGpB0GbE2fXKvVt0vW3+fqcPGBtz/
szYldrROH2DVbg4e3GbkV65SomwMpnQfvwBydLOa7eCyqD5uYQ4BVyT0bAnoiRHj
QrWpkbVknpgnvIDQR7NO6msg2hwiNH1j3VyfWaPTxLT2tybzgQzC2uH0ivTJim4n
Kbya3zUApBKgP5ylJSXh/t5sVKlB32Qby8fpxoDsPLexJZPiRJSJx6t/iCxpshB2
v8gl8IWKHF3xIdWfW4H72U/zIyEKnyR+1C/0KxnZP56tbtxWGp0=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFEDCCA/igAwIBAgIRAOvV+QArW1IlExGq8Ft+41EwDQYJKoZIhvcNAQEFBQAw
RTELMAkGA1UEBhMCR0IxGDAWBgNVBAoTD1RydXN0aXMgTGltaXRlZDEcMBoGA1UE
CxMTVHJ1c3RpcyBGUFMgUm9vdCBDQTAeFw0xMDEyMDExMjQyMzBaFw0yMDAxMTgx
MTQyMzBaMFIxCzAJBgNVBAYTAkdCMRgwFgYDVQQKEw9UcnVzdGlzIExpbWl0ZWQx
KTAnBgNVBAsTIFRydXN0aXMgRlBTIFRUIElzc3VpbmcgQXV0aG9yaXR5MIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAk7x4ogwd5RxiVm5ucUkaPjD592H3
fWNa+1jSz/GdP2VaCigGdAYGC9CdPrO5q+X2liSTjcW23OOoJxV//Dv5o73c+qmP
24LlUmhoddbk6yn6sBAZLqw0GbqITqQz+hSUD5V+JzV6LJfSmSBtBOT3ALQwgssC
RO5H/RkyGfKmdHqFfgorzwrUjSmuSPx2+ke9Q3kR2yL0Sk4741gRaPq5fo9XgZNY
80FLYnNthHM5wq9koUkmbogYW2qtO5aKv9N8KLWoW3dfLizloLqRiR+Kkuscgnty
LEvumNVF0o5LBk+h8KIqgTJWUyEmlAMQ0vFbCRFXVr+mu7CgJNK5gGIRGQIDAQAB
o4IB7DCCAegwHwYDVR0jBBgwFoAUuvpxJXmLV0ElIYYLceuyZA6LIWcwDwYDVR0T
AQH/BAUwAwEB/zCCAUcGA1UdIASCAT4wggE6MIIBNgYKKwYBBAGodQEBAzCCASYw
LQYIKwYBBQUHAgEWIWh0dHA6Ly93d3cudHJ1c3Rpcy5jb20vcGtpL2Zwc2lhLzCB
9AYIKwYBBQUHAgIwgecwChYDQ1BTMAMCAQEagdhJc3N1ZWQgaW4gYWNjb3JkYW5j
ZSB3aXRoIGFuZCBnb3Zlcm5lZCBieSB0aGUgVHJ1c3RpcyBGUFMgSXNzdWluZyBB
dXRob3JpdHkgQ2VydGlmaWNhdGUgUG9saWN5IHdoaWNoIGNhbiBiZSBmb3VuZCBh
dCANCmh0dHA6Ly93d3cudHJ1c3Rpcy5jb20vcGtpL2Zwc2lhLw0KDQpUcnVzdGlz
IEZQUywgYSBkaXZpc2lvbiBvZiBUcnVzdGlzIExpbWl0ZWQgKHd3dy50cnVzdGlz
LmNvbSkwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL3d3dy50cnVzdGlzLmNvbS9w
a2kvZnBzL2NybC9pYS5jcmwwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTAoiVZ
1B4CE4PULwSIVEogjW+N/jANBgkqhkiG9w0BAQUFAAOCAQEAVF6ttbAx8r0dwLlr
0wz/gHOC9ham3PHHDvlcC09QvoD3uOgqfdrtlLeTUHZHu4bYRELsEofUfsF5cHQS
M08SinUam3LWYrNygmwU4XNYk8M475Igun2wM30cx9TiBhL4VmdpG7T9Q2GF89YE
0YQf3xki3FltHOC7KtOHlBTktYgYwPdCdp0I0nEKMLUtd0OBPG2jPKU5gmBf5nxX
LlQpt5JkxY7Eg2PVXUkIEaKiCqjzLepLdFXCuAI1ONBxKNhD8bcq2NCT/e4+WRXk
7cqqnpseNaUdV7PRNjR/JttcYjXNCZ5dVYnpvlVLOonPI7mleR6ikAJX3mZiVSwY
bFKzCg==
-----END CERTIFICATE-----

[Andrew Ayer]

On Fri, 24 Feb 2017 08:25:25 -0800
Andrew Ayer via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:

> On Fri, 24 Feb 2017 07:08:54 -0800 (PST)
> "blake.morgan--- via dev-security-policy"
> <dev-secur...@lists.mozilla.org> wrote:
>
> > Trustis has some time ago, migrated all TLS certificate production
> > to SHA-256 Issuing Authorities. The small number of previously
> > issued SHA-1 TLS certificates issued from “FPS TT”, that had
> > lifetimes extending beyond 1 Jan 2017, were revoked towards the end
> > of 2016.
>
> Below is an unrevoked SHA-1 serverAuth certificate for
> getset.trustis.com issued from this CA with a Not Before date of
> 2016-11-07.

This certificate can now be viewed on crt.sh:

https://crt.sh/?sha256=bb0835a27459d0b02aa797f3f35b02457ac07b57497aa0266677708c7b20fb20

Regards,
Andrew

[Gervase Markham]

On 24/02/17 07:08, blake....@trustis.com wrote:
> Certificates for the HMRC SET Service are issued from the SHA-1 “FPS
> TT Issuing Authority”, which is now only used for this service. The
> replacement server certificate for hmrcset.trustis.com was issued
> from the FPS TT IA, via a manual process under the mistaken belief
> that this was necessary for this particular service to operate
> correctly.

And presumably under the further mistaken belief that "necessary for
this particular service to operate correctly" was a good enough reason
to disregard the SHA-1 ban?

> Trustis has some time ago, migrated all TLS certificate production to
> SHA-256 Issuing Authorities. The small number of previously issued
> SHA-1 TLS certificates issued from “FPS TT”, that had lifetimes
> extending beyond 1 Jan 2017, were revoked towards the end of 2016.

Except the one in use on hmrcset.trustis.com? It's not clear how the
certificate-nearing-expiry for that domain fits into the last sentence
of the paragraph above.

> As a result of the investigation the security management committee
> has made a number of recommendations. Principal amongst these is
> enhanced training and oversight for technical staff that deal with
> unique certificates or certificate management in complex
> circumstances that are not part of standard operations.

Have you deleted, locked or otherwise made unavailable all SHA-1
profiles which relate to intermediates which chain up to publicly
trusted roots?

Gerv

[Gervase Markham]

On 24/02/17 08:25, Andrew Ayer wrote:
> Below is an unrevoked SHA-1 serverAuth certificate for
> getset.trustis.com issued from this CA with a Not Before date of
> 2016-11-07.

Blake: you wrote: "As part of the incident handling procedure, Trustis’

security management committee, commissioned a full investigation into

the circumstances surrounding this incident."

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?

Gerv

[blake....@trustis.com]

Hi Gerv,

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.

Kind regards,
Blake

[Gervase Markham]

Hi Blake,

On 02/03/17 16:26, blake....@trustis.com wrote:
> 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.

Do you have an ETA for this incident report? It's been quite some time
now. I am still interested to understand how a "full investigation" of
the first certificate failed to turn up the second.

Gerv

[uri...@gmail.com]

Is there an expectation of a resolution of some sort to this matter?
Also, their most recent audit is apparently overdue (perhaps related to the SHA-1 mis-issuance?)

https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/-689uFoXBwAJ

[Gervase Markham]

On 12/04/17 21:39, uri...@gmail.com wrote:
> Is there an expectation of a resolution of some sort to this matter?
> Also, their most recent audit is apparently overdue (perhaps related to the SHA-1 mis-issuance?)
>
> https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/-689uFoXBwAJ

I am actively pursuing Trustis in regard to this matter.

Gerv

[blake....@trustis.com]

On Thursday, March 16, 2017 at 11:00:51 AM UTC, Gervase Markham wrote:
> Hi Blake,
>

> On 02/03/17 16:26, blake morgan wrote:
> > 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.
>
> Do you have an ETA for this incident report? It's been quite some time
> now. I am still interested to understand how a "full investigation" of
> the first certificate failed to turn up the second.
>
> Gerv

Hi Gerv,

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.

Regards,
Blake

[Gervase Markham]

Hi Blake,

On 21/04/17 16:55, blake....@trustis.com wrote:
> 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.

Thank you for the update.

Gerv