Tag Info

Hot answers tagged

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


5

With a digital signature you might claim ownership of a piece of data, but usually not to your own advantage. A digital signature works like this: The key owner generates a public/private key pair (two mathematical objects sharing a common structure). The public key is made public (hence the name) while the private key is kept private (the structure is ...


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


3

You can "regenerate" the certificate on your gateway, but it will work only if you take care to reuse the same name and key. This is a certificate chain: the certificate on the gateway is the "CA certificate" and the clients have been issued certificates by that CA. Such a client certificate will be deemed valid (aka "acceptable") if whoever does the ...


2

A possibility would be to use 'sudo' (or a script / alias relying on it). Thanks to sudo, you can allow your users to temporarily use another (not necessarily root) in order to execute a very specific command: Create a new account which will own the private key, Configure sudo so your users can launch an SSH client using this account and its private key. ...


2

You want mutual authentication between client and server. As per the SSL/TLS protocol, this is supported with client certificates. Both the server and the client have a certificate; the server shows its certificate to the client, and then requests the client to show its own certificate and prove control of the corresponding private key. This works, this is ...


2

There are lots of flaws with the current PKI, and trust chain is one of them, but not the only one and not in all cases. Each browser/OS comes with lots of CAs and the trust is enabled by default. So once you get the browser you implicitly trust all these CAs for your communication. You need to explicitly disable trust settings if you want to control whom ...


2

I would not call it blind trusting, but yes - you rely on the trustworthiness of the root certificate and all the intermediate authorities on the way depending on the implementation and configuration. A website's certificate is verified with a CA. In order to make sure this CA is indeed the actual CA you intend to trust, you can verify its own certificate ...


2

Your main assumption that key size is directly related to the format of the keys, parameters or output size does not hold. Normally the attacker would only have access to a public EC key, which is (usually) not 256 bit, but a point on the curve. This point consists of two coordinate values prefixed with an indicator (compressed or uncompressed points). ...


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


2

The chain is not verified "by itself". A given system (say, a Web browser) will consider a server's certificate as valid because it could build a valid chain (with all signatures corrects and matching names and all the rules of X.509) which ends with the certificate to validate (the server's certificate), and starting with a root CA that the client already ...


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


1

As a rule, encryption provides confidentiality, not integrity. Depending on the algorithm, the attacker may have more or less control on what will show up after decryption. In any case, we are talking here about RSA, in which encryption uses the recipient's public key. As the name suggests, the public key is public (and keeping it "secret" can be hard). ...


1

Speaking about encryption in general, not limiting it to RSA, if a man-in-the-middle modifies an encrypted message, the message will not decrypt as the same message you sent. It really depends on the encryption algorithm used. For example, if a block cipher was used, only the block with the altered data will fail to decrypt properly, the rest of the blocks ...


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

Signing a physical object like a printed poster is problematic at best. If someone photocopied the poster and re-posted or somewhere else, is it still valid? What if they cropped off the edges of a valid poster? is it still good? How about subtle but semantically significant changes like color or clarity? Does taking a marker to your poster invalidate it? ...


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

Sorry, but the answer is "no". The top level root certificate "signs" your other certificates. When your client goes to validate their certificate, they are going to look at the signature on it, and they will see it was signed by "oldcert", they will then attempt to validate "oldcert", and discover and that "oldcert" has expired. Just having the new ...


1

Technically your certificate is not for you. You have a certificate so you can show it to other people; it is meant to convince them, not you. You don't necessarily trust your own certificate. As a safeguard against bugs, you may want to check that the public key in the certificate matches your private key: if the CA fumbled (badly) and sent you the wrong ...


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


1

Faced with this question, Microsoft answered the way they are accustomed to: with a Microsoft-specific extension. They defined the User Principal Name, which is actually an OtherName element, the UPN being identified by a Microsoft OID (1.3.6.1.4.1.311.20.2.3) and encoded as an UTF8String (as succinctly specified there). The format of the string mimics that ...


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


1

I recommend you to keep it simple. You could simply AES the fields you need to protect. Independently of the encryption method you use you must encrypt together some fields: Name + Surname Date of birth State + Street number + Street name *... Otherwise you could try statistical analysis against the data.


1

I understand your issues, but one of the fundamental maxims of cryptography is that you shouldn't reinvent the wheel and create your own encryption algorithm, primarily because it will be nowhere near as secure as an established one. Is this data going to be accessible over the Internet or transmitted over unencrypted channels? If the answer to either of ...


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

1024 is considered the minimum key size for RSA at the current time. For general purposes i would say that 2048 is enough. However, if you will use this key to transfer highly sensible data (e.g. related to bank accounts or important server passwords etc..) I´d go with 4096 bits.


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



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