LetsEncrypt certificate is not recognized by Chrome Android 6.0.1/5.0.2

2,948 views
Skip to first unread message

Kaiduan Xie

unread,
May 15, 2016, 1:07:36 AM5/15/16
to Josh Aas, Let's Encrypt CA Development, Let's Encrypt Client Development
Josh,

I suddenly found that https://helloworld.letsencrypt.org was determined by not private on Chrome on Android 6.0.1/5.0.2 today. This is a very big nasty surprise :(

What has changed on Android side?

Thanks for help,

/Kaiduan

蔡崴丞

unread,
May 15, 2016, 1:24:46 AM5/15/16
to Kaiduan Xie, Josh Aas, Let's Encrypt CA Development, Let's Encrypt Client Development

It's using X1 signed by ISRG Root,which isn't included in most browser.


--
You received this message because you are subscribed to the Google Groups "Let's Encrypt Client Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to client-dev+...@letsencrypt.org.
To post to this group, send email to clien...@letsencrypt.org.
To view this discussion on the web visit https://groups.google.com/a/letsencrypt.org/d/msgid/client-dev/CACKRbQeS3MPr_p8EASsJ_LaQgQ6bx4td5f8DjjW_qHVYkpqFng%40mail.gmail.com.

Melvin Carvalho

unread,
May 15, 2016, 6:58:55 AM5/15/16
to 蔡崴丞, Kaiduan Xie, Josh Aas, Let's Encrypt CA Development, Let's Encrypt Client Development
On 15 May 2016 at 07:24, 蔡崴丞 <dann...@gmail.com> wrote:

It's using X1 signed by ISRG Root,which isn't included in most browser.

Works for me on chrome, firefox, opera (desktop)
 

--
You received this message because you are subscribed to the Google Groups "Let's Encrypt CA Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ca-dev+un...@letsencrypt.org.

Timothy Holborn

unread,
May 15, 2016, 8:17:30 AM5/15/16
to Melvin Carvalho, 蔡崴丞, Kaiduan Xie, Josh Aas, Let's Encrypt CA Development, Let's Encrypt Client Development

doesn't work on my android device.

Daniel Reynolds

unread,
May 15, 2016, 11:44:49 AM5/15/16
to Timothy Holborn, Melvin Carvalho, 蔡崴丞, Kaiduan Xie, Josh Aas, Let's Encrypt CA Development, Let's Encrypt Client Development

Jeroen de Neef

unread,
May 15, 2016, 12:22:49 PM5/15/16
to Daniel Reynolds, Timothy Holborn, Melvin Carvalho, 蔡崴丞, Kaiduan Xie, Josh Aas, Let's Encrypt CA Development, Let's Encrypt Client Development
It doesn't work for me on Windows 7, Google Chrome version 50.0.2661.102 m.

Michel Kuijpers

unread,
May 15, 2016, 1:42:02 PM5/15/16
to Jeroen de Neef, Daniel Reynolds, Timothy Holborn, Melvin Carvalho, 蔡崴丞, Kaiduan Xie, Josh Aas, Let's Encrypt CA Development, Let's Encrypt Client Development
also doesn’t work on my MacBook Pro (10.11.4 (15E65)) in Safari (Version 9.1 (11601.5.17.1)) but it works in Chrome (Version 50.0.2661.102 (64-bit))

Groeten en een fijne dag,
Michel
-=-=-=-=-=-=-=-

Met vriendelijke groet,
Michel Kuijpers
-------------------------------------
Du-llens Fotografie en Websolutions
URL: http://www.du-llens.net
Email: mic...@du-llens.net
Mobiel: 06-23977966
-------------------------------------

Daniel Jeffery

unread,
May 15, 2016, 1:54:30 PM5/15/16
to Jeroen de Neef, Daniel Reynolds, Timothy Holborn, Melvin Carvalho, 蔡崴丞, Kaiduan Xie, Josh Aas, Let's Encrypt CA Development, Let's Encrypt Client Development
As danny8376 pointed out https://helloworld.letsencrypt.org is currently NOT using the intermediate cross-signed by IdenTrust. As a result the site will come up as untrusted if the ISRG root has not been manually added to a browser cache. This is intentional as Let's Encrypt is jumping through hoops with some root programs to get their roots accepted.

Vladimir Djukelic

unread,
May 15, 2016, 2:05:02 PM5/15/16
to Michel Kuijpers, Jeroen de Neef, Daniel Reynolds, Timothy Holborn, Melvin Carvalho, 蔡崴丞, Kaiduan Xie, Josh Aas, Let's Encrypt CA Development, Let's Encrypt Client Development
DOES NOT work on Safari Version 9.1 (11601.5.17.1) on Mac OS X El Capitan 10.11.4 (15E65)

