Certificate transparency: Why fully random serial numbers and seperate hosting?

They even require it for getting an good security rating in chrome for your side.
I implemented CT and OCSP-Stappling in java for my side. And now also CHACHA20_POLY1305.

I didnt ask why CT was made. I ask why the concet HOW CT was done was changed.

also @tlussnig zje serial numbers werent easily guessable since a part of the number was always random.
let’s look at the hello world LE cert which also was the example then.
the serial is 01:00:00:00:00:00:00:15:4F:F8:F2:23:AE:7F:FA:BC

let’s explain it from behind, makes more sense this way.
the complete second half of the number (4f until BC) is randomly set proably so you cant guess the serial number.
then the 00:00:00:00:00:00:15 is just an increasing number which means the hello world is the 15(hex)th so the 21st cert that was issued, well not exactly because:
so we had 01 as the “location identifier” which probably means they use multiple servers to generate the certs and so the the increasing numbers dont overlap on multiple “locations” because they are made to generate certs simoultanerously and get out of sync we have this.

so every cert could be downloaded somewhere on LE using the first half of the serial number and we had it.
the best thing of this approach is that since the CT is technically on-premises you dont get a problem with CT when something happens to their server or the connection to them.

now the main question is WHY did you switch to a 3rd partx CT provider and completely randomized the serial numbers?

I think this could be related to this:


CA / Browser Forum Baseline Requirements, v. 1.0

9.6 Certificate Serial Number
CAs SHOULD generate non-sequential Certificate serial numbers that exhibit at least 20 bits of entropy.

1 Like

so now check this.

the serial number is not sequential. just a part of it.
also the random part is 8 bytes (64 bits) long and it shouldnt be hard to get an entropy this long. (attack a mic to the server and try to get it hooked into the entropy and then you have a near perfect random number generator (maybe)

This is from the pure definition point correct. But from another perspective you can say you have an sequential number plus an 64bit random value. With you argument i can build <M/W> as anonymized id. And say you
have an random password. Even if it contain gender and birthday is contained it is an random number. And per definition an random number mean there is no usable part in it.
I think the discussion why some part that should not have an sequential meaning only serial number can let you think.
is not really important.

The incrementing serial prefix was originally a solution to allow people to quickly enumerate all the certificates we issued, as you’ve mentioned @My1. Unfortunately this design decision added a number of points of failure in Boulder that were really unnecessary.

Instead of attempting to maintain this solution with a somewhat flaky fix we chose to instead submit all issued certificates to CT logs and use a (almost) fully random serial. This adds a slight hurdle to people who may want to find all our certs but it is one of the main functions of CT and removes a set of problems we bound ourselves to with the incremental approach that have greatly simplified our design.

4 Likes

finally an explnation from someone in here that’s even remotely on the topic.

and it even makes sense, not a lot of developers can finish both points in their messages. :smile:

thanks @roland

[OffTopic]
Just a completely off-topic note about CT. Because of bad practises by Symantec Google requires CT after une 1st, 2016 for all certificates of them: https://googleonlinesecurity.blogspot.dk/2015/10/sustaining-digital-certificate-security.html

1 Like

I dont know who renamed the topic, but (for clarification) it wasnt only about the serial numbers but also about why it was stopped hosting the certs directly at LE but using a cert provider.

as I said before @roland already answered the question.

@riking changed it. You can see it when clicking on the orange pen at the right top of your first post.
I’ve changed it a bit.

wait YOU CAN CHANGE A TOPIC TITLE? (shouting in surprise) but you arent a mod (at least you dont have a shield…

BTW LE is still hosting the certs. Or better issuing, because you host the public/private keys yourself…

Yes that’s a feature of DIscourse (the forum software used here), because it allows the self-managment of communities like this. (which is IMHO a very nice idea)
In this example it allows users of a specific rank to edit all titles of any topic.

More details:

well they obviously still issue the certs (that isnt the issue) but with the previous CT model they also hosted all certs where you had them under letsencrypt.org / some-path /

I was just wondering why it was changed completely and it makes sense.

“host” is the wrong word. They save a copy of them in the CT logs or better: they “publish it in the CT logs”.

I know no CA which does or did publish it like this. And as this is not standardized and has no sense I am aware of I’d say this would be quite useless.

This is no change - it’s an addition. To be more exact: An additionally security feature.
To read more about “why it makes sense” (how it works) have a look at the wikipedia article:


and the official domain: https://www.certificate-transparency.org/

well before they had pretty much their own CT log which doesnt look like a problem to me…

I don’t know what problem you see with CT logs.

Edit: How do strike that through?
Edit2: Found out.

I dont have an issue with it I was just surprised since they upside-down-ed their whole CT model and wanted to know why, which was (as I already said) answered

@rugk There’s no problem with CT logs. LE had an API to download all issued certificates before. As it sounds, it’s gone now. The question was just about the reasons behind that change.

@kelunik FINALLY someboy who understands the purpose of this topic *tears of joy* (how to escape an asterisk?)