Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Sectigo-issued certificates with concerningly mismatched subject information
446 views
Skip to first unread message
Ian Carroll
Jan 26, 2020, 4:59:43 AM1/26/20
to mozilla-dev-s...@lists.mozilla.org
Hi,
I was recently sent https://crt.sh/?id=380678631 by Nathanial Lattimer (https://twitter.com/d0nutptr), when he noticed it appeared to contain subject information for a completely different entity (Harman International's domain, Twitter's organizational information). It appears Sectigo made this mistake several times, in https://crt.sh/?id=380583413 and https://crt.sh/?id=369796283 as well.
These certificates expired in 2019 and are thus no longer a problem, but they were actively used by the customer (e.infinityspeakers.com still serves one of them) and it does not appear anyone has noticed. Harman is owned by Samsung and so it is very unlikely these were properly issued.
I wanted to highlight this mis-issuance since it seems like a concerning failure case that is different from a simple typo, and may have a more systemic root cause. If there is a bug that is repeatedly causing i.e. the swapping of identity information in certificate requests, it would be pretty concerning.
These certificates have been reported to ssla...@sectigo.com as well.
I was recently sent https://crt.sh/?id=380678631 by Nathanial Lattimer (https://twitter.com/d0nutptr), when he noticed it appeared to contain subject information for a completely different entity (Harman International's domain, Twitter's organizational information). It appears Sectigo made this mistake several times, in https://crt.sh/?id=380583413 and https://crt.sh/?id=369796283 as well.
These certificates expired in 2019 and are thus no longer a problem, but they were actively used by the customer (e.infinityspeakers.com still serves one of them) and it does not appear anyone has noticed. Harman is owned by Samsung and so it is very unlikely these were properly issued.
I wanted to highlight this mis-issuance since it seems like a concerning failure case that is different from a simple typo, and may have a more systemic root cause. If there is a bug that is repeatedly causing i.e. the swapping of identity information in certificate requests, it would be pretty concerning.
These certificates have been reported to ssla...@sectigo.com as well.
Hanno Böck
Jan 26, 2020, 5:16:34 AM1/26/20
to dev-secur...@lists.mozilla.org
On Sun, 26 Jan 2020 01:59:33 -0800 (PST)
Ian Carroll via dev-security-policy
I see that a lot of people are having fun pointing out these issues
again and again to show how sloppy CAs work. Which is fine I guess, but
it leads to the question what the point of all this is. Maybe it's time
to change the WebPKI rules to reflect that - either say "any information
in a certificate that is not the CN/SAN is yolo and can be whatever and
web clients should make sure they never display that informaiton" or
"any useless extra information should be skipped".
Let's be honest: There are two reasons these extra fields exist in the
first place, and no good one. One reason is they are legacy baggage from
the X.509 standard. If we'd rewrite the webpki today we wouldn't have
such fields. The other is that they are upselling features where CAs can
create the illusion that there are more or less valuable certificates.
--
Hanno Böck
https://hboeck.de/
Ian Carroll via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
> These certificates expired in 2019 and are thus no longer a problem,
> but they were actively used by the customer (e.infinityspeakers.com
> still serves one of them) and it does not appear anyone has noticed.
I guess this is the most relevant part here. Noone has noticed.
> These certificates expired in 2019 and are thus no longer a problem,
> but they were actively used by the customer (e.infinityspeakers.com
> still serves one of them) and it does not appear anyone has noticed.
I see that a lot of people are having fun pointing out these issues
again and again to show how sloppy CAs work. Which is fine I guess, but
it leads to the question what the point of all this is. Maybe it's time
to change the WebPKI rules to reflect that - either say "any information
in a certificate that is not the CN/SAN is yolo and can be whatever and
web clients should make sure they never display that informaiton" or
"any useless extra information should be skipped".
Let's be honest: There are two reasons these extra fields exist in the
first place, and no good one. One reason is they are legacy baggage from
the X.509 standard. If we'd rewrite the webpki today we wouldn't have
such fields. The other is that they are upselling features where CAs can
create the illusion that there are more or less valuable certificates.
--
Hanno Böck
https://hboeck.de/
Nick Lamb
Jan 26, 2020, 8:52:33 AM1/26/20
to dev-secur...@lists.mozilla.org, Hanno Böck
On Sun, 26 Jan 2020 11:16:24 +0100
Hanno Böck via dev-security-policy
significance, this type of mistake might realistically have grave impact
depending on how it happens, for which we will need Sectigo's honest
response to the incident.
For example suppose Sectigo has a bug in which under some circumstances
Customer A is treated as though they were Customer B instead, and of
course certificates like these are one possible result of the bug that
we can see in the CT logs. But other symptoms of that same bug might
include Customer B has proved to Sectigo that they control example.com,
so Customer B can order new certificates for example.com, but with the
bug now Customer A can get such certificates too which they are not
entitled to.
> Maybe it's time to change the WebPKI rules to reflect that - either say
> "any information in a certificate that is not the CN/SAN is yolo and
> can be whatever and web clients should make sure they never display
> that informaiton" or "any useless extra information should be
> skipped".
I definitely can't support the former. The purpose of X.509
certificates is to bind a public key to an identity. If we decide that
something isn't part of the identity then it shouldn't be included.
I think the latter isn't a good idea, beyond the extent to which it's
already present in the BRs but I don't feel strongly about it.
Hanno Böck via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
> I guess this is the most relevant part here. Noone has noticed.
>
> I see that a lot of people are having fun pointing out these issues
> again and again to show how sloppy CAs work. Which is fine I guess,
> but it leads to the question what the point of all this is.
Unlike minor typographical errors which I don't think have a larger
> I guess this is the most relevant part here. Noone has noticed.
>
> I see that a lot of people are having fun pointing out these issues
> again and again to show how sloppy CAs work. Which is fine I guess,
> but it leads to the question what the point of all this is.
significance, this type of mistake might realistically have grave impact
depending on how it happens, for which we will need Sectigo's honest
response to the incident.
For example suppose Sectigo has a bug in which under some circumstances
Customer A is treated as though they were Customer B instead, and of
course certificates like these are one possible result of the bug that
we can see in the CT logs. But other symptoms of that same bug might
include Customer B has proved to Sectigo that they control example.com,
so Customer B can order new certificates for example.com, but with the
bug now Customer A can get such certificates too which they are not
entitled to.
> Maybe it's time to change the WebPKI rules to reflect that - either say
> "any information in a certificate that is not the CN/SAN is yolo and
> can be whatever and web clients should make sure they never display
> that informaiton" or "any useless extra information should be
> skipped".
certificates is to bind a public key to an identity. If we decide that
something isn't part of the identity then it shouldn't be included.
I think the latter isn't a good idea, beyond the extent to which it's
already present in the BRs but I don't feel strongly about it.
0 new messages