Tag Info

New answers tagged

0

Provided that a CA has strong policies such that an issued certificate is never forward- or back- dated, then: A certificate issued at the NotBeforeDate cannot have been compromised by vulnerabilities that are known to have been fixed before the NotBeforeDate - a certificate that does not exist during the period of a vulnerability cannot have been ...


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


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


-2

Yes, a major one. They will have the private key (because they got it, then passed to you) and can thereby impersonate your website at will.


0

There is no problem with CSR's generated with a vulnerable version of OpenSSL. This doesn't mean your keys were not compromised via an actively running server, but it sounds like you understand that.


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


0

In case of HTTPS protocol, Common Name can also be used by some of the client applications for verification of the server's identity. The RFC 2818 says the following about the server's identity: If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject ...


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


0

Basically, any CA does exactly what it wishes to do. However, OS and browser vendors won't accept just any CA as a "trusted root". E.g. Microsoft runs a root certificate program which defines the contractual conditions that a CA must fulfil in order to get its root CA public key included in the "trusted store" of all Windows systems. These conditions include ...


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


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


0

In the Microsoft / Active Directory world, there are several ways by which certificate-based authentication may happen, but the short answer is: yes, a user can have several certificates. In IIS terminology, that is called "certificate mapping", with the option clientCertificateMappingAuthentication (not to be confused with ...


0

You can only make assumptions based on the contents of the Organization field (DV certificate will either have the domain or "Persona Not Validated" in the organization name field) or in the policy identifier if it is there. Certificate issuers do not follow any unified scheme to differentiate OV vs DV. So, with cURL, you will have to do write your own ...


0

To detect a MITM attack, you need some way to communicate with the other end that is not easily tampered with by a third party. If there's a MITM attack, the key you're using is different than what the other end is using, and the crypto bits are different. A classic way to do this appeared in some early public-key phone encryption units. After call setup, ...


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


0

I think you misunderstood STARTTLS. This command just tells the other server, that the clients wants to do TLS and after the server agreed the normal TLS handshake will start, e.g. with certificates and all the stuff - same as with https. The main difference is, that you don't commit to TLS right after TCP connect, but only after exchanging some plain text ...


0

You shouldn't. The reason being, the https:// URI scheme signals both to the user and to the browser that it is acting in a secure environment, and precautions should be taken to prevent secure information from leaking to an insecure environment. This is well-understood and a pretty strong system. The mechanism a server would use for switching from an ...


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


0

thanks for the tips. The MX record was pointing at mail.mydomain.com, updating the certificate sorted that out. We still have a problem as our mail server is desparately out of date and doesn't support TLS 1.1 (or higher), so we'll need to upgrade that now (oh joy!!). Thanks again for your help.



Top 50 recent answers are included