I've been using an online SSL checker to check certificate validity for several sites.
One thing I noticed is that many websites have wildcard certificates - especially those hosted on common web hosting sites, such as goDaddy: *.onlinestore.godaddy.com
But those sites have custom domains and so when validating the SSL cert I can see an error where the hostname does not match the altnames listed in the certificate.
But all major browsers (tested chrome, FF, IE and Safari) still show the site as secure. Do the browsers not care that the domain names are not listed in the cert, and isn't that a security vulnerability?
Example: https://www.sslshopper.com/ssl-checker.html#hostname=www.cinnamonmotif.com
In case a wildcard certificate is installed on a domain, the browser only check the certificate validity and wildcard rule. As long as this rule is true the certificate id trusted and no warning appears.
If you look at the certificate that the browser resolved you'll see that it's different than sslshopper.com resolved.
When you go in a modern browser the client sends the TLS Server Name Indication extension, and the site notices that it's supposed to serve up the cinnamonmotif.com certificate.
SslShopper saw *.onlinestore.godaddy.com, which is certificate 0x6068c7475ab4ee2a from Go Daddy Secure Certificate Authority - G2.
With SNI the served up certificate is cinnamonmotif.com, certificate 0x3e0240d9425e8120 from Go Daddy Secure Certificate Authority - G2.
The fact that the browser saw a different certificate, which is a hostname match, is why the browser says it's a legitimate connection.
Related
I have a web page with apache, and it is hosted only in localhost, but all devices that are connected to my network can be entered using my ipv4 (192.168.1.x), I have installed a certificate using openssl, but the certificate is only valid For my pc where I am hosting the site, if I try to enter with another device it tells me that it is not valid.
That's expected since the Certificate Authority (who emitted your certificate) is not trusted by the browsers. You'd need to install your CA certificate in your clients in order to make them trust the certificates emitted by that CA.
If you own a valid domain, you may buy a certificate for it from a trusted CA, or even emit a certificate using Let's Encrypt, which emits free SSL certificates that are trusted by all major browsers currently. Remember that this won't work neither for invalid/local domains or domains that you don't own.
I have a wildcard self-signed certificate for two domains
*.abc.com
*.xyz.com
I'm access the servers https://one.abc.com and https://two.xyz.com via a third service https://three.abc.com and using the same self-signed certificate
I want to ignore the ssl warnings only once.
Note: I've broken down the issue.
Exceptions in the browser will be added only for the currently requested domain. If you want the self-signed certificate to be trusted for all domains contained in the certificate you have to explicitly add it to the trust store instead of only overriding the browser warnings.
I am trying to activate HTTPS for my domain name. Chrome recognizes the SSL certificate when i go to https://www.example.com, but I get the error and it says that my SSL is not trusted. What do I need to do to get my SSL certificate to be trusted?
Instead of using a self-signed certificate, get one from a certificate provider. I'd recommend you looking at LetsEncrypt because they have a good automated support for being able to renew certificates automatically.
When I send a request a known site lik facebook, Google,... on https protocol, the certificates are appearing on browser via pedlock.
How the web site (facebook,google,..) certificate comes to my browser?
How my browser knows the certificate is valid? is asking the Certificate Authority company?
What means my computers trusted certificates (on Windows certmgr.msc)?
1. How the web site (facebook,google,..) certificate comes t y browser?
When your browser requests a website using the HTTPS protocol the transfer will start with a SSL/TLS handshake. During this handshake the server will submit the website certificate to your browser.
2. How my browser knows the certificate is valid? is asking the Certificate Authority company?
The website certificate is commonly provided by a certificate authority (CA). The CA has signed the website certificate with its own certificate - after it has verified the websites identity. Every browser has some certificates from trusted CAs pre-installed. These certificates are used to check if the submited website certificated is properly signed by the CA.
In addition the browser may use the Online Certificate Status Protocol (OSCP) to check if the website is still valid.
3. What meansmy computers trusted certificates (on Windows certmgr.msc)?
I guess this is a different topic. The CA certificates used for HTTPS connections are part of the browser (IE, FF, etc.) and no part of the operating system.
Additional notes
The way the browser displays a trusted HTTPS connection depends on the browser and of the type of the used certificate.
If you are interested in some details how the certificates are distributed, you may doa research to the topic of "Public-key infrastructure (PKI)"
I guess it can't be done, but if so, I'd like to know why.
Let's say I get an SSL certificate for example.com from one of the official certificate authorities around. Let's also say I'm running a.example.com and b.c.d.example.com and would like to have SSL certificates for those as well.
Can I use the example.com certificate to issue certificates for a.example.com and b.c.d.example.com myself? And will they be recognized by users' browsers? If not, why not?
(My guess that it can't be done is because it would break the very lucrative wildcard cert business model, wouldn't it?)
Clarification: can't I act as a "self-signed" certificate authority using the keypair for which I obtained the official cert, and simply add my official cert in the validation chain?
You cannot use Your certificate to issue other certificates, because the purposes of the
certificate are encoded in Your certificate and "Certificate Authority" is certainly not included in that list.
Web browsers check the "certificate chain" beginning from Your certificate, the certificate that was used to sign it, the signer of that certificate etc.
Your certificate must match the current use case (mostly "identify web site") and all signing certificates must include the "Certificate Authority" flag. The last certificate must be known to the browser (root cert).
As You already guess, wildcard certificates might help in Your case.
You're correct, you cannot issue certificates from a certificate. You need a Certificate Authority to issue certificates.
The whole point of a Certificate Authority is that they are a trusted 3rd party. CA's like Verisign are trusted by default by most browsers so that you dont have to manually accept certificates from them. They have what is termed a trusted root certificate.
If you create your own Certificate Authority and start dishing out certificates, web browsers will not know you and hance not trust you. The user will be prompted.