DOES WORK on Chrome Version 50.0.2661.102 (64-bit) on Mac OS X El Capitan 10.11.4 (15E65)



Timothy Holborn

unread,
May 15, 2016, 2:09:11 PM5/15/16
to Vladimir Djukelic, Michel Kuijpers, Jeroen de Neef, Daniel Reynolds, Josh Aas, Kaiduan Xie, Let's Encrypt CA Development, Let's Encrypt Client Development, Melvin Carvalho, 蔡崴丞
how about making a little promo video / campaign explaining for lay people what it is and how to install. perhaps also browser extension that could help if for some reason  (ie: s/w update) the install needs to occur again.

Might also be useful for decentralization generally, but would want to have some means to manage trust with any such tools broadly.

TimH..

Lucas Garron

unread,
May 16, 2016, 2:58:56 PM5/16/16
to Timothy Holborn, Vladimir Djukelic, Michel Kuijpers, Jeroen de Neef, Daniel Reynolds, Josh Aas, Kaiduan Xie, Let's Encrypt CA Development, Let's Encrypt Client Development, Melvin Carvalho, 蔡崴丞
The whole point of Let's Encrypt is to provide a free CA that works *without* users having to do anything.
Also, to take one example, Chrome uses the OS trust store, so it's not straightforward to just "add the root to modern browsers".

In any case, the problem with helloworld.letsencrypt.org has nothing to do with the root(s), since the Let's Encrypt X1 is actually signed by both the ISRG root and the IdenTrust root.
In order to use the current leaf cert, the site needs to serve the Let's Encrypt X1 cert as an intermediate, as suggested by the SSL Labs scanner:

This will make it work on the Android devices mentioned in this thread, as well as any other devices that don't support AIA.
»Lucas

J.C. Jones

unread,
May 16, 2016, 3:57:51 PM5/16/16
to Lucas Garron, Timothy Holborn, Vladimir Djukelic, Michel Kuijpers, Jeroen de Neef, Daniel Reynolds, Josh Aas, Kaiduan Xie, Let's Encrypt CA Development, Let's Encrypt Client Development, Melvin Carvalho, 蔡崴丞
As Dan said, the "Hello World" site is being used as a demonstration of the ISRG Root X1 for various root programs. Recently, Mozilla asked that the helloworld site present the ISRG Root X1-path certificate rather than the cross-signed certificate for their testing [1]. That's why it is configured this way.

In theory, it could present both the cross-signed and not-cross-signed intermediates, but that will break clients in other ways, and still present certificate chain errors at SSL Labs  (specifically "Extra certs, incorrect order") .

In hindsight, it would have been better to use a different site for the root program applications, but it's stuck now.


Cheers,
J.C. 

Anders Henke

unread,
May 17, 2016, 11:46:01 AM5/17/16
to clien...@letsencrypt.org
Manually adding a root certificate actually is a very trivial thing: Let's Encrypt could provide a simple download link and ask the user to click on it. In many environments, it's shockingly easier to import a root certificate than to skip/accept the warnings of a self-signed certificate.

Why is it that shocking: a root certificate is another "ultimate" trust anchor into your computer. The root certificate then can be used to impersonate any website or tell your operating system "it's fine to run that executable, skip any warnings".

x509 by design doesn't know about "decentralization": while a subordinate CA may be restricted (if every software plays fine and adheres those restrictions), a root certificate has no restrictions at all.


It's short of giving some stranger a master key to your (digital) house: before you're doing so, you'd really like to know that "stranger" well. Hence browser and operating system vendors do use various processes to verify if the operators of a new root certificate really do "know what they're doing" and  are trustworthy.

If "adding a root certificate" becomes an "usual task" (like "click away that cookie information"), lay people will be happy to add root certificates. It's just a few clicks ... then, the root certificate will be able to impersonate about any website's certificate.

I do consider it a very bad idea to make "adding root certificates" an everyday task.
While it's legitimate for Let's Encrypt's root certificate, in the very next second some phishing spam might ask users to add "their" root certificate as well. And a secondary spam run will be able to use "perfect" impersonations of e.g. banking websites, webmail services, whatever you're asking. The browser's address bar will show the "correct" address, it will display the secure lock icon, about anything we're teaching users to take care of.

The only available technique to save users from malicious CAs today were HTTP Public Key Pinning.
As Netcraft recently discussed ( http://news.netcraft.com/archives/2016/03/30/http-public-key-pinning-youre-doing-it-wrong.html ), only a few thousand websites are actually deploying that technique right now. A third out of them uses it incorrectly, which effectively disables it for them.

In such a world, educating users how to add random root certificates is a very bad idea.



Best,
Anders
Reply all
Reply to author
Forward
0 new messages