Generate a certificate without Certificate Transparency

#1

Hey, I’ve deleted all of the pre-inserted questions because I don’t need help with a specific case but have a more general question.
Using your service and cli tool certbot - would it be possible to generate a certificate without the Certificate Transparency field?
I mean for my own domain, after I pass the test that proves that I own the domain name.
I’m fine with the data being recorded in a CT log and being available to the world but I’d like a certificate that doesn’t have the CT field in it (the hash that proves that it was logged), or perhaps has an invalid CT hash.

I’m interested in it for research purposes and I can’t think of a way it would risk anyone.
Would that be possible? I couldn’t find any relevant certbot flag for it

1 Like
Will you support Certificate Transparency?
#2

it won’t trusted by browsers

1 Like
#3

Hi @RefaelF

simple answer: That’s not possible. You have to accept that Letsencrypt certificates are logged.

Read

If you want a “more private” certificate, then use the test system and add the Fake Root to your browser. These certificates are logged too, but there is no public CT monitor (or I don’t know one).

1 Like
#4

Thanks for the ultra quick responses guys.

orangepizza
Yup I know, as I’ve mentioned it’s for research purposes and not for a publicly available commercial website.

JuergenAuer
As I’ve mentioned I’m fine with it being logged I just don’t want the proof of it to be stored in the certificate itself (in the “SCT List” field).

Let’s say I (as the website owner) would like to pass the SCT as a TLS extension, which is completely valid and supported by browsers, instead of an X.509v3 extension - Would it be possible?

#5

Is there a RFC? Or are you a browser vendor, so you are able to implement such an extension without having a RFC?

1 Like
#6

https://no-sct.badssl.com/ had vaild digicert cert that no stapled sct for CT (but still loged in CT)
maybe ask them for this?

#7

JuergenAuer
There’s this: https://tools.ietf.org/html/rfc6962#section-3.3.1
And the newer version: https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-30#section-6.4
And this section: https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-30#section-8.1 states: “CT-using TLS clients MUST implement all of the three mechanisms by which TLS servers may present SCTs”.

I’m not sure if a more thorough RFC or further explanation exists for the implementation of CT as a TLS extension but browsers should support (not sure if already do or will, at some point) all 3 techniques: TLS extension, OSCP and X509v3 certificate extension.

I’m not a browser vendor, just trying to find out if let’s encrypt enables the support of the other 2 CT techniques (other than X509v3 certificate extension) by allowing not to include the CT hashes in the certificate extension.

orangepizza
Yup I know badssl and this test page of them, wanted to check it it’s possible to get one using let’s encrypt instead of DigiCert, but anyways I’ll ask the people behind badssl, thanks

1 Like
#8

These certificates may be “hand made”.

And Chrome doesn’t like the domain:

NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED

com
2019-12-04.no-sct.badssl.com.png1094×592 32.6 KB

#9

hmm. mobile version of chrome don’t care about it.

Screenshot_20191205-001507_Chrome
Screenshot_20191205-001507_Chrome.jpg1080×1920 227 KB

#10

Yup this is exactly what I’m looking for, I’d like to generate a similar certificate.
Chrome doesn’t like it because the server didn’t send the SCT in any of the other 2 ways.
I guess that in Chrome mobile they don’t enforce it, just like Firefox, IE and Edge.

Anyway perhaps I’ll try to open a new topic in feature requests for it? I need it now for research purposes but I guess that if there are 2 other ways to implement CT, the certificate extension shouldn’t be mandatory by let’sencrypt because some people might need one of the other two (perhaps for better performance or who knows what)

1 Like
#11

The best way to do this since you are operating an internal only site is to operate your own PKI. I run an offline root with an intermediary run by active directory certificate services.

Let’s Encrypt issuing certificates without CT is dangerous and breaks the whole promise of CT. Imagine a malicious actor gains control of your dns for 30 seconds, they could issue multiple wildcards without CT you would be unable to detect or revoke.

#12

As I wrote before, I agree that the certificate creation should always be logged by the CT servers, I just wanted to have the option to not include the SCT hash in the certificate afterwards.

Yeah my own PKI with a self signed certificate was always an option, was just interested to know if Let’s encrypt supports it.

#13

Hey @RefaelF, thanks for posting your question.

Sorry, we don’t support issuing certificates without the embedded SCT list extension and aren’t likely to add support. I think the majority of our users are best served by embedded SCTs and increasing the complexity of the issuance path in our CA software to accommodate alternatives is high risk work that we tend to be very conservative about.

Hope that helps, sorry for the bad news :slight_smile:

4 Likes
#14

Thanks for your reply @cpu . Yeah I get it and actually see no reason to use any other way since the other two require server-side changes.
So just to make sure, OCSP stapling is not supported right?

This used to be the official response: “If we provide SCTs, it would be via OCSP, definitely not by X.509v3 extension” :slightly_smiling_face: long ago

1 Like
#15

That’s correct.

wow that’s a blast from the past! :laughing:

That discussion pre-dates my involvement with Let’s Encrypt by a bit under a year and I’m not sure I’ve read that thread before today. I don’t know off-hand what caused our implementation plan to change but maybe @roland or @jsha can add some more context.

2 Likes
#16

That thread pre-dated browser enforcement of CT for DV certificates. My thinking then was that if browsers weren’t making use of it, I didn’t want to bulk up our certificates unnecessarily.

I suspect at the time I was also hoping that we could incentivize very widespread adoption of OCSP Stapling, which would improve privacy and reduce dependency on our OCSP resolver. I may have figured that if we made SCTs available over OCSP, that would be a strong encouragement, once browser enforcement did roll out, for subscribers to implement stapling.

Since then we’ve found that stapling is poorly implemented in a lot of web browsers, and concluded that we’re not likely to see most subscribers implementing stapling.

And also, of course, browsers started enforcing CT. When that change was announced, we wanted to make sure all of our subscribers’ certificates would keep working without onerous interventions, so we chose the X.509v3 extension approach, as did most CAs. We decided that we didn’t want to implement an option to leave the SCTs out of the cert and deliver them in OCSP, because this would have added considerable complexity to our issuance and OCSP signing pipelines for very marginal gains.

4 Likes
#17

@roland reminded me that our other, probably more significant, concern at the time was that, to embed SCTs in X.509, we’d have to block issuance on getting SCTs. In the absence of enforcement, that felt like it would put pressure on availability and issuance latency without a corresponding gain. Of course, with enforcement on horizon that calculus shifted. We’ve been happily surprised by how little CT submission has affected our availability. We have had some small outages due to CT submission but overall it’s been fine.

1 Like