Hot answers tagged certificate-authority
111
Serious certification authorities use heavy procedures. At the core, the CA key will be stored in a Hardware Security Module; but that's only part of the thing. The CA itself must be physically protected, which includes proactive and retrospective measures.
Proactive measures are about preventing attacks from succeeding. For instance, the CA will be stored ...
54
A good question. The simplest answer is that having an expiration date ensures that you have an "audit" every so often. If there were no expiration date, and someone stopped using a certificate (and protecting the private key), no one would ever know. However, by having an expiration date you ensure that the user goes back to the company that sold them the ...
40
When a certificate is expired, its revocation status is no longer published. That is, the certificate might have been revoked long ago, but it will no longer be included in the CRL. Certificate expiration date is the cut-off date for CRL inclusion. That's the official reason why certificates expire: to keep CRL size bounded.
(The unofficial reason is to ...
31
Disclaimer: This answer comes directly from the eHow article. No infringement intended.
Domain Validation SSL Certificates
Domain validated SSL certificates are used to establish a baseline level of trust with a website and prove that you are visiting the website you think you are visiting. These certificates are issued after the SSL issuer confirms ...
24
Update 5 The root problem (heh) with the CA model is that in general practice, any CA can issue certs for any domain, so you're vulnerable to the weakest link. As to who you can trust, I doubt that the list is very long at all, since the stakes are high and security is hard. I recommend Christopher Soghoian's post on the subject, which clarifies the ...
20
On the physical side they first keep the root CA completely offline. Typically what happens is that they set up the root CA, make subordinates, then take the root CA completely offline and take the hard drives and HSMs (sometimes even the whole server) and essentially lock them in a safe.
Next, they segment the network to keep those subordinate/issuing ...
18
For the purposes of this discussion there are only a couple differences between web signing certificates:
Extended vs standard validation (green bar).
Number of bits in a certificate request (1024/2048/4096).
Certificate chain.
It is easier to set up certificates with a shorter trust chain but there are inexpensive certs out there with a direct or ...
17
Option 3 is that they don't want to put all of their CA eggs in the same basket. I know that various Apple.com certificates - all apparently legitimate - are issued by different CAs, so it could just be that these companies do not want to depend on a single supplier.
Why not? Well imagine that one CA is compromised, or goes out of business, or fails some ...
16
It is ultimately the responsibility of the client's user to check the validity of the certificate.
As a service provider, apart from educating the user if you can, there is not much you can do on your side:
you don't control which certificates are trusted by the user's browser and you can't know whether the users
have verified they using SSL/TLS properly and ...
15
Using an SSL certificate for your websites primarily gets you two things:
Identity proofing that your website is who it says it is
Stream encryption of the data between the webserver and the client
By doing what you propose, which is normally called self-signing, prevents you from relying on the identity proofing. By using a known trusted CA the client ...
15
At the byte level, X.509 is X.509 and there is no reason why the free SSL certificates would be any better or worse than the non-free -- the price is not written in the certificate. Any certificate provider can fumble the certificate generation, regardless of whether he gets paid for it or not.
The hard part of a certificate is outside of it: it is in the ...
14
Must/should I fetch all CRLs of the complete chain to check the certificates validity?
Absolutely. A CA builds a CRL only for the certificates it issues. Status of the CA itself must be checked via the CRL of the issuing CA. Note: This is a recursive search. When writing code, or testing systems, remember that there can be more than one "generation" of ...
13
I'm afraid that the short answer to this question is that it's impossible to know, as far as I can see. There are a large number of default CA's installed in most common browsers and assessing how likely they are to be "trustworthy" in terms of giving out certificates to governmental or other organisation is difficult.
If a CA became known as untrustworthy ...
12
Yes, you should fetch all CRLs for all certificates in the chain. A certificate can be deemed usable for any purpose, including verifying other certificates, only if it can be plugged at the end of a valid certificate chain and its revocation status has been ascertained. Of course, a CRL must not be trusted unless its signature can be verified with regards ...
12
Yes, it can be issued.
Luckily the common browsers do not accept wildcard certificates for TLDs.
Chromium Source Code:
DCHECK(reference_domain.starts_with("."));
// We required at least 3 components (i.e. 2 dots) as a basic protection
// against too-broad wild-carding.
// Also we don't attempt wildcard matching on a purely numerical hostname.
...
12
Well, technically, if the user cannot confirm the identity of the certificate owner, then the communication cannot be really secure, because a villain may impersonate the server; he may even relay the data to the right server transparently (that's the man-in-the-middle attack model). Making sure that you talk to the right server IS an integral part of the ...
12
The communication is still encrypted, but the trust mechanism is undermined. But usually the most important factor is that the users will ugly warning messages about the security of your site - and most won't make informed judgements about the integrity of the connection - they'll just go buy stuff elsewhere.
12
On a theoretical basis, an expired certificate is a certificate which must not be used any longer. This is made explicit in the the Internet X.509 Profile in the certificate validation algorithm (section 6.1.3, item a.2). In practice, this has two consequences:
The key owner (the server) must keep its private key, well, private. Anybody who gets a copy of ...
12
SSL is based on public/private key cryptography. This means that
anything encrypted with a public key can only be decrypted with the associated private key
the private key can be used to sign a something and that signature can be verified with the public key.
A certificate is a public key with information about the owner attached to it. The owner can ...
11
The fingerprint, as displayed in the Fingerprints section when looking at a certificate with Firefox or the thumbprint in IE is the hash of the entire certificate in DER form.
If your certificate is in PEM format, convert it to DER with OpenSSL:
openssl x509 -in cert.crt -outform DER -out cert.cer
Then, perform a SHA-1 hash on it (e.g. with sha1sum1):
...
11
If there was a universal five-day grace period, nobody would notice the certificates' expiry until five days later, leaving you with an identical net effect to refusing an expired certificate immediately. It's the fact that SSL connections stop working that creates the pressure.
I suspect it would be more productive for SSL client applications to warn ...
10
As discussed on the original version on stackoverflow:
It all comes down to who you trust. Some organisations will trust government, while some definitely won't. Some will trust a bank in this role, but would a competitor trust them? I have seen many banks set up their own PKIs or use a PKI vendor - and the physical security requirements around root CA ...
10
Certificates do not provide encryption. Encryption comes from SSL itself. The certificate is about convincing the client that the data it dutifully encrypts is really sent to the genuine intended server, and not somebody else impersonating the server. A certificate for a SSL server can use a key which works only for digital signatures (e.g. a DSA key) and ...
10
hackedirl means HackedIRL -> Hacked In Real Life
It is a name used by sites of the Cheezburger network (fail blog and others) - just a funny name, nothing to do with hacking.
The reason you see all these IPs is that Cheezburger network uses the wordpress platform for the content of its sites and wordpress does load balancing and redundancy using DNS.
...
10
Note: This is a (very very long) compendium of various recommendations and actions that Microsoft, NIST, and other well respected PKI and cryptography experts have said. If you see something that requires even the slightest revision, do let me know.
Before I get into configuring the CA and its subs, it's good to know that even though MSFT's CryptoAPI ...
10
The handshake includes these (rough) steps:
The server sends its public key.
The client encrypts setup info with that public key, and sends it back to the server.
The server decrypts the client's submission and uses it to derive a shared secret.
Further steps use that shared secret to set up the actual encryption to be used.
So the answer to your ...
10
Not every CA (government, commercial, or private) stores private keys the same way. Most legitimate operators use a HSM. It's possible that the vendor publishes CRL revocation lists using a one way link from the root to the SubCa. (Transmit-only serial cables, audio cables, QR codes, Ethernet with only a few pins connected.... etc.)
To get specific then ...
9
One of the only reasons you buy SSL certificates (and don't buy rsa/dsa keys) is for the trust relationships.
If you can securely import a self-signed SSL cert into your browser and install the SSL cert on your web server, there is no reason to involve anyone else.
See AviD's comprehensive description of SSL for more information. What SSL provides:
* ...
9
Short answer: Yes, there is some potential benefit for end-entities to choose a public key that is larger than the CA's public key.
The question is not entirely clear, but I presume your situation is that the root or parent uses a 1024-bit RSA key (i.e., the end-entity's cert is signed with a 1024-bit RSA key), and the end-entity uses a 2048-bit RSA key ...
9
Perhaps you're ending up at different web farms. A site as big as facebook will not have a single point where they offload SSL, so they can either install the same certificate and private keys in all SSL endpoints, or use different certificates. As long as they're signed by a CA in your browser, you normally won't notice the difference.
Only top voted, non community-wiki answers of a minimum length are eligible
