Concerns about Trustcor
groups.google.com
groups.google.com
Mysterious company with government ties plays key internet role : https://www.washingtonpost.com/technology/2022/11/08/trustco...
For example, do a search for 'google.com' and you'll see they don't have a single Google cert logged post 2020.
Sounds like they're useless, actually, considering typical certificate validities nowadays.
crt.sh does contain all the certificates the CT logs know about.
Google certs are there, just as any other: https://crt.sh/?id=7669606389
> ... I know you guys promote some kind of app security solution commercially, but I did note in my earlier response that our company and MsgSafe has never shipped an app that was not in BETA only and that the 5-year-old app beta was abandoned years ago.
Trying to ignore the fact that there might have been malware in a security-focused message application they shipped is concerning. (I _can_ imagine how it might have been done innocently - a beta intended to be internal-only w/ various metrics analysis et al, for example). It's hard to trust part of the business if a separate section of the company engages in that sort of behavior.
That said, their note about an unrelated party in the US registering the same name for a company in the US is really weird and concerning.
> Our attorneys believe someone could have done this (and it agrees with our event timeline we’re creating as we investigate) for physical actions taken and may have used this with insurance companies to obtain additional nonpublic information about our company and our insurance infrastructure which is large and complicated just like every CA’s insurance has to be.
This feels vaguely scary if you run businesses abroad with US-based hosting or physical infrastructure.
Browsers sending each certificate fingerprint (which can easily be translated to a hostname by building a database of certificates) to a server on the Internet has got to be one of the worst ideas in the history of information security. Yet more institutions knowing every domain you connect to is the absolute last thing we need.
CAs can all issue certs for any domain, right? I mean, there's these hacks that are supposed to restrict that, but it's optional. The browser trusts any cert that a CA has signed. And in order for a CA to let you create a cert, they have hokey, problematic methods to allow you to prove that you, temporarily, at the moment, control the IP space that is pointed to by whatever DNS server a given CA trusts, and hope that BGP and DNS do not lie to the CA. So 1) BGP has to be trusted, 2) the DNS has to be trusted, 3) the CA has to be trusted, and 4) a temporary check of an IP address needs to show something to the CA that they think is valid (among other hokey validation methods, like an e-mail to some predetermined address at a domain, or an HTTP GET to the aforementioned IP).
That's a lot of stuff that we hope is all valid and not been tampered with! (In fact, these things [and more] do get tampered with, and have been exploited in the past to generate certs illicitly) So how can we make things a little more consistent and secure? Well all of this trades on the idea that the CA is trying to verify that you, the person asking for a cert, really own and control the domain name that you are asking for a cert for. That's tricky, because the registrar and the nameserver are the only entities that can authoritatively say who owns and controls the doman.
So... why don't we just confirm, cryptographically, with the registrar and the nameserver, that the requestor of the cert is who they say they are? If the registrar keeps a key that the domain owner has uploaded [or signed], and the nameserver keeps a key the nameserver owner has uploaded [or signed], and you create a CSR (including what CA should generate your cert), get it signed by both the registrar and nameserver, and send it to the CA, the CA can verify it with the registrar and the nameserver, and the cert can include the CSR signature from the registrar and nameserver. So now anyone who gets the cert can confirm 1) who was supposed to issue it, 2) that the real domain owner signed the request, 3) that the CA confirmed all this when it issued the cert, without depending on BGP or DNS or HTTP.
.....this will never happen, of course, because there are vested interests, and it would take a lot of hand-wringing and agreements and modifications to policies and new software and all kinds of stuff to make that happen. So we will continue relying on BGP, DNS, and the integrity of a couple hundred CAs, to make sure nobody ever 'exceeds their authority' and issues a cert they shouldn't have.
As you've realised, the reason they cost "real money" measured in dollars is because of rent seeking[1] by a few large corporations. These guys have sufficient clout to (mostly) snuff out any upstarts. For example, their response to Let's Encrypt was to start pushing CAA records for "security". You guessed it: the security in that context is not referring to your IT security, but to their revenue security.
Similarly, Microsoft Azure has CA integration... with the two biggest for-money certificate authorities. There is virtually no chance they'll ever willingly integrate with Let's Encrypt or add support for the generic ACME protocol because there is no margin on free.
There's not much that can be done to fight this, but there are options.
As you've said, DNS name servers and CA functions need to be combined. It's almost gibberish to have these as separate services in 2022, since practically everything uses TLS, which needs both to act in concert.
In fact, DNS-based traffic management, static DNS, dynamic DNS, DHCP, IPsec management, and CA services should all be combined into a single executable. This way back-end machines could enroll in certificates at the same time that they get their IP addresses. Their IP addresses would be registered under their name, and load balancers can add their IPs to service pools. Etc...
Microsoft almost did this right, with LDAP + DHCP + DNS + Enterprise PKI being mostly integrated, but not quite.
Keep in mind that the era when these things "had" to be separate services was when DNS needed a dedicated bare metal machine for performance. These days the DNS zone of a large corporation fits in L2 cache and can run out of a fraction of a CPU core!
CAA easily supports several CAs issuing for one domain.
But yeah, not surprising then that they had the means to run a CA, too.
sudo dpkg-reconfigure ca-certificates[1] https://ccadb-public.secure.force.com/mozilla/IncludedCACert...
Such an incredible feat that it has never happened before.
A certificate tightly controlled by a three letter agency and used for spot interceptions on specific targets is very unlikely to be found.
Massive interception are likely to be detected nowadays, but the lone political opponent is still far from safe from them.
Generally, a 'pre' certificate is submitted to a number of logs by the CA. The log returns a signed timestamp. These SCTs (signed certificate timestamps) are embedded in the final certificate provided to the subscriber - and the browser can verify those. (The SCTs can also be stapled, and not signed into the certificate itself).