Good question. The certificates of the most trusted CAs are normally included into software install package, e.g. into browser installer, into OS installer, or are preinstalled on device like smartphone. That's why the browser (or some other application) will notice if certificate is really from the specified CA.
Is the only protection here that Bob actually checks that the public
key on the returned certificate matches what he originally sent in his
request to the CA?
If the public key was switched before the CA used it to create the certificate, then Bob's web site won't work at all. The private key, which he has kept safe, will only work with his original ...
Browsers will alert the user if they are presented with a self-signed certificate which they don't trust.
The browser user or system administrator should preempts this scenario and add the self-signed certificate to the browser's trust-anchor store beforehand. That way, the user won't see a warning.
Done this way, users can be informed that if they ever ...
Browsers will only accept an invalid certificate - and self-signed is one form of "invalid" - when the user acknowledges the risk and overrides the browser. The specific steps for doing so vary from browser to browser, but they're usually onerous by design - they want the decision to bypass security to be hard, not easy.
The revocation command uses the path taken from the /etc/ssl/openssl.cnf file, instead of your command, so it actually looks for certs in the cert/ directory.
Move them manually to this folder and it should work.
The checking of the hostname is done in X509_check_host. This function calls the internal function valid_star to make sure that the given wildcard in CN or SAN can actually be used.
This function checks that wildcard-CN/SAN like * or *.com are treated as invalid since they are too broad. *.example.com is instead acceptable. Thus check is done by counting ...
Is it dangerous to add a custom cert authority to a browser?
It is pretty dangerous. The owner of this CA can use it for man in the middle attacks or to impersonate arbitrary web sites since your browser will trust the CA to create certificates for arbitrary sites. Using such attacks he can then intercept your passwords and other sensitive data.
As long as you control DNS, it's trivial, even with Let's encrypt. Simply use DNS validation with LE, and they will happily issue a certificate. The point of this process isn't to ensure that anyone can use your site (that's your problem), but to ensure that noone will get a certificate for sites they don't know.
With many paid certificates, you can ...
The certificate and DNS record for IP public are irrelevant, you can buy any certificates without publish your sites. All you have to do is to prove you are the owner of that domain by clicking the approval link which send to your domain registration email or a DNS TXT record only.
The first error was because s_client doesn't like to see the root CA in sent in the TLS connection. The second error is because s_client doesn't trust the root CA.
To solve this second error, run s_client with the -CAfile option and specify the root CA.
How does that work?
They seem use an In-the-middle SSL Bump proxy.
First, it works as a transparent proxy, meaning it will silently redirect all HTTPS traffic to SSL Bump proxy servers.
You have to install and accept the proxy's Certificate Authority cert to make this work.
Once done, each SSL connection is made from your host to the SSL Bump Proxy with ...
“Anyone who controls the root CA knows everything you send through HTTPS, including your login passwords.”
This is not true.
First, note that what you are saying implies that Verisign (for example) can read your login passwords, credit card details, etc. That is quite obviously not the case.
If you trust me as a root CA, that means that your browser will ...
First: if the state requires everyone to have a state-controlled root certificate installed, and it's a law, then being a good citizen requires following the law.
Second: The question you're asking becomes a question of legality. This is not something that can be reasonably answered with technology, because the laws of an area govern the technology that can ...
As the previous answer suggests, the 2015/2016 attempt at this stunt got so much backlash they basically backed away from it and it sat for a while. The original January 1st 2016 deadline came and went with no real enforcement. Their request that Mozilla trusts their root certificate was declined. The MITM attempts still cropped up in individual cases of ...