Hot answers tagged

38

You need to import the root certificate into the trust store for the browser. Once the browser knows you trust this root certificate, all certificates signed by this will show up as trusted. Note that this will only make the connection trusted for you, any others who don't have the root certificate installed will still receive an error.


30

Self-signed certificates are inherently not trusted by your browser because a certificate itself doesn't form any trust, the trust comes from being signed by a certificate that EVERYONE trusts. Your browser simply doesn't trust your self-signed certificate as if it were a root certificate. To make your browser accept your certificate, go into your browsers ...


8

Actually, self-signed certificates can be secure, just not under the model we're using now. Under the wide-spread CA (certificate authority) model that everyone uses currently, the purpose of the certificate being signed by a trusted CA is to provide authentication. When we get a certificate, all we really see is 1's and 0's coming in from the jack in ...


5

Checking the root certificates of my browser I see that almost all Root CAs are using SHA-1 or below. The signing algorithm used for the trusted root certificates is unimportant. Signatures are used to establish trust. By definition, a trusted root certificate is one which you implicitly trust based on provenance (e.g., where it came from and how it ...


5

Is it ok to use self-signed certificates for development, and then use the acquired one for production only? Yes, that is the way almost every one does. You don't have to pay a certification authority to certify that you are talking to your own server. Self sign it until production, buy a real certificate later. Does using self-signed certificates ...


4

Shorter answer. A lot of answers here, but none seems to get straight to the point: Without a neutral and recognized third party—such as a certificate authority—verifying certificate ownership, a certificate is meaningless. Longer answer. To better understand, when doing something like creating an HTTPS connection you have the following chain: A client ...


4

Why is it designed to trust all root CA to issue certs for any domain name? This has historical reasons and maybe for reasons to promote competition. At the beginning you had only a few root CA with very high prices. Now the prices are down because all CA can issue a certificate for anybody. If each CA would only be able to sign certificates for a ...


4

Relying on DNSSEC would essentially amount to transferring our trust from the CA's to the registrars (e.g. firms like GoDaddy), the TLD's (e.g. VeriSign), and the root (e.g. ICANN). I'm not sure we can trust these entities any more than we can trust the CA's. See Moxie Marlinspike's blog post for a great write-up on this subject: ...


4

A: Authentication only. You can still do "null" encryption afterwards, if you like. But if you do non-null encryption, then you'll have an idea of who with you're doing that. That's the authentication part. -- There used to be a time when SGC, Server-Gated-Cryptography, was a thing. An extra bit in the certificate would either allow or disallow any decent ...


2

The best practice is to trust the root CA, for very practical reasons. Root CAs are a special beast and are expected to have very long lifetimes (20 years or more) because they require replacement in the client software, which is usually a manual process. Intermediate and server certificates are expected to change frequently - in some cases (load ...


2

I think you are certainly right, the verifier knows your TPM is trusted. In the DAA case the verifier cannot map TPM to user though. In AIK certificate enrollment, the Certificate Authority may well be the same entity that verifies the AIK certificate. Whereas in DAA, there is no Certificate Authority involved. There is an issuer which works with a TPM ...


2

Self-signed certificates can't be trusted because anyone is able to craft one. An attacker performing a MITM attack could easily replace any certificate by a self-signed one and impersonate any website you're browsing, even if you're using HTTPS. That's why we are using trusted Certificate Authorities to ensure that certificates cannot be falsified.


2

Any application must be given the list of "root certificates" to be trusted. In case of a browser, there is a defined list that comes by default with any browser, but this list does not contain your certificate. Imagine you don't need to actually give the list of certificates that you trust, then anyone would be able to setup a https website that an ...


1

We all need a little context. There is a difference between "untrusted" and secure. And "Trusted" does not necessarily imply Secure (or Authentic) A self-signed certificate on an isolated network with only one server and one client is probably more secure than any "trusted" certificate. And "trusted" implies ONLY that a Certificate Authority Certificate ...


1

Sorry, per the sourcecode you can't prevent the writing of $outdir/$serial.pem and still get your (desired) -out. You could put $outdir someplace like /tmp that gets discarded frequently; or on an OS that allows you to add new filesystem types (Linux at least) you could create a filesystem type that implements a directory such that anything created in it is ...



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