Tag Info

Hot answers tagged

8

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


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

I can think of many reasons. The first one, is economical. Effectively, getting a certification is costly, and the higher you are on the chain, the more expensive it gets. Using, what you propose might theoritically be interesting, but it will cost twice as much to companies (don't forget, CA are economical entities that sell their services, they won't do it ...


1

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


1

It has to be the FQDN of your mail server. This would be what your DNS MX records point to, e.g. mx.mydomain.com. A mail client will find to which system it needs to send an email based on the mx record associated to the domain of an email address, e.g. john@test.com: what's the MX record of test.com? mx.mailserver.com Then and only then will TLS enter ...


1

All root CAs are self-signed. Which means we feel forced to implicitly trust that the CA is operated responsibly and securely. This isn't always the case (Diginotar). There are alternatives to the certificate authority method. One of these is the web of trust, which is used mainly in PGP / GPG / OpenPGP implementations. There are situations that can arise ...



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