I've just installed SSL on my server (shared reseller package).
Its my first time using SSL and I couldn't get it working properly in Chrome or Firefox. Obviously this was because many of the CSS/JS/etc. links were not "https", but "http".
I've modified the necessary files and now Google Chrome is displaying a nice green padlcok and confirms my pages (checkout/login/controls/accountools).php are all secure.
However, if I open up the page in Firefox, instantly I get:
This Connection is Untrusted
You have asked Firefox to connect
securely to www.domain.co.uk, 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.
Contrast this to Google:
Your connection to domain.com is encrypted with 256-bit encryption.
The connection uses TLS 1.0
The connection is encrypted using AES_256_CBC, with SHA1 for message authentication and DHA_RSA as the key exchange mechanism
What's more, the other browsers (MSIE, Safari, Opera), didn't bat an eyelid even when the pages were technically "unsecure" due to the CSS/JS/images, etc.
I know I can simply add my site to the trusted list in Firefox, but this doesn't look good for me when someone comes along and sees "UNTRISTED WEB SITE" before they even get to the checkout/login pages etc.
How can I fix this?
Complain to the iSP. The SSL certificate isn't properly signed.
Related
I'm new to Jmeter and I have the following case:
I'm trying to record using Jmeter by going to github.com/login. I set localhost and port to jmeter, also to Mozilla. Certificate created by jmeter is added to mozilla.
If I access for example stackoverflow, it works, but if I want to go to github I don't have the button Accept the risk and continue as it was for stackoverflow, therefore github can't be accessed. I even installed a clean Mozilla in order to not have any old certificate for github.
Does anyone know why is this happening?
jmeter configuration
github certificate message
firefox proxy config
Later edit: This is how it looks for example
stackoverflow
I'm not able to access facebook, google besides github.
It is a matter of certificate installation. Once you install the certificate, there shouldn't be an "Accept the risk and continue". Rather you should be able to directly navigate to the website.
Please try the below steps to install appropriately in Firefox
Launch Firefox -> Navigate to Options -> Search Certificates -> Click View Certificates -> Click on "Authorities" tab -> Click Import -> Choose certificate file types to include ".crt" files in the File Browser Pop-up -> Choose "ApacheJMeterTemporaryRootCA.crt"
Pop-up such as this should appear if you have followed appropriately
Check Trust this CA to identify Websites -> Click OK -> Navigate to Authorities tab once again -> Ensure JMeter certificate is available
If all the above steps are followed, you should be able to record https://github.com/login without any hiccups
Why this error appears in the first place
Basically when a browser tries to access a website via HTTPS, it tries to establish a secure connection post validation of the SSL certificate. In our case, since JMeter is the proxy with which Firefox interacts, Firefox believes it is the actual server and hence it is trying its best to ensure your safety by preventing you from sending the request since JMeter's SSL certificate is not one of the approved SSLs (not part of Trusted CA certificates).
How the certificate helps
When you add the JMeter's Root CA certificate into Trusted CA folder, you let Firefox know that SSL provided by JMeter is trustworthy and hence things are alright
Hope this helps!
You need to import JMeter's certificate into Firefox browser in order to be able to intercept and decrypt secure traffic, see HTTPS recording and certificates chapter of the HTTP(S) Test Script Recorder documentation for more details.
Remember that JMeter's MITM certificate has limited lifetime (7 days as of JMeter 5.3), so it might be the case you need to re-import the certificate if it's expired. The lifetime of the certificate is controlled by proxy.cert.validity property
If you still experience problems try cleaning your browser history and remove everything from the beginning of the time, it will remove cached certificates as well
More information: Recording HTTPS Traffic with JMeter's Proxy Server
Also be aware that you can use an alternative way of recording a JMeter test - JMeter Chrome Extension, in this case you won't have to worry about proxies and SSL certificates
We run an e-commerce site. Last week we renewed our SSL certificate and our web hosting provider inexplicably put the wrong web address on the new certificate.
So when we visited the site - browsers were giving us security errors, (and presumably to any customers during that time).
Once the SSL was fixed, we were able to access the site by either clearing the browser cache or using a different browser.
My question is: Will browsers automatically reset the cache after a period of time for our customers?
My concern is, unless customers manually clear their browser cache they will continue to think our site is unsafe.
There is no such thing as a SSL cache for failed attempts. If the browser connects first to a site with HTTPS it will get the certificate and validate it. If the validation was successful the browser might cache the current TLS session for reconnects - but only if the server sends a session id or session ticket for the TLS session. If the validation and thus the connection fails the browser caches nothing. And even if the browser tries to resume a TLS session later it depends on the server if this resumption is accepted at all - otherwise again a full handshake is done which involves getting and validating the certificate.
While you don't describe it this way I rather suspect that there was a wrong HTTP redirect, i.e. something like redirecting from http://example.com to https://wrong.example.org instead to https://www.example.com. Given the problems you describe this was likely a 301 "permanent" redirect which means that the browser can cache this redirect forever. See How long do browsers cache HTTP 301s? for more on this.
after upgrading to Safari 9 I'm getting this error in the browser:
[Warning] [blocked] The page at https://localhost:8443/login was not allowed to run insecure content from http://localhost:8080/assets/static/script.js.
Anyone knows how to enable the running of insecure content on the new Safari?
According to the Apple support forums Safari does not allow you to disable the block on mixed content.
Though this is frustrating for usability in legitimate cases like yours, it seems to be part of their effort to force secure content serving / content serving best practices.
As a solution for you you can either upgrade the HTTP connection to HTTPS (which it seems you have done) or proxy your content through an HTTPS connection with an HTTPS-enabled service (or, in your case, port).
You can fix the HTTPS problem by using HTTPS locally with a self signed SSL certificate. Heroku has a great how-to article about generating one.
After setting up SSL on all of your development servers, you will still get an error loading the resource in Safari since an untrusted certificate is being used(self signed SSL certificates are not trusted by browsers by default because they cannot be verified with a trusted authority). To fix this, you can load the problematic URL in a new tab in Safari and the browser will prompt you to allow access. If you click "Show Certificate" in the prompt, there will be a checkbox in the certificate details view to "Always allow content from localhost". Checking this before allowing access will store the setting in Safari for the future. After allowing access just reload the page originally exhibiting a problem and you should be good to go.
This is a valid use case as a developer but please make sure you fully understand the security implications and risks you are adding to your system by making this change!
If like me you have
frontend on port1
backend on port2b
want to load script http://localhost:port1/app.js from http://localhost:port2/backendPage
I have found an easy workaround: simply redirect with http response all http://localhost:port2/localFrontend/*path to http://localhost:port1/*path from your backend server configuration.
Then you could load your script directly from http://localhost:port2/localFrontend/app.js instead of direct frontend url. (or you could configure a base url for all your resources)
This way, Safari will be able to load content from another domain/port without needing any https setup.
For me disabling the Website tracking i.e. uncheck the Prevent cross-site tracking worked.
I'm working on a web application that uses the google earth plugin. Recently, a new requirement to have non-public users logon was added, which meant that some users were now using the site over https. Among the things that broke in testing were the custom placemark icons (They were working using http).
The icons are hosted on the same server which servers the page.
Here are the urls for each of the protocols.
http - http://localhost/Images/yellow.png
https - https://localhost/Images/yellow.png
I can follow that link and the image will appear as you would expect.
The images hrefs are declared as icon styles in dynamically generated kml.
I want to avoid loading the images over http because I think that will cause internet explorer to present the user with a mixed content warning.
How do I get the images to load properly while using https?
I have been wrestling with this myself -- the short answer is that this won't work. If the content is served off of an HTTPS site that generates any kind of error/prompt (authentication, invalid certificate, etc.) the plugin will simply not load the content.
Interestingly, the desktop client works fine and prompts the user for credentials if necessary. However, neither client will allow content to be served off of site with an untrusted certificate.
The only workaround that I have found is:
Use a trusted HTTPS certificate on the server hosting the content (either trust the certificate on the client systems or just use a real certificate.)
Do not use HTTPS basic auth as that will always generate 401/Challenge responses which the web browser client will simply ignore
If authentication is a requirement, use NTLM authentication and common (e.g., domain) logins. If you load the plugin in Interent Explorer (or in a .NET WebBrowserControl) the authentication will be handled properly and the images will show up.
I was at a Google Earth administrator's training last week and the trainer confirmed this "bug". It is supposed to be fixed in the next version of the plugin (it may actually be fixed already -- what version of the plugin are you using?)
I have a problem with my site after implementation of SSL that images do not appear. The scenario is that images come from images.domain.com (hosted on Amazon S3) and my certificate is for www.domain.com.
This problem only seems to happen in IE and not in any other browsers.
The issue is related to "mixed content" - HTTPS pages which have HTTP resources (images, scripts, etc) embedded.
The point of using HTTPS is to ensure that only the originating server and the client have access to the secured page. However, in theory it might be possible for this security to be compromised if HTTP resources are embedded - a server might intercept an unsecured javascript file and inject some code to alter the secured page onload.
Most browsers will indicate that a secure page has mixed content by altering the "secure lock" icon, either by showing the lock as open or broken, or by making the icon red (Chrome displayed a skull and crossbones for a short time, but they realised that this was a bit serious for the potential threat level).
Internet Explorer (depending on the version) will display a message either asking whether the insecure content should be shown (IE<=7), or whether only the secure content should be shown (IE>=8). It sounds like you have somehow disabled this message to always hide the insecure content, however that's not the default behaviour.
I think the best solution for you is to replace your S3 links with HTTPS versions.
I am not a web developer, but someone who often deals with the crap experience that is IE. I am not sure what version you are using, but you do not have a wildcard SSL cert (i.e. *.domain.com), so does it have something to do with an old-school limitation in 3rd party images?
See here for what I allude to above and a very good explanation of how IE caches cross-domain HTTPS content, specifically images. I am not sure what the solution is, but I was curious so I researched a little myself and this might help.