Hot answers tagged

41

In a certificate, the serial number is chosen by the CA which issued the certificate. It is just written in the certificate. The CA can choose the serial number in any way as it sees fit, not necessarily randomly (and it has to fit in 20 bytes). A CA is supposed to choose unique serial numbers, that is, unique for the CA. You cannot count on a serial number ...


33

This is an historically disputed point. In the validation algorithm from RFC 5280 (that supersedes RFC 2459, by the way), there is no requirement of validity range nesting. However, some historical implementations have insisted on it; see for instance the X.509 style guide of Peter Gutmann: Although this isn't specified in any standard, some software ...


22

RSA is two algorithms, one for asymmetric encryption, the other one for digital signatures. They use the same kind of keys, they share the same core operation, and they are both called "RSA". Diffie-Hellman is a key exchange algorithm; you can view it as a kind of asymmetric encryption algorithm where you do not get to choose what you encrypt. This is fine ...


20

It's about expanding trust, yes. If you trust both CA1 and CA2, and a cert is signed by both, you've got a very high level of trust because two seaparate entities that you trust have verified the cert. It has the added bonus of increasing the ease of verification of trust, such as situations where you've got clients that trust CA1 or CA2 (but not both). In ...


20

SSL is by far the largest use of X.509 certificates, many people use the terms interchangeably. They're not the same however; a "SSL Certificate" is a X.509 Certificate with Extended Key Usage: Server Authentication (1.3.6.1.5.5.7.3.1). Other "common" types of X.509 certs are Client Authentication (1.3.6.1.5.5.7.3.2), Code Signing (1.3.6.1.5.5.7.3.3), and a ...


20

You've evolved to mostly right, but to add several points and expand on @CoverosGene more than I felt comfortable doing in an edit: X.509 defines a certificate (and some other things not relevant here) in ASN.1, a (very!) general data structuring method which has several defined encodings, of which DER Distinguished Encoding Representation is quite common ...


17

The Key Usage extension is described in section 4.2.1.3 of X.509, with the following possible flags: KeyUsage ::= BIT STRING { digitalSignature (0), nonRepudiation (1), -- recent editions of X.509 have -- renamed this bit to contentCommitment keyEncipherment (2), ...


16

In "pure X.509", it does not really matter if an extension is critical or not, because conforming implementations are supposed to honour the extensions that they recognize, be they marked critical or not. The "critical" flag is for extensions which are not standard: you make such an extension critical if it is important for security (implementations which do ...


15

CA does not issue private keys to anybody. CA signs (using its own private key, which is kept very secret) your public key. The CA has no access to your private key at all. If the CA’s private key is leaked to Mallory, Mallory is able to issue valid certificates for any name. That means he can make almost undetectable (well, obviously, you can detect the ...


14

OpenSSH does not officially support x.509 certificate based authentication: The developers have maintained a stance that the complexity of X.509 certificates introduces an unacceptable attack surface for sshd. Instead, they have [recently] implemented an alternative certificate format which is much simpler to parse and thus introduces less risk. ...


14

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


14

Theoretically, X.509 chains are unlimited in length. The Basic Constraints extension can apply a per-chain limit; this is used mostly for CA that agree to issue a sub-CA certificate but want to constraint that sub-CA to issue only end-entity certificates. Implementations may have limitations. In fact, with some carefully crafted certificates, one can make a ...


14

Hmm, I agree that I would have expected to find this info in RFC 5280 4.1.2.5. Validity. (By the way, RFC 5280 obsoletes RFC 3280, which obsoletes RFC 2459, so you really shouldn't be looking at 2459 any more). That said, you can figure this one out logically (at least for a standard TLS-like setting): When an end-user validates a cert, they have to follow ...


13

There is no technical/specification limit imposed on the length of certificate chains. (However, there are X509v3 attributes which can impose policy-based limits on the length of a certificate chain for a CA; see the pathLenConstraint field of Basic Constraints, RFC 5280, Section 4.2.1.9.) With longer chains, verifying clients need to perform a little more ...


10

The following are the "accepted naming", i.e. the terms that I would accept: A public key is a mathematical object; it is half of the cryptographic key pair. For RSA, a public key is a pair of big integers (modulus and exponent), nothing more. A private key is a mathematical object; it is the other half of the key pair. For RSA, a private key is a bunch of ...


9

The official reason why certificates expire is because of revocation. A certificate is "revoked" when its issuer asserts that the certificate contents are no longer to be trusted, for some reason which needs not me specified. It is like a "cancel" from the CA: the CA signed the certificate, but now regrets it. A common reason for revocation is when the ...


9

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


9

Theoretically you can put anything you want in a certificate; for instance, this certificate actually contains a video file as "Subject Alt Name" (surprisingly, Windows has no trouble decoding a 1.2 MB certificate -- but it does not show the video, alas). However, in practice, certificates "for SSL" just contain the intended server name, as specified in RFC ...


8

Strictly speaking, a key should not be "multipurpose". Distinct key usages call for incompatible key life cycles. The Key Usage extension is a formalism of this fact. For instance, keys which are used for signatures and authentication could be lost with relatively low consequences: if your smart card is destroyed, you can no longer sign, but no data is ...


7

It is the server's responsibility to serve up the entire certification chain. If your web server isn't doing that, it is misconfigured, and you should fix it. You can use the SSL test service from SSL Labs to test whether your server has SSL properly configured. Just type in your server's domain name, and it will give you a report indicating whether it ...


7

These values (both OID and root CA cert fingerprint) are indeed hard-coded in the browser's code. In Firefox, this is done in nsIdentityChecking.cpp.


7

Take care that the set of possible extensions is, by definition, not bounded (at least not practically; there is an internal limit a bit of about 1282255). There are standard extensions which are described in the X.509 standard, but there could be a lot more elsewhere. In particular, Microsoft's implementations (e.g. AD Certificate Services) tend to use a ...


7

No extension is strictly necessary in the SSL server certificate, but some extensions can only help: An Authority Key Identifier extension will help clients link the certificate with the issuing CA. A CRL Distribution Points extension (non critical) should be used to point to the URL where the CRL should be found. An Authority Information Access extension ...


7

X.509 certificates are a generic, highly flexible format. SSL (now known as "TLS") uses X.509 certificates. A "SSL certificate" is a certificate whose contents make it usable for SSL (usually, usable for a SSL server). In particular, in most usages of SSL, the client will want to see the intended server name in the certificate. In a Web context (HTTPS), the ...


7

Microsoft has issued the MS09-056 update which patched this vulnerability in CryptoAPI on almost all of their operating systems, that automatically fixes it for Internet Explorer, Chrome, Safari, and any other application that relies on the CryptoAPI. Mozilla has issued an updated quickly after Marlinspike's demonstration and Opera has patched it in version ...


7

A certificate for a Time Stamp Authority is accepted as such only if it contains an Extended Key Usage extension which itself advertises the specific id-kp-timeStamping object identifier (aka 1.3.6.1.5.5.7.3.8). Though Authenticode time stamps do not follow the RFC 3161 format, the rules on the TSA certificate are still the same (see section 2.3). There is ...


7

Yes, it is possible, but the better question is would they? The CA's reputation is their life blood. Why would they give a trusted signing authority to another CA that might not hold up to their standards (and could be a direct competitor in the future.) To the best of my knowledge, no CA offers this kind of service, nor do I see any reason why they would ...


6

The X.509 specs only support one signature. From the RFC concerning them: Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } To support multiple signatureValue's you'd have to do something like "signatureValue SEQUENCE OF BIT STRING" ...


6

Certificate validation is, huh, a bit more than looking at the dates. Have a look at RFC 5280. It would be an utter delusion to believe that you could implement certificate validation with any kind of security, and decent interoperability, if you do not read several times and wholly understand that document. A lot of crud has accumulated on the ...


6

When doing SSL access to a server, the client performs the following verifications: The client validates the certificate with regards to the local "trust anchors", also known as "root CA", which are embedded in the client (the browser or the operating system). Validation is about building a chain of certificates from a trust anchor down to the SSL server's ...



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