Re: SHA-1 serverAuth cert issued by Trustis in November 2016

2017-04-24 Thread Gervase Markham via dev-security-policy 
Hi Blake,

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

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

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

2017-04-21 Thread blake.morgan--- via dev-security-policy 
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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

2017-04-13 Thread Gervase Markham via dev-security-policy 
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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

2017-04-12 Thread urijah--- via dev-security-policy 
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


On Thursday, March 16, 2017 at 7:00:51 AM UTC-4, Gervase Markham wrote:
> Hi Blake,
> 
> On 02/03/17 16:26, blake.mor...@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

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

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

2017-03-16 Thread Gervase Markham via dev-security-policy 
Hi Blake,

On 02/03/17 16:26, blake.mor...@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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

2017-03-02 Thread blake.morgan--- via dev-security-policy 
On Friday, February 24, 2017 at 11:25:22 PM UTC, Gervase Markham wrote:
> 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

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

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

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

2017-02-24 Thread Gervase Markham via dev-security-policy 
On 24/02/17 07:08, blake.mor...@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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

2017-02-24 Thread Andrew Ayer via dev-security-policy 
On Fri, 24 Feb 2017 07:08:54 -0800 (PST)
"blake.morgan--- via dev-security-policy"
 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-
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

2017-02-24 Thread blake.morgan--- via dev-security-policy 
On Monday, February 20, 2017 at 11:50:59 AM UTC, Gervase Markham wrote:
> On 16/02/17 18:26, blake.mor...@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

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

2017-02-20 Thread Gervase Markham via dev-security-policy 
On 16/02/17 18:26, blake.mor...@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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

2017-02-16 Thread Eric Mill via dev-security-policy 
On Thu, Feb 16, 2017 at 8:26 PM, blake.morgan--- via dev-security-policy <
dev-security-policy@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-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



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

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

2017-02-16 Thread blake.morgan--- via dev-security-policy 
On Wednesday, February 15, 2017 at 10:02:50 PM 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=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=mozilladisclosure
> 
> -- 
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

2017-02-16 Thread Richard Wang via dev-security-policy 
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 
>
 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:
https://crt.sh/?id=50773741=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-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

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

2017-02-16 Thread Nick Lamb via dev-security-policy 
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=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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

SHA-1 serverAuth cert issued by Trustis in November 2016

2017-02-15 Thread Rob Stradling via dev-security-policy 
This currently unrevoked cert has a SHA-1/RSA signature, the serverAuth 
EKU and CN=hmrcset.trustis.com:

https://crt.sh/?id=50773741=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=mozilladisclosure

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy