When I try to get data in a mobile flex app from a secure site, I get following alert:
A secure connection with this site cannot be verified. Would you still
like to proceed? The certificate you are viewing does not match the
name of the site you are trying to view.
For each call, I get the popup. If I keep on clicking Yes, the app works fine (but I would like to avoid that ;-)).
Any ideas? Apparently, the url from where the request comes, is not the same as defined in the certificate... But what is the url if called from a mobile app (standalone)? It's neither an error, because you can click on yes. So it's more that the client gives a warning. The annoying thing is that you can't accept it permanently...
This is the same whenever a cert is not correct and chrome or firefox alerts you and asks if you want to proceed. You cant accept a faulty cert on the behalf of your users. The easiest way to fix this is to tell the site owner to get a proper cert.
Check with your system administrators of website whether certificate installed is issued for your domain. It appears that certificate is issued for a domain https:///xxxx where as it is installed on https://yyyy
Bypassing is OK for testing , it seems finally you will have to get this corrected
In my experience this only comes up with self-signed certs, expired certs, and when you are calling the cert by a URL that is not identified in the cert.
With most certs they are associated with a single host/domain combination, i.e. https://www.domain.com
That means that they cannot be used with any other domain host combination. Not even http://domain.com or https://sub.domain.com.
There are certs that will support different hosts on the same domain (www.domain.com, sub.domain.com, etc). They are called wildcard cert. They are very expensive compared to normal single domain certs.
My guess is that in the browser you are calling www.domain.com but in your AIR app you are calling domain.com or calling some other host. That or you have permanently accepted the improper cert in the browser.
I have never have a problem with anything improperly identifying a valid cert. Not a browser, Flex app, AIR application. Ever.
If you view the cert in the browser you should be able to see what domain/host it is registered to. Make sure you are using exactly that. Any variation will cause the error.
As a temporarily solution I added some exceptions to the URL Rewrite Module, so that communication by Mobile App can be done with HTTP. But it's no longer secure, so I would rather use HTTPS.
I have also faces this issue and simple solution is fixed the certificate issue. If not possible then forget about using the HTTPS use HTTP only. So you never get any complain about any certificate issue.
Related
I have deployed my app for about 3 months now, but I'm still seeing different SSL certificate. Also, it seem that it has renewed it using different domain. Is this still normal? If yes then how long does it normally take to complete a provisioning? Is there a way use my own certificate instead? ... Since it's just using LetsEncrypt after all.
Domain connected:
Domain mismatch:
Any idea?
It looks like they take advantage of an extension to the X.509 standard known as Subject Alternative Name. From the Firebase documentation:
Your domain will be listed as one of the Subject Alternative Names in the FirebaseApp SSL certificate, which is publicly viewable. While the domain is provisioning, you may see an invalid certificate with that does not include your domain name. This is a normal part of the process and will resolve once your domain's certificate is available.
Indeed, you name appears in the list, along with several others.
(Sorry, my system is in Italian)
EDIT: by the way, Firefox shows the right (alternative) name in the Page Info tab and so does Edge, so it's much more likely to be a Chrome related glitch, but the certificate is valid.
I have a Comodo SSL certificate on my host plan, however when accesing my site from google, it sends me automatically to
http://example.com, Where the green lock doesn't appear.
If I manually add "https", like: https://example.com it does show up!
Is there a way to access my website always with the green lock showing up? instead of manually having to write it everytime?
You can easily redirect to the https version of any page using rewrite rules/rewrite module of your web server (the exact way to do this depends on the webserver used). Ask your provider, this is a common case so there may even be a UI option in your console to do this.
Regarding google see this: https://webmasters.stackexchange.com/questions/67212/how-to-convince-google-to-list-https-version-of-website
It may also be good form to verify the protocol used to access the site in your authentication module and refuse authentication if the wrong protocol is used. Assuming web rules are used to redirect traffic this would to prevent leaking information due to a misconfiguration/bug.
I have some JS that is on some intranet application that's running on HTTP (this server/service is out of my control, run by the customer). I operate the internet application and it must run on HTTPS for security purposes.
I'm attempting to use XDomain but I'm finding that the cookies aren't being sent. Is the problem that I'm going intranet to internet or that I'm going HTTP to HTTPS or some configuration problem?
I keep getting 401 when checking authentication of the user even after they have logged in.
I've verified the backend/internet service works as expected via a jsfiddle (i.e. Access-Control-Allow-Origin, etc. are all correct).
Thanks!
There are some security related issues with XDomain that makes it strip any cookies according to no 5 in this msdn blog. However there also exist a workaround using proxy with example project on Github. I think everything you need to make it work are described in those two pages.
I have a web site developed in Asp.Net and it is hosted in cloud. Site is running on https protocol and certificate is issued to domain (E.g. example.com ) and subdomain (*.example.com). It works well if user types example.com or app.example.com. However some user types URL incorrectly. They type something like www.app.example.com. In this case browser displays warning about certificate. It states something like this “This server could not prove that it is www.app.example.com; its security certificate is from *.example.com. This may be caused by a misconfiguration or an attacker intercepting your connection”
This is perfectly fine since subject name (or issued to) is not matching since it involves two subdomains i.e. first subdomain is www and another subdomain is app. Many user scare to do that and they will leave the web site. By googling I found, problem can be fixed by regenerating the certificate with additional subject alt names such as *.example.com and ..example.com. But IT staff do not want to regenerate the certificate for some reason. Is there any alternative to fix this problem without regenerating certificate. Expectation is that any error message should not be displayed and any extra action should not to be required from the end user.
I have tried with redirect rules in IIS. But they are not working.
Platform details – Asp.Net MVC 5, IIS 7.5 and Windows Server 2008 R2 datacenter
Is there any alternative to fix this problem without regenerating certificate.
No. The certificate must match the name. If the certificate does not match user gets an error. There is no way around it and if there would be one this could be considered a security risk, because without a proper name check man-in-the-middle attacks would be possible.
I have tried with redirect rules in IIS. But they are not working.
Redirects are done at the HTTP level, which means with https it first needs to establish the SSL connections. If this fails because of the name mismatch then the redirect will not be reached.
I was recently looking around at some of the features my current web host offers, and am now wondering about a few things. Even if you can only answer part of this, I appreciate any help you can provide.
I have a domain, mydomian.com, and the host offers shared SSL so I can use HTTPS by using this address https://mydomain.myhost.com. The SSL certificate is good for *.myhost.com.
I don't know a lot about SSL, but I'm assuming this means that the data between site users and ANY domain on myhost.com is encrypted. So was curious if this meant that if someone else on the same host as me somehow intercepted the data from my site would they be able to view it, since they would also have a https://theirdomain.myhost.com address, which uses the same SSL certificate? I may have no idea at all, and this was pretty much a guess.
If HTTPS is used on a login page, but after logging in the other pages are viewed over HTTP, is this a security issue?
Is there any way to show a web form via HTTP for bots like Google, but have real users redirected to the HTTPS version? Would be ideal if this could be done via .htaccess. I currently have some rewrite rules that redirect certain pages to HTTPS, but the rest as HTTP. So if a visitor visits the contact form they get the HTTPS version automatically, but it automatically switches back to HTTP for pages that don't contain forms. So, via htaccess, is there a way to direct real users to the HTTPS version, but have bots directed to the HTTP version? I would like these pages to still be indexed by the search engines, but would like users to see it via HTTPS.
Thanks in advance for any help you can provide.
I'm going to guess you'll be okay for number one. If your host does it correctly, individual subdomains never get to see the SSL keys. Here's how it would work:
Some guy with a browser sends an encrypted request to your subdomain server.
Your host's master server receives the request and decrypts it.
The master server sends the decrypted request to your subdomain server.
And any HTTPS responses you send back go through that process in reverse. It should be easy to check if they've set things up that way: If you can set up shared SSL without personally handling any key files, you're good. If you actually get your hands on some key files... not good.
For two: If you encrypt the login, you protect the passwords, which is good. But if you switch back to HTTP afterwards, you open yourself up to other attacks. See: Firesheep. There may be others.
And for three. Yes - definitely doable. Check out mod_rewrite. Can't give you an example, as I've never used this particular case, but I can point you to this page - particularly the section entitled "Browser Dependent Content."
Hope that helps!
Every traffic is encrypted, when you use https:// as protocol. (Except for some uncommon circumstances I won't talk about here). An SSL certificate's purpose is to prove the identity of the server, by combining it's public key with an identity. This certificate is only usable with the private key that belongs to the public one. In your case it seems that this certificate as well as the key-pair is provided by your hosting provider. I guess that neither you nor the other customers on the host have access to this private key. That means that only your provider is able to decrypt the traffic. Since that's always the case (he's running the server, so has access to every data), that should be no problem.
In most cases it is a security issue. On every further unencrypted http-request the client has to provide some information of the session to the server. These can be intercepted and used by an attacker. (simply speaking)
The bots should support https, why not redirect them? Anyhow: The important part is not to provide the page containing the form via https. To protect your user's data you should take care that the response is transferred via https.