I get the following error message.
You have asked Firefox to connect securely to www.gstatic.com, but we can't confirm that your connection is secure.
Normally, when you try to connect securely, sites will present trusted identification to prove that you are going to the right place. However, this site's identity can't be verified.
What Should I Do?
If you usually connect to this site without problems, this error could mean that someone is trying to impersonate the site, and you shouldn't continue.
This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox only connect to it securely. As a result, it is not possible to add an exception for this certificate.
www.gstatic.com uses an invalid security certificate.
The certificate is not trusted because the issuer certificate is unknown.
The server might not be sending the appropriate intermediate certificates.
An additional root certificate may need to be imported.
(Error code: sec_error_unknown_issuer)
Can someone please help me to solve this issue :'(
You're receiving this error message because the certificate for the site isn't valid. In order to communicate using SSL with a site, the site must provide a valid certificate. There are a number of things necessary for a valid certificate, but one factor is the certificate must be issued by a trusted certificate authority, or CA. Your browser is preconfigured with a set of trusted CAs, but for this particular site, the issuer is not part of that set of trusted authorities.
Furthermore, since the site is using HSTS (HTTP Strict Transport Security), an exception cannot be made for this certificate.
You'll need to view the certificate and see who issued the certificate (the CA) and whether that is a real CA. The certificate may be self-signed, which means the site issued their own certificate without a trusted CA. If you wish to continue, you'll have to install the issuer's certificate as a trusted CA in your browser. However, do not install the issuer's certificate if you cannot verify their identity as a trusted CA.
This article on your particular error may provide guidance on why you're seeing this message. Here's a general description on how SSL works and what roles certificates and CAs play.
With regard to the first solution, if you end up having to install a CA cert into your Firefox browser, click Edit Trust and check the "This certificate can identify websites" checkbox. If that checkbox is not checked, then Firefox will still not trust websites who issue certificates signed by that CA.
Related
Does adding a certificate exception in Firefox tell it to trust a certificate, an address, or a combination of both? See the following hypothetical:
First, I hypothetically visit https://foo.com, which uses a self-signed certificate.
My browser alerts me that the certificate is self-signed, but I choose to add an exception (in firefox 40's settings under Advanced > Certificates > View Certificates > Servers).
Now let's say I go to https://bar.com, and it presents the exact same certificate. Will firefox trust this site, because it uses a trusted certificate, or will it warn me because the certificate is not trusted at this address?
Now let's say I re-visit https://foo.com in a couple weeks, and they have since generated and started using a new certificate (The CA is the same, but I have not added the CA as a trusted root). Will firefox show me a warning, because the certificate is not trusted? Or will it trust the site, because it is a trusted address?
Or is there another angle to this?
thanks
If you add an exception the certificate is trusted exactly for this site only, i.e. it makes an exception for the pair (hostname,certificate) and not for the certificate only.
That is you cannot create a certificate for example.com, make the user trust this (i.e. harmless site, make an exception) and later use the same certificate for a man-in-the-middle attack against paypal.com just because you've added paypal.com as an alternative subject into your self-signed certificate. There was once a bug which made such attacks possible, but it is long fixed.
I have followed http://www.robbagby.com/iis/self-signed-certificates-on-iis-7-the-easy-way-and-the-most-effective-way/ and https://www.sslshopper.com/article-how-to-create-a-self-signed-certificate-in-iis-7.html
When I go to the site, it still shows:
"The security certificate presented by this website was not issued by
a trusted certificate authority.
Security certificate problems may indicate an attempt to fool you or
intercept any data you send to the server."
An advice would be most welcome. I'm on Windows Server 2008 R2
If this is a self-signed certificate, you need to add the certificate or the root certificate which was used to sign the certificate to your browser.
If this is a public facing website, you may forgot to add the intermediate certificate authority certificates to the web server. If this is a public facing website, please provide the URL and I can help you more.
I'm new to mutual SSL. Therefore my understanding how client certifcates might be wrong.
When using Client certificates in IIS, do they need to be issued from the same certificate (or CA) as the IIS HTTPS binding has configured?
My dev IIS has a self signed certificate.
For the client certificate, I've created a CA and a Client certificate according to
the post here.
The CA is in my "Trusted Root Certification Authorities" of the local Computer.
The Client certificate is in my personal certificate folder.
On IIS I've set Client certificates to accept.
The first strange Thing is that when I browse to my page, the IE always shows me 403.7. Even I've disabled the IE setting "Don't prompt for client certificate selection...", there is no window opening for the certificate selection.
Also when accessing the page with a HttpWebRequest with Client cert attached, the response is always 403. Unfortunately there I did not figure out how to get the sub status.
Why doesn't IIS accept my Client certificate when the RootCA of the Client certificate is in the trusted root store?
Is there a way to get more details where the problem might be?
Thanks
Thomas
Finally could solve the issue:
The CA and Client certificates which I generated according to the tutorial here did NOT have the private key assigned in the certificate store. I had to remove the certificates from the cert store and Import the PFX file including the private key.
Second, the client certificate needs to be in the Current User/Personal store so IE does pick it up. I initallly generated it in the Current Computer/Personal store.
There might be a direct way how to create the two certificates including Private key with makecert. But the PFX import was the easiest way for me.
After 3 days of try and error on my side: If you use IIS10 on Windows2022, TLS1.3 is turned on by default.
The SSL handshake seems not to be implemented correctly in browsers/curls/.... for this case.
For testing reasons turn off TLS1.3
In
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server
Add:
DisabledByDefault as Dword with 1 and restart the server (not only IIS!)
I have created my SSL certificate using Selssl7.exe on server1 but used Cn as Server2 and hosted the certificate on server2. I started to get a certificate error when browsing from linux firefox saying:
This certificate is invalid, the certificate is not trusted and is self signed, the certificate is only valid for server1
But when I browse the URL from Windows IE I just get the regular error saying that it's not trusted and I can easily add it to exceptions.
Can we use self-signed certificates generated on server1 on a different servers?
You can and you may but you are pretty much undermining each and every aspect of authenticity by doing so.
A self-signed certificate is generally a problem because other users will not know this certificate in advance. So their browser dutifully issues a warning. That's why you have to pay for TLS certificates that will be recognized - they are issued by CAs whose certificates are contained in the default trust store of your browser. CAs had to pay to "be part of the club", but otherwise, anyone can create certificates. It's just the matter of being recognized by default settings.
But you open another hole by reusing a certificate that was issued for a dedicated server on a different server. TLS certificates' subject distinguished names must match the host name of the server they are deployed on. This is mandated by the TLS spec because this is the only effective measure to prevent man-in-the-middle attacks when using TLS. After you open a TLS connection to a server, your code will check whether the host name that you are connected to matches the subject DN of the server's certificate that was sent. Only if it does you can be sure to be talking to the right server.
So, in conclusion, if you reuse a server certificate on a different host, then you are severely impacting the security of TLS. It's still possible, sure, but if you cripple security to this extent, then you are probably better off using plain HTTP in the first place.
I issued a self signed certificate on IIS 7.5, and it is working correctly if i access my website through my computer.
However, if i access the website from another computer, i get an warning saying the certificate was issued to another address.
Is this because the certificate was issued to localhost instead of the actual IP?
Or this doesn't make any sense?
Regards,
The error message you are getting is normal, assuming you do not have anything in your certificate aside from 'localhost' to identify the owner.
Your browser is performing a name check, and looking to validate the certificate that is presented with the URL you typed in. Typically, the common name of a certificate matches the hostname/DNS name of the machine. Alternatively, there can be information inside of the Subject Alt Name (SAN) extension of your certificate. There, you could specify multiple DNS names or IPAddress fields that identify your server in addition to the CN.
If you are simply performing internal testing, I would not be terribly worried about the warning you are receiving. Just keep all of this in mind when you move to production. Also, having your CA being self-signed, you may also receive trust warnings, unless you manually import your self-signed CA certificate into the trust store of the browser you are using.
Maybe this helps you: Self signed certificates on IIS 7. At the end of the article, in the section named "Adding the Certificate to Trusted Root Certificate Authorities", an alternative solution is shown, but it implies importing the certificate in the client machine, so that could be a huge disadvantage. However, it is a solution if you can't register the certificate on a Certificate Authority, an you have access to the client machine.