Tag Info

Hot answers tagged

38

You shouldn't really be worrying about this, the certificate contains only your public key, which is supposed to be public anyway. The only issue is the privacy concern of giving away the information in your certificate to any site that asks for it. Summary of the issue: The BBC weather page has a request to http://www.live.bbc.co.uk. HTTPS Everywhere is ...


9

Depending on how the CA does things, it may or may not have a copy of your private key. Usually it doesn't. The normal method is that you generate your private/public key pair on your own machine, then send the public key to the CA as part of a certificate request. The CA assembles and signs the certificate, and sends it back to you. Your private key never ...


5

In general, self-signed certificates offer no security benefit over raw public keys (there can be convoluted situations where the self-signature provides a "proof of possession" of the corresponding private key, but this very rarely matters). Self-signed certificates can offer a usability benefit, though, in that it allows the use of certificate-based ...


5

Normal, serious root CA are offline. They are hosted on machines which are never connected to any kind of network. This tends to make them immune to remote attacks, and that's the point. Technically, the reasons which have warranted key renewal ("the bug was there, so there might have been a compromise that we don't know of") are still valid: it would be ...


5

Yes. Most private keys have an easily identifiable format. If its say an RSA private key generated with openssl, they have a specific format e.g., will always start with the same three bytes depending on key size: 30 82 01 (for 768 bit key or MIIB in base64) 30 82 02 (for 1024 bit key or MIIC in base64), 30 82 04 (for 2048 bit key or MIIE in base64), 30 ...


5

I find the question useful, because it is actually hard to find out if a certificate got revoked the right way. If you know who issued the original certificate you can download the CRLs (which contains only the serial numbers and the date of revocation, not the revoked certificate itself). If not you are out of luck. If you know the serial number of the ...


5

Oooh, that's a tricky one. Theoretically, the nextUpdate field is meant to be a (future) date at which a new, updated version of the CRL should be made available. The idea is that if you have a cached CRL, then there is no point trying to download a new one before that date. In "true X.509" each relying party (a "relying party" is "some system which tries ...


4

There is no risk of compromising the private key, because you send only the CSR which contains the public, but not the private key. But, using a CA is in effect a trust delegation, e.g. people trust your certificate because they (or the browser) trusts the CA which signed the certificate. Once they notice, that the CA is no longer trustworthy (like DigiNotar ...


3

The risk of using a shifty-looking CA is not in the certificate enrollment process: as long as you generate the key pair yourself and send only the certificate request to the CA (which contains only the public key) and receive the raw certificate in return (not a PKCS#12/PFX archive), then your private key is yours and yours only. The risk, though, is in ...


3

You are correct that SSL uses a asymmetric key pair. One public and one private key is generated which also known as public key infrastructure (PKI). The public key is what is distributed to the world, and is used to encrypt the data. Only the private key can actually decrypt the data though. Example time. Say we both go to walmart.com and buy stuff. ...


3

As far as X.509 is concerned, the Common Name is not mandatory. However, a number of systems will use the CN for display purposes, e.g. most "certificate manager" GUI in Windows. Therefore, it is recommended, if only for ease of sysadmin tasks, to include reasonably precise CN in certificates. If you want to, from an application, pinpoint a specific ...


3

Heartbleed has pretty little relation with certificates. The only link is that a potential consequence of a successfully exploited heartbleed is a reveal of the SSL server private key. Therefore you might want to go to full paranoia mode and consider that any private key which was used in a vulnerable server is toast and must be replaced. This is quite ...


3

As far as X.509 is concerned, there is absolutely no problem in having several certificates with the same public key. The validation process is described in full details here; in a nutshell, it is verified that: each certificate in the chain is currently valid (with regards to its start and end dates for validity); the signature on each certificate is ...


3

PKCS#12 is an extremely flexible format, so any answer to your question is relative to what the archive producer decided to do: which algorithms, which parameters... Normally, when doing password-based encryption, you will end up with 3DES or AES, and the key derivation algorithm is PBKDF2 with a cost parameter that you do not get to choose. To make the ...


3

There is a standard for STARTTLS in plain HTTP. Note that "STARTTLS" is still SSL; it merely modifies the dynamics, but no implementation complexity is avoided that way. Generally speaking, nobody uses STARTTLS for HTTP, mostly because it is less secure. Indeed, a very big part of SSL-for-Web-browsers is the visual feedback, by which the user is made aware ...


3

The point of a load-balancer is that all your servers appear to the client as one. So no matter where you handle the TLS (on the load-balancer or on the application servers), you will only need one certificate to ensure that no web browsers will show any HTTPS warnings. When clients communicate only with the load-balancer (which handles TLS) and you control ...


2

If you're trying to protect data-in-transit between two servers, please just use SSL/TLS certificates instead of rolling a new encryption scheme. Note that SSL/TLS technically uses symmetric encryption as well, but the shared session keys are encrypted with asymmetric keys during the initial exchange (hence the need for certificates). One of the huge ...


2

X.509 security certificates are mainly about the authentication of the site providing it, i.e. you know the site is really the site it claims to be. This is why e.g. banks use certificates at a high trust level (which means they are signed by more certification authorities, signed by more established cas rather than unknown ones, etc.). Even without ...


2

When AD Certificate Services starts up, it insists on validating its own certificate (the subordinate CA certificate). This entails verifying that the CA certificate has not been revoked, by obtaining the CRL referenced from the CRL Distribution Points extension found in that certificate. If the CRL have been moved, and not up-to-date CRL can be found at ...


2

I think I understand the question as: If a servers' private keys have been compromised, won't a MITM attack be possible even if the heartbleed vulnerability has been patched? (given that not all browsers mandate Certificate Revocation List (CRL) checking?) And I believe the answer is indeed yes. Patching against the heartbleed vulnerability ...


2

What you are describing is actually your own, reduced auto-update feature, limited to updating what amounts to a "trust store" for certificates. The bad thing about it is that it works outside of the normal app update mechanism, without much possible user intervention, so the user will get the updates whether he wants them or not. The good thing about it ...


1

Using the date from the server itself is self-defeating: a fake server could send a fake date. Actually there is in SSL itself a field for the date: the first four bytes of the client_random and server_random fields contain the current date and time, as known by the client and the server, respectively. This implies the following: A passive attacker, ...


1

Let's assume, for an instant, that you really need to "re-key your Web servers" because of the heartbleed bug (if there is such a need, then you quite logically also need to do it for every other similar vulnerability which shows up, hence several times per year, and you must also do it for vulnerabilities which will show up, so, by that reasoning, your ...


1

You assume incorrectly: a cert does not have to be revoked when re-issued. It is typically a different process altogether. This means that you should add a last step to your plan: revoke the old certificate once you are done with installing the new one. Clients will not cache your certificate. In fact, they cannot keep a cached copy since it is your server ...


1

File name "extensions" are immaterial. There is no real standard for these few letters, only loosely maintained traditions. The PKCS#7 standard (now called CMS) describes how to encode and decode signed and/or encrypted and/or authenticated "messages" into sequences of bytes. How these sequences of bytes are stored or exchanged is completely out of scope; in ...


1

There are variety of ways to look into your question . Apply the patch for the heartbleed bug and use openssl Use Options to bypass heartbleed or versions of openssl that dont have heartbleed problem. more here Use some other Crypto Library (does not gaurentee it does not bleed later ) Basically, there is no fool proof way or ideal way to distribute keys ...


1

A certificate is basically a binding between an identity and a public key, but there are details: The notion of "identity" which is most adequate for your situation is not necessarily the same as the notion of identity for a SSL server certificate (i.e. a server DNS name...). The lifecycle of the private key matters: who generates it, where it is stored, ...


1

Good Question. TACK is a "dynamic pinning" solution to the broken Certificate Authority model we all depend on today. A competitor is Google's Certificate Transparency (CT). Status of TACK is No browsers currently support it. There are no browser extensions to enable it. The last posting from the developers (January, 2014) is that it is entirely up ...


1

When the CA signs the locally generated keypair, the private key is never seen by the CA server. If you use IE in a corporate environment, or a similarly configured EXE, it may be possible possible for that website to request the ActiveX control to upload the private key to the CA for key archival/escrow purposes.


1

There are mostly two main ways, one of which using certificate extensions, and one of which being a bad idea. These two are the same... In a certificate, you can encode "usages" as part of the Extended Key Usage extension. In your terminology, you would define some OIDs for actions A, B, C and D, and put only OIDs for A and C in the certificate. What is ...



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