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.
Related
Website Unavailable
The website you are trying to reach is unavailable because it use security service to prevent unauthorized access and online attack.
No information in the Cloudways KB - a broad search returned nothing so I'm adding this here for others.
Hosting provider says: This is a new security feature that is recently added to avoid domain mapping attacks on the websites so server will not serve a website if the domain name is not present in the Nginx domain relevant file.
To fix, in your cloudways hosting account:
Choose the application experiencing the error message
Choose ‘Domain Management’
Make sure ‘primary domain’ value is set, if it IS, (as it was in my case), change it and change it back - I added the www. to mine then went back to my preferred domain name without the www. That fixed it for me.
I’m building a web application where users can create their own websites. Users have the option to point their own domain names at these sites. A prototype for the application already exists; Apache accepts requests on all hostnames and the actual domain mapping and resolution happen at the application level (a simple database lookup grabs the site that matches the requested hostname).
Where I’m stuck is how users’ SSL certificates might fit into this equation. What steps would I need to take to allow a user to upload their SSL certificate such that the application could successfully handle secure HTTP requests to their hostname? Is this even something the application alone could handle?
I think you cannot handle this in your application alone.
It's a CA problem, except you are an intermediate CA company, or you cannot get the user's domain SSL certificate and sign for user's domain.
The typical user, and IMHO even more the user's who are going to create a web site of this system as opposed to setting up their own WordPress or other site on their own server (or their own paid shared server hosting account), will have absolutely no idea how to setup a proper SSL certificate, so getting it to your securely so that you can install it wouldn't even be an issue because they will never get that far.
However, you should be able to use Let's Encrypt to do exactly what you need. As part of the process of adding a domain, once the domain is pointing to your server (the users will have to figure out how to do that with their domain registrar), you can create a Let's Encrypt certificate and validate it. My favorite web hosting company (I won't name it as that is not relevant - anyone can do this with some effort) provides this capability as part of their Control Panel. They also provide paid certificates with a few of the big issuers, as they have for many years, but for most small sites Let's Encrypt works very well and is totally free. The setup literally takes only a minute. The key is that you have to give the user an IP address or CNAME first so that they can point the domain. Once the domain is resolving to your server, you can get the Let's Encrypt certificate.
We are setting up a website with secure and non secure pages. These have been added for mapping in uriworker.properties. The domain name in the urls are different . Example nonsecure url is x-y-z.a.b.org and our secure url is x-y-secure-z.a.b.org.Both of these domains are part of our DNS entry. We do not have any redirect rules configured within the webserver. But when we try to access the secure url https://x-y-secure-z.a.b.org, webserver is sending the request as http://x-y-secure-z.a.b.org:443. Due to the scheme not being https , the application does not identify this as secure request and is returning a 302 to the https url. This redirection happens infinitely and then an error appears which says that page is not redirecting properly.
After a lot of analysis , we figured out that the application had a hardcoded check on the scheme of the domain name to be in a certain format as secure.xyz.
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.
I have a virtual folder containing an administration application, like
https://www.mysite.com/alpha
which requires SSL. In the IIS manager properties for the folder, under "Authentication and access control", Anonymous Access is disabled and "Authenticated Access" is set to "Integrated Windows authentication."
When I connect to the site in Chrome, I receive two login boxes. The first is from mysite.com/alpha:443, and the second is from mysite.com/alpha:80. Firefox appears to re-send my credentials for the second box so it is never shown.
Any ideas why I'd be required to log in twice?
If you require SSL for authenticated users on your website (for any reason), then the best solution is to always have your "Login" page on https://. That way when they log in, they are instantly secure. The reason for this is because of the native design of SSL. It separates/secures it's self from the non secure version by not passing authentication states between http and https.
you will also have to write some logic to redirect returning authenticated visitors to the secure page (IE: visitors who can return authenticated from a cookie).
EDIT:
Since your using windows authentication, it's probably easiest to simply redirect ALL incoming http traffic to https. This means your entire site will be over SSL and will be inaccessible via http (other than to redirect to https)
I wrote a Blog Post on forcing a website to use WWW in the web address, but it can also be ported to forcing https.
Yep,
The one uses SSL, the other not.
therefore, you are not allowed to share the credential cache from a Secure session, with the one of the unsecure session.
if you require SSL, then directly redirect the users to the SSL website.