Tag Info

Hot answers tagged

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 ...


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 ...


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 ...


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

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

A CRL is an object which contains the list of serial numbers of certificates which have been revoked by a given CA. It is a signed object; the CRL issuer is usually the CA itself (with the same key) but this power can be delegated. An OCSP response is what an OCSP responder returns when it receives a request about the revocation status of a certificate. The ...


8

There's just no way to fix it. Even if the registration period is two years and a one year certificate is issued, you could still sell or drop the registration next week. There's nothing the certificate authority can do about that. (Well, I suppose they could monitor the registrations and if there's a change in registrant, they could revoke the certificate. ...


8

Yes, for your backend you can just generate self-signed certificates with OpenSSL as you have already done. The difference is that you then need to instruct your frontend servers to trust those certificates (how depends on the platform used). Alternatively you can set up your own private CA (certificate authority, e.g. Verisign) and have your frontend ...


8

Currently SSL works the way that there is always some English language country based company issuing certs based on their root key. Now this is all in the control of the goverment, because they can gain access to these keys upon request, and they have agreements to do it. However, for business this is not good enough, definitely. You're ...


8

There is a handy script distributed alongside openssl, CA.sh to do most of this stuff. Its location is distribution specific. In Debian and derivatives you can locate it using: # apt-file search CA.sh openssl: /usr/lib/ssl/misc/CA.sh And RedHat and derivatives the (approximate) equivalent is: # yum provides */CA 1:openssl-1.0.1e-4.fc18.x86_64 : Utilities ...


7

The important point is that the (only) purpose of the SSL certificate is to verify the identity of the server you're communicating with. Everything about the encryption and security of the connection is negotiated between the browser and server independent of the certificate. As long as the key embedded in the certificate is large enough and not ...


7

Segmenting the space of certificates so that "partial" CRL can be computed is possible and supported, but it must be done properly. One base principle of CRL is that a CRL should be amenable to processing regardless of how it was obtained: that's the whole point of having signed objects. Since a certificate is considered as non-revoked by virtue of not ...


7

X.509 validation is nominally disjoint from domain names. X.509 was designed in the context of The Directory, a mythical beast which can be thought of as a big, worldwide LDAP directory referencing every server on Earth and elsewhere. (Historically, it went the other way: LDAP is Lightweight Directory Access Protocol, a reduced version of the protocol which ...


6

One alternative is DANE/TLSA, which is a RFC standard that allows self signed keys in DNS. One of the challenges is that this is very new and most client software doesn't yet support it. (Chrome being a new addition) In addition DNS is subject to various attacks, especially on WiFi networks and the like. One way to remedy the DNS attack is to use ...


6

"Alternatives" depend on whether you want something which may work in the future, or something which works right now, with existing browsers. Right now, Web browsers expect that servers send X.509 certificates, and then they validate them against the set of root CA integrated in the browser (or operating system). This means that if you want something that ...


6

A certificate is only as good as whoever validates it thinks it is. A certificate is good for SSL as long as the SSL clients (e.g. Web browsers, or VPN clients) accept it as good. Whatever you do, the existing clients will lead the dance. A "wildcard" certificate is described in RFC 2818, section 3.1: Names may contain the wildcard character * ...


6

Depends on the value of the Certificate Basic Constraints field of your certificate. Most probably it will be Is not a Certification Authority. However, you can get a CA type certificate which is allowed to issue more certificates. The main CAs (top level) have certificates with the value of Certificate Basic Constraints of the form Is a Certification ...


6

According to your comments to other answers, you actually want to sign a pdf file with [your] certificate, then have this signature saved and appended to the pdf [you]'ve just signed. (BTW, you sign with the private key associated with the public key in your certificate, not with the certificate itself, but that's a detail.) I assume you want to ...


5

What Verisign does, basically, is to encrypt your certificate using their private key, and send you the result. The user's browser contains Verisign's public key, so it can verify your key has been signed by Verisign by decrypting it using that public key. They can re-send you your certificate as often as you want (they may or may not choose to do so ...


5

Extended Validation certificates are intended to show the user more visibly the institution to which they were issued. The technical aspects of the certificates themselves is combined with visual clues in the user interface of the application verifying them: the green bar and a visible name next to the location bar in the browser. For example, the EV ...


5

A root CA is actually an illusion. In X.509, there are trust anchors. A trust anchor is, mostly, a name and a public key, which you know a priori and that you trust. Representation of that name and that public key as a "certificate file" (traditionally self-signed) is just a convenient way to keep the trust anchor as a bunch of bytes. As per X.509, a CA is ...


5

Do I have any assurance that the previous owner does not have a valid HTTPS certificate for the site? No, you don't. CAs can issue certificate that are valid after the expiry date of the domain (at the time of issuance). Even if they didn't, a domain could be transferred before its expiry date. In addition, you can't possibly control all the CAs ...


5

whilst I agree with @Thomas's very thorough response above I'd like to add that I installed the root CA system for a UK banks own debit card system (each wee chip on the card is actually a certificate). We used Thales HSM devices (6 figure £ costs) that had proper tamper proof systems for tilt, temperature, physical attack and so on. in terms of the key ...


5

Your certificate will have certain properties, I believe they are called 'certificate usage' or similar. If, under there, you find Certificate Signing, then yes - you can use your certificate to sign other certificates. Note: the constraint Signing alone does not mean you can sign other certificates, it must be the full Certificate Signing. Your wildcard ...


5

Is a fake certificate only useful in combination of a DNS hijack (or any other method that will point the fake cert's target domain to a fraudulent IP, e.g. modifying hosts file etc?) ... or man-in-the-middle by means of ARP or routing table changes by an ISP. In any case, some redirection that is undesirable for the end user must also occur. The area ...



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