Tag Info

Hot answers tagged

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


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

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

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

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

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

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


2

One theory is that, ideally, the end-user should manage his own store of trusted root CA, making an informed decision based on the published Certification Practice Statements by existing CA. Theory and practice match only in theory, though. It is not surprising that most users cannot and will not handle such a management process, if only because it relies ...


1

Consumers of the service you are attempting to authenticate with certificates provided by such an "untrusted" third party might be more willing to install the root certificate of some independent party in their trust chain, vs. some one-off root CA that you have created just for your service. In such a case, cacert (or equivalent entity) assumes the burden ...


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