Tag Info

New answers tagged

1

First step: forget all about encryption. There is no encryption in certificates. There are digital signatures. Digital signature algorithms, when first invented and published (in the late 1970s), where unfortunately described as "encryption with the private key", which is a flawed analogy, that does not actually work, and entails a heavy dose of confusion. ...


4

There is no global directory of all issued certificates (X.509 was designed to support the Directory, but it never existed in practice). You will have to contact "all CA" and ask them nicely. Basically, this would mean going to their site, and using the "I lost my password" feature so as to regain control of your account, if it exists. Details vary depending ...


3

Partly solving the underlying problem, you may use Public-Key-Pins header to restrict which certificates are valid for your domain (so a stolen certificate could only be used by a man-in-the-middle would on the first connection to your site). You can also use Public-Key-Pins-Report-Only to get notifications for failed Pin validation. Both headers are ...


1

The "right" way to think about renewals is to ask yourself why you want to renew. As I understand it, you have a root CA which is hardcoded in some application installed in the clients. Moreover, the clients themselves own certificates, presumably issued (directly, or indirectly through an intermediate CA) by that root CA. This hints at some mutual ...


1

"Web of Trust" in X.509 formats have been occasionally tried. For instance, Thawte tried it but gave up. For a Web of Trust to "work", you need two things: "Relying parties" (in the HTTPS case, this means Web browsers) must implement the verification protocol which checks the WoT relations. Sufficiently many participants must join the system. A WoT ...


0

This reminds me of the web-rings which used to be popular. If you can create a reputation-based system, you can start your own CA. The thing is, even the CA's today don't check much. You can have a malicious website with a CA signed certificate. So, it doesn't seem implausible. You could create a CA system based on website reputation. For instance, having a ...


6

... But in reality, a self-signed cert is not significantly less secure than a cert signed by a CA - in the sense that your traffic is encrypted and sent to the web server and decrypted there. It just means that no one "trusted" checked the identity of the webserver in question. This just is a very important part. If you don't verify, that the peer you ...


2

Certificates are for authentication, not for authorization. Authentication is (here) about the OpenVPN server making sure that the alleged client is who they claim to be. This is the point of certificates: the client shows his certificate, which contains his public key and identity; the server validates the certificate (with regards to its trusted CA) to ...


1

Trying to focus on the second question. The issue of «Which default trusted root certificates should I remove?» depends basically on who you deal with. You will "only" need to trust all the CAs that sign any of the websites you connect to. For a grandma-type user that always visits the same few sites, probably a handful CAs will be enough, while the list ...


1

A plan of action for this is to have regular monitoring and auditing performed on all requests. A little about how SSL CAs work (source: Fox-IT Post Breach of DigiNotar) Current browsers perform an OCSP check as soon as the browser connects to an SSL protected website through the https-protocol3. The serial number of the certificate presented by the ...


1

A stolen CA private key is a bad situation indeed. Response depends on the extent of the breach, and the context. First, it may be so that the CA private key was not exactly stolen, but merely used improperly. For instance, in the case of the Comodo event, the compromise was on Registration Authority accounts. The RA is the component who tells to the CA ...


1

Certificate "class" is essentially a marketing terminology. Each CA is free to call some of the certificates "class 0" or "class 1" or whatever, roughly meaning "I issued that but I did not bother to check" or "this time I did some checks because the owner paid me enough for that". Theoretically, as per X.509 rules, the "class" should be encoded in the ...


2

Right now, in X.509, there is no such thing as tracking of a number of uses of a given key. This is part of what is meant by "X.509 is context-free": validation is about whether the certificate path you have in front of you is valid or not, irrespective of whether a similar path or something different was shown to you 5 minutes ago when talking to the "same" ...


0

By "Classes" I think you mean "Extended Key Usages", and that attribute in particular is used by applications (email, web browsers, smart cards, IPSec, etc) to determine what that certificate is permitted to do. An EKU can be specified on the root CA or any subCA below it. Wherever that EKU is defined, then all usages below should inherit that ...


6

The question is... a bit complex. The critical issues are existence and availability of intermediate CA certificates. Consider the following points: Root CA are not "revoked". Revocation is a mechanism by which the issuer for a given certificate specifies, directly or indirectly, that one of its issued certificates is not to be trusted and must not be used ...


-1

Normally if a CA is renewed, the new CA uses the same public/private key pair as the old. If not, all certificates issued by the CA will no longer be valid. Creating a CA with the same subject and serial number as the old CA but with a different public/private key is more or less a completely new CA from a PKIs perspective. So if the XP client only has the ...


1

In an Active Directory setup, the "certificate templates" are supposed to be used by the clients and by the CA itself ("AD Certificate Services"). For the CA, the templates describe how certificates shall be issued, including: The certificate contents, including all the extensions, validity period and so on. The issuing conditions, e.g. whether the ...


2

What you intend to do by signing your primary key with a secondary key is essentially using your own CA. In theory, a CA is a third party trusted by the participiant who tries to verify the identity of his communication party to reliably verify this identity. In practice, in web context this decision which CAs are trustworthy is not made by the enduser ...


4

What you're describing is called certificate pinning; essentially, you ignore the whole CA process and just give the user application a certificate to trust. It's actually widely recommended for non-browser applications (e.g., mobile apps) for the exact reason you stated - if you rely on a CA and it goes down, you're in pretty deep trouble, whereas it's ...


0

This may see like a cop-out answer but it is not if you stay with me. PKI is just as much about the paperwork (policies and procedures) than it is about technical constraints. So if you have defined in your Certificate Practice Statement that your organization can and will suspend CA certificates as part of normal operations, then yes I do believe that the ...


1

Unfortunately, the only way to get a CA client certificate is by using the managed PKI solutions you have mentioned. As I have mentioned in my comment StartCom StartSSL Corporate may be the cheapest at around $2/certificate but says its for 1,000 certificates you have to contact them for an exact price. Another solution that may be possible (depending on ...


1

I will caution that I haven't tested this behavior, so while I believe my answers are based on sound logic it may not be the same logic that Microsoft chose to implement. When a client is determining whether to trust a certificate it will work its way up the CA tree (from initial certificate to root CA) verifying signatures of the certs. If a CA's key pair ...



Top 50 recent answers are included