New answers tagged

0

You don't require them : it's just a legacy habbit. Take a look at Project Perspectives


0

The set of https connections you will encounter breaks down into two disjoint subsets: Those you care about: financial sites, email, work, cloud storage for your backups … any site where a compromised connection will cost you money, data, time, aggravation, compromise of other sites (the main reason email is on the list — password resets), etc. Those you ...


0

Yes. If allowed by EKU. You can use a cert/key as a client cert if that is allowed within the certificate. Namely if TLS Web Client Authentication is allowed within the Extended Key Usage (EKU) section. For example: in the example.com cert it is actually allowed. (I didn't know that.) $ echo -n | openssl s_client -connect example.com:443 2>/dev/null | ...


0

Wether or not a given x509 certificate can be used for the client side of a Client authed SSL connection depends on the Key Usage and Extended Key Usage options placed on the certificate by the issuing CA. You can examine an x509 cert using openssl x509 -in certfile.pem -text The Key Usage options refer to various operations that the cert is allowed to be ...


2

I saw in that article and in many other places (including security.stackexchange), that if the user installs a certificate of an unknown 3rd party. That 3rd party can exercise MitM attacks in other apps of the device. If you install a certificate for a certificate agency (not a certificate for a site) then you effectively trust the certificate agency ...


0

One of the important detail that I discovered about exporting and importing private keys from a Windows Server Certificate Authority scenario is that it is important that the certificate request is made on the same machine where you will be importing the request. This is why there were some instances where after importing the certificate, the private key is ...


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


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.


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


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


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


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


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.


7

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


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


1

If you want to trust any certificate issued by A or B you put these into the trust store. If you want to accept only this specific certificate as trusted than you should only add this certificate. But you are right that you get problems when the certificates gets renewed. If you just want to trust this specific certificate only but want to accept it also if ...


1

When you install ADCS, you get the option of generating a new key pair, or reusing an existing key pair. The sentence you quote seems to indicate the latter: You export the certificate and private key from an existing CA, as a PFX file. You import the PFX into a Windows Server 2012 machine. You install ADCS on that machine, directing it to reuse the ...


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


0

You've hit on one of the fundamental problems with certificates. They are a form of authentication, but they are poor at authorization. I know who you are, but what are you allowed to sign? And do you and I agree on the definitions anyways? Over time, various bits have been hacked into X.509. Bits represent whether you can sign code, encrypt over TLS, etc. ...


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


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


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


0

As described on the manpage for openSSL: -out filename the output file to output certificates to. The default is standard output. The certificate details will also be printed out to this file in PEM format (except that -spkac outputs DER format). So it seems this will always write the certificate in a PEM format. You could choose to write these to ...


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


0

Your application could store multiple certificates in its pin list. The procedure for changing the cert would then be: Some time before the certificate expires, release a new version of your app with a replacement cert in the pin list, as well as the original cert when the old certificate expires, replace it on the server - the app should then still work ...


0

I need to assume you are describing Public Key Pinning (HPKP) as documented at https://developer.mozilla.org/en/docs/Web/Security/Public_Key_Pinning (The TLS related activities are quite fast moving these days, so perhaps there's some other SSL pinning being experimented with). As described in Ricky's answer, you can pin the public key of the intermediate ...


0

You sign a new certificate with your intermediate signing key. Specifically, what's "included in the app bundle" is your root signature verification key.


0

Q1 For public websites the most safe approach, or the only safe way is to use certificates from a trusted CA. However, in many scenarios we can use a self signed certificate to get "safe" connections with a web site. Browsers can't trust in SSC at all, but it launch a scary warning to prevent users about a posible untrusted and risky site. Q2 A server key ...


0

1) A self-signed certificate uses your key to sign itself; there is no CA involved, there is nothing to verify. The certificate will basically verify that it is matching the key but nothing more, so it serves no real verification purpose. Your browser will pop up a self-signed certificate warning, which means that the key is not certified by anyone. This ...


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


0

To answer Q3, Verisign's public key (actually its root certificate) is included in your web browser, along with a lot of other root certificates.



Top 50 recent answers are included