The CT endpoints are correct, however you need to access it with the correct paths and parameters instead of the root endpoint.
For example, to access the STH (signed tree head), you use the URL: https://ct.googleapis.com/pilot/ct/v1/get-sth
Or to access log entries numbered 1000 to 1100: https://ct.googleapis.com/rocketeer/ct/v1/get-entries?start=1000&...
Doesn't look like gossiping is going to happen at scale
I think Emily Stark is in charge of CT on the Google Chrome side. And I think CT was largely a Google brainchild, so she is probably a good person to listen to.
And she wrote a nice primer on CT last year:
Gossip is ...
Searching for the term 'gossip' in the chromium and Firefox sources gives no relevant results. Nor can I find any other reference to gossip in browsers elsewhere. So I believe browsers have not implemented any form of gossip yet.
In fact, there has been no ultimate decision on gossip yet, since RFC6962 says that all CT clients should gossip, and that the ...
As of today (January 25, 2018), adoption of Certificate Transparency is not ubiquitous, but it is starting to gain momentum. Let's Encrypt logs all their certificates to CT logs, and several major CAs like DigiCert and Comodo run their own CT logs. Google Chrome already displays Certificate Tranparency information in its Dev Tools, and Firefox plans to add ...
Since I can't comment, apparently, I want to clarify a couple of points.
CT does not require all browsers to use it: there is a herd immunity conferred even if only one browser does it. And, BTW, Chrome's next release includes CT support.
Webservers do not have to change to support CT - CAs can include the SCTs in issued certificates. Some CAs already do ...
Certificate Transparency is a heuristic defence mechanism which does not detect misissued certificates; instead, it strives to allow faster detection of misissued certificates.
The core idea is that of Glasnost. It so happens that most successful attacks rely on an asymmetry of information. Suppose that I want to impersonate Google's server. Through ...
Certificate Transparency solves a different problem from CRLs and OCSP.
OCSP and CRLs handle the problem of certificate revocation. The CA is offering resolution for mistakes and bad actions on the part of the CA's users. That is, the CA is assumed to be infinitely trustworthy, but a certificate may need to be revoked because of poor key management or some ...
CABForum "Baseline Requirements"
TLS certificates on The Web are governed primarily by the CA-Browser Forum Baseline Requirements, which all publicly-trusted CAs are required (by browser vendors) to follow.
In the Baseline Requirements (BRs), intermediate certificates are not explicitly required to be used at all. In theory, a CA could just sign ...
Will certificates from corporate (or "internal") CAs be rejected by Chrome?
This is already answered in the exact sentence you've cited: "... require Certificate Transparency for all newly issued, publicly trusted certificates ". Since internal CA are not publicly trusted no certificate transparency will be required for these.
Will every certificate ...
First, what stops me from setting up my own log, make the SCT, and never tell Google or anyone else about it?
Can the browser tell if a log is legitimate?
It's left unspecified in the RFC:
TLS clients [...] should validate the SCT by [...] using the corresponding log's public key. Note that this document does not describe how clients obtain ...
The aim of certificate pinning is to protect against malicious man in the middle attacks and not against legal content inspection as done in companies and also desktop antivirus for protection, where the certificates are issued by an explicitly trusted local CA. it does not matter here that legal protection methods might also be used to invade the privacy - ...
Certificate Transparency (CT) does not apply to non-public root Certificate Authorities. CT only validates that certificates issues by trusted public CAs were issued legitimately.
Your Burp Suite certificate is configured on your system as a trusted root certificate and no CT policy will therefore be applied to it.
The Mozilla MDN page on Expect-CT also ...
Why are some split into 202X series and what does the number mean?
Since certificate transparency logs can grow to include hundreds of millions of certificates, they are often split into separate physical logs (this is called temporal sharding). The number represents the year up till which the log is valid. Certificates are placed in different logs based on ...
From Announcement: Requiring Certificate Transparency ...:
This past week at the 39th meeting of the CA/Browser Forum, the Chrome team announced plans that publicly trusted website certificates issued in October 2017 or later will be expected to comply with Chrome’s Certificate Transparency policy in order to be trusted by Chrome.
Thus, the requirement ...
If you do interested in programmatic accessing CT logs then one possible way forward could be the lib I made CTjs. There you could find an an example how to use it - it is example using all possible APIs and features of CT log. Also there is RFC6962 example on a real data from all known CT logs.
PKI has two elements: the technical protcols and the procedures we build around them.
In the technical realm, things are pretty clear: you got mechanism that allows you to decide what to trust, when under what condition and how to communicate (most) changes in that trust system (CRL, OCSP, etc.).
These technical elements do not, however, cover the ...
So your question boils down to this:
We are a small CA supported by some browsers. We are trying to offer EV certs but are running into issues because we're not logging our certs to CT logs. How can we get the CT logs to accept our certs / SCTs?
I agree that it's surprisingly hard to find any information on this. My first hint comes from Chromium docs:
In short, no there is n't.
A bit longer, there is no repository of all root CA's certificates.
for example , private CA's are almost always not included in the CA list, also CA's with a limited scope are often not on those lists.
All major certificate keepers have there own list of CA's they thrust (and to what degree). This includes organizations like: ...
Depending on your application, you might not need "all" the CA certificates, but only the ones that you are able to trust.
You can use the Mozilla CA Certificate Store at:
Those are the CAs that are trusted in e.g. Firefox.
Chrome's Certificate Transparency policy describes the number of distinct Google and non-Google logs that the certificate must have been logged to at the time it was issued. Certs with longer lifetimes must be logged to more logs in order to be trusted by Chrome. This is a relatively new enforcement (April 2018) so it only applies to certs issued since that ...
As described here:
Google's first CT log.... Will log any certificate that is anchored in
a root trusted by one of the major browser vendors.
So I don't believe they'll accept arbitrary CAs.
You could get your root added to Testtube, a test CT log, but that may not be what you're looking for.
The operation of Certificate Transparency is specified in RFC 6962 and the submission method is specified in sections 4.1 and 4.2. A shortened version:
4.1. Add Chain to Log
POST https://<log server>/ct/v1/add-chain
4.2. Add PreCertChain to Log
POST https://<log server>/ct/v1/add-pre-chain
The format for the POST requests is specified in the ...
As long as the logs are recognised by the browser/software validating the certificate it wont matter which log was used, for example known logs used by chrome would make a log not on the list somewhat less interesting.
See nobody's answer
Certs are repeated in different logs for reliability, i.e. if one of the logs you used is offline, but the other is ...
Because I don't have uri here, the report will not be sent, so there
is no additional security at all.
You are right.
In case enforced is not specified, as in your case, and browser detects a CT violation, e.g. because a mis-issued certificate is used or because of misconfiguration of your web site, it makes sense to report it to the web site owner. Then, ...
It would not be noticed if a certificate is just issued. It would be noticed though if the certificate gets used in practice since the validation against the CT log will fail (it is not in there). And it will notice if there is no CT information in the certificate even though it is required for the CA.
For more see How will Certificate Transparency be ...
Yes, easiest way is to just compare public key in pre-certificate and certificate, as stated above. But the way could be wrong if CA issued certificate having incorrect pre-certificate data. Let me explain. Assume you have a TBS (ToBeSigned) part of the possible future certificate. Then CA makes pre-certificate from the TBS (append "poison extension" and ...
Check the public key, if they match, it is OK. At the end of the day, the key is the important part of the certificate, as if it is your key and the attacker therefore does not have the corresponding private key, the rest is not important.
Do not check the certificate ID as suggested, ID can be manipulated.
it gives public confirmation that the certificate
was indeed issued (and not only the pre-certificate)
To quote RFC6962bis (draft-ietf-trans-rfc6962-bis-28), section 3.2:
"signature" MUST be from the same (root or intermediate) CA
that will ultimately issue the certificate. This signature
indicates the CA's intent to issue the certificate. This