Tag Info

Hot answers tagged

192

It is already done: It is the FPKI root CA, under explicit and full control of the US government. Windows already trusts it by default. Before you flip out and begin to delete root CA certificates, burn your computer's motherboard, or drink a gallon of vodka, think about what it means. It means that the US government could technically emit a fake ...


64

It sounds like your issue is that this vulnerability is bigger than you know what to do with. The rules of responsible disclosure, as decribed here, say that you should contact the vendor and negotiate a period of time - between 1 week and 6 months, depending on the depth of the changes required - in which they can implement a patch, revoke and re-issue ...


59

In essence, these certificates are necessary and required for backward compatibility with XP and Server 2003. If anything was signed with these certificates, even if they're expired now, your server needs the cert trusted in order to trust the thing that the cert signed. Source: http://support.microsoft.com/kb/293781 Some certificates that are listed in ...


43

You are right assuming the certificate is useless without the private key, so sending it in the mail is no big security risk and is common practice actually. The certificate is supposed to be public, connecting to your website would also provide me with your certificate, so no need to hack your email there. edit When starting the connection the server ...


34

The NSA could and probably already has gone -- using a USA PATRIOT Act demand letter, or other similar legislative tool -- to all the major CAs in the United States (e.g. VeriSign, GeoTrust, etc.) and demanded that they remit their private root keys to "No Such Agency", "for purposes of 'national security'". Of course, all such requests must (per PATRIOT ...


33

Such a claim is generally quite serious. While reaching out to the vendor in question is a responsible matter, you should certainly consider notifying the relevant root store security teams, since they are responsible for designing, evaluating, and applying the security controls to prevent this, and will likely need to directly work with the CA to ascertain ...


29

Yes, what you are getting in the zip file is exactly what every visitor to your site would get every time they start a TLS session - the public keys with certifying information. The private key is the only thing that should be kept hidden from unauthorized access.


28

Mostly yes, any CA in your trusted root, (or subordinates) can issue a cert for any DNS name. Name constraints and Enhanced Key Usage can be used to mitigate this, but they aren't enforced everywhere. DANE, Certificate Pinning, and Certificate transparency are a few projects that help protect from this risk.


24

Solved. The problem was indeed triggered by installing Apple Mavericks/ML Security Update 2015-004. As mentioned in this Apple release note, it included updates to the certificate trust policy. There was a duplicate certificate installed (with a wrong serial no.), removing it fixed the problem. The serial number for the cert as published by Apple matched ...


23

Congratulations! Sounds like a major find. First, generate some proof. The github.com SSL certificate sounds like a great start. Make sure you keep all the network traces you need to show exactly what happened. You need to determine if you broke any laws or T&Cs while doing this. If the CA does not have a bug bounty, you almost certainly did. In that ...


22

Certificates are signed and the cryptographic signature is verified; if the signature matches then the certificate contents are exactly as they were when the certificate was signed. This, of course, does not solve the problem, it merely moves it around. The complete structure is called a PKI. The certificates which are preinstalled in your computer (came ...


20

You can add, for example the -sha256 flag to the OpenSSL command line when generating the CSR. I don't believe any CA will change how they sign your CSR based on this, and it certainly won't affect the certificate chain. They're not resigning the cert chain for each key, the only signature operation they do is on your CSR itself. Any intermediate/root CAs ...


20

There is a standard for that, and, more generally, for all communications with a PKI. It is called CMP. Revocation requests are specified in section 5.3.9. Now, finding a PKI that actually implements CMP... this may be challenging.


18

When unsure, you can also contact CERT: https://forms.cert.org/VulReport/ They have experience in dealing with even very serious security vulnerabilities, and are generally considered a trusted party. At least they can confirm that your assessment of the vulnerability is correct, and document your part in finding it. While CERT generally advises you to ...


17

Can any CA sign any cert for any domain? In general, yes. Trusted root certs are trusted for anything under the root. If the answer is yes, what prevents having two different CAs creating a valid cert for the same domain? Nothing - it's completely legitimate for you, the owner of example.com, to go get a certificate for www.example.com issued by ...


15

It's prevented through legal (contractual) and not technical means. What happens if a CA creates an certificate which is not duly authorized by the legitimate domain owner: Time passes, with users unknowingly trusting the fraud. Somebody notices and reports it. Browser vendors remove that CA's root certificate from the next update to the trusted list All ...


15

Google blogged about flagging Certificates using SHA-1 here -> Gradually sunsetting SHA-1 There's no reason to get a new certificate yet as Chrome won't be actually blocking the certificate just treated as “secure, but with minor errors”, I believe that some issuers are offering to reissue certificate but as always, YMMV.


14

There is nothing at all wrong with running your own internal certificate authority; the vast majority of large companies that I have interacted with have their own internal CA. Advantages The nominal cost of a cert becomes nearly zero when amortized over enough systems and users; when you purchase certificates from an external CA, this will never become ...


13

No. In addition to the obvious government Root CAs in your trust stores; the NSA is a spy agency and as such has likely already stolen the private keys of several other CAs. If they are devious, they'd steal the private keys of other government CAs for potential false flag operations. Additionally, unless every operating system and browser explicitly locks ...


10

So we had to install their root certificate "PrivateCompany Root CA" to our web server. Why? Globally trusted CAs are useful in general purpose clients like browsers. But if you consume specific web services from a custom client you can add that CA locally. Every decent SSL client allows you to influence certificate validation. For example by ...


10

There are multiple ways to exploit a compromised certificate. If you have a compromised website certificate, you need to get people onto your server when they type the address of the compromised one. This can be done: By getting control of a DNS server, there you can basically change the association of a website URL to your server IP address. By ...


10

First of, CRL do not cover root CA. By definition, a root CA is a root: it has no issuer except itself. A CRL conveys revocation information, which is a way for a certificate issuer to announce that a previously issued certificate should be considered as invalid even though it looks fine and its signature is correct and everything. Thus, a CRL that talks ...


8

The server always sends a chain. As per the TLS standard, the chain may or may not include the root certificate itself; the client does not need that root since it already has it. And, indeed, if the client does not already have the root, then receiving it from the server would not help since a root can be trusted only by virtue of being already there. What ...


8

If you follow the links from the first Wikipedia link you provided, you'll find the spec for the ACME protocol that Let's Encrypt will use. And what it says is: Because there are many different ways to validate possession of different types of identifiers, the server will choose from an extensible set of challenges that are appropriate for the ...


8

Public Key Cryptography designates the class of cryptographic algorithms that includes asymmetric encryption (and its cousin key exchange) and digital signatures. In these algorithms, there are two operations that correspond to each other (encrypt -> decrypt, or sign -> verify) with the characteristic that one of the operations can be done by everybody while ...


8

If someone steals a CA's certificate signing key, the already signed certificates remain valid. But that doesn't mean they are not harmed. The whole point of certificates is that only a trusted party can produce them, so that when you see a certificate, you can be confident that it is valid and that you're talking to the entity you intended to talk to. If an ...


7

It's a rather short list: ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ Now that's the fixed and static list. But: contact info from WHOIS is also legal. From the CAB-Forums' Baseline requirements, page 17: 11.1.1 Authorization by Domain Name Registrant For each Fully-Qualified Domain Name listed in a Certificate, the CA SHALL ...


7

You don't need to get another new certificate. In order to resolve this issue, you need to just reissue your certificate with SHA-2 signature. That's it.


7

Unfortunately, this won't do anything to fix the problem, and might even make things worse for you if you don't set things up properly. Certificates are designed to provide assurance that the public key your connection is encrypted with actually belongs to the server you are trying to connect to. It does this by using a signature from a third party ...


7

This is not for "certificates above the end-entity" but for "root certificates" only. In pure X.509, there is no such thing as a "root certificate". There are certificates, and there are trust anchors. A certificate contains a public key, the name of the entity that owns that key, and is signed by another entity (an "upper certification authority"). This ...



Only top voted, non community-wiki answers of a minimum length are eligible