Certificate Transparancy not working in Chrome?

Issuance Tech
1

Hi all,

I installed the Let’s Encrypt certificates on my test-server and I was expecting that the Let’s Encrypt certificates where using certificate transparancy (CT). But when I look at the transparancy indicator in Chrome, it says that the server didn’t provide CT information. I see this:

When I look for my certificate at https://crt.sh, I can find it. Also, the log operator (log.certly.io) is included in Chrome as well (see: http://www.certificate-transparency.org/known-logs). Is there something I missed? Is there additional configuration on server-side needed?

1 Like
2

Hello;

Certificates are correctly sent to log; but let’s encrypt does not yet include the SignedCertificateTimestamp in the issued certificate or in the OCSP.

I managed to make it work by resubmiting my cert+intermediate to log (log.certly.io); Got the response and encoded a PEM TLS extention with this signature into serverinfo.pem

In apache i did not used the mod_ssl_ct (that seems to me a bit overkill), but added a SSLOpenSSLConfCmd ServerInfoFile /path/to/serverinfo.pem

It works now see http://imgur.com/eTdmhnw

You can check that your server is sending this by using openssl s_client -serverinfo 18 -connect serverr:443 -servername server < /dev/null

you shoud get a
CONNECTED(00000003)
-----BEGIN SERVERINFO FOR EXTENSION 18-----
[data]
-----END SERVERINFO FOR EXTENSION 18-----
depth=1 C = US, O = Let’s Encrypt, CN = Let’s Encrypt Authority X1

I guess let’s encrypt may start to use ocsp later ?

3 Likes
3

You need to transfer the timestamp somehow, e.g. by using OCSP Stapling. But as @jbvignaud said, there seems to be something missing. @jsha @schoen

1 Like
4

Thanks for the explanation. It works for me too now.

5

Working log servers for let’s encrypt are:

log.certly.io
ct.googleapis.com/aviator
ct.googleapis.com/pilot
ct.googleapis.com/rocketeer
and ctlog.api.venafi.com (but included in chrome M47)

The other one like ct1.digicert-ct.com/log ct.izenpe.com and ct.ws.symantec.com do not handle DST Root CA X3.

1 Like
6

@jbvignaud: You’ve got it exactly correct, thanks for providing such detailed info! Let’s Encrypt currently submits to logs but does not provide SCTs. We eventually plan to provide SCTs in OCSP responses. This has mostly been a matter of prioritization for launch. Additionally, the Golang OCSP library does not yet support extensions, which we will have to fix before we are able to provide SCTs via OCSP. If anyone would like to volunteer to implement that, it would be very helpful!

Thanks,
Jacob

1 Like
8

I’m assuming test.com isn’t your real domain name … you need to change that to the correct domain name first

9

thanks for replaying , test.com its web server i create locally in vm inside my laptop under centos 7 for testing ,so can i test it or should i have domain (real domain ) for testing .?

10

You need to have a real domain, that is accessible from the general internet in order to get a certificate.

I would also suggest testing with the staging / test server so that you don’t hit the rate limits.

11

can i use sub domain to test ?

12

Yes, as long as it's publicly available

13

This is most certainly NOT te place to discuss this error… It has nothing to do with Certificate Transparency.

1 Like
14

Agreed. Locking this (old) thread.