Hot answers tagged

22

The answer by user2320464 is good, but I'd like to expand more. Summary: The certificate holder generally does not manage their own revocation information, because the whole point of revocation is to announce that holder of this certificate is not trustworthy. The rightful owner of the cert needs to be able to declare the cert Revoked, but in a way that ...


14

Yes, StartCom is a legitimate Certificate Authority. On the plus side, they were at one time the only provider which would hand out free SSL certificates which were recognized by the major browsers. (There's competition now in Let's Encrypt). On the minus side, their web site design and implementation is clunky, non-intuitive, and lacks pretty. (The ...


6

This is an awesome idea - to manually trace through the cert validation process! I've enjoyed reading through your steps, since I've never actually done it myself! Answering your questions: First question: Is this the correct way of obtaining the certificate the *.wikipedia.org certificate was signed with? After all, how can I be sure ẁikipedia.org didn'...


5

Typically certificates are revoked by the person being issued the certificate. So if you were to purchase an SSL certificate and later found the private key was compromised, then you would revoke the certificate. This action would be recorded on the "Issuing CA" where the serial number of the newly revoked certificate would appear in the Certificate ...


5

First off, let's be careful about language, when you talk about a public CA like Entrust, or Verisign, or Digicert, yes there is some software involved for actually creating and managing the certificates, but you're really talking about the people. These companies are trusted CAs not because of the software they use, but because their network admins take ...


4

In order for that to succeed the server's hostname would have to match the certificate name. That means you would have to either get a CA to issue a cert as google.com (not likely to happen) or you would have to get a root cert from a CA you control and install that on the user's computer as a trusted CA certificate. Even then, many big web sites use ...


2

In case of cacert.org, they are presenting a self-signed certificate and that's why your browser complains. There is no trust chain that leads from the certificate to a root CA that you trust. If you were using a Linux distribution that comes with their certificate pre-installed, you wouldn't see a warning. It would be inferred that by using such a system ...


2

It is the responsibility of the person who bought the certificates to ensure the security of the cert. It is the responsibility of the CA to revoke any certificates that were sighted breaching the terms of service. A certificate is a lot like a driver's license. If someone steals it, you have to report it.


2

Since there is no way to cryptographically invalidate a certificate, a system must be used to publicly announce the revocation of a certificate. The Online Certificate Status Protocol (OCSP) is the current way of doing this. Browsers can check an OCSP provider to confirm that a certificate is not revoked before connecting to a website.


2

I believe you're asking the wrong question. The right question is "Should someone new to security be working on a root CA?" and the answer is "probably not." It is highly likely that what you're doing will expose everyone who relies on your root CA to high risk of compromise. This has been demostrated by mature companies like Dell (see, for example, http:/...


2

Yes, StartSSL belongs to a StartCom - a legitimate certificate authority Here some points how one can notice it is a legitimate site: They use an EV certificate. As they are a CA they of course signed the EV certificate by theirself and as the HTTPS connection succeeded you also know your browser trusts that CA. They have a Wikipedia article There is also ...


1

The website operator is responsible for notifying the CA to revoke the certificate, and would usually reissue a new Certificate at the same time. The CA is then responsible for publishing this information through CRL and/or OCSP. The client application is responsible in fetching the CRL/OCSP status of a Certificate from the CA. In some rare cases, the CA ...


1

Your question about when / how to renew the CA key is a good one, but I'm afraid that it doesn't have a generic answer; it depends on which applications are consuming those certificates and how they expect a CA to behave as it approaches its end-of-life. One thing that is universally true is that end-entity certs should never outlive any CA in their issuing ...


1

Five years is a long time in Information Security. Ten years will see the security world decide that some algorithms and keys are too easily compromised. I have a client who had implemented SHA1 hashes in each tier in order to support unpatched Windows XP using a PKI environment that was built within the last four years. We had to rehash each CA's ...



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