Why is there a name on one of the SSL badges, but not on the other one? Why do they look different?
The URL on the top uses GeoTrust, wile the bottom one only uses a RapidSSL certificate. Could that be the reason?
Out of curiosity, what is the reason behind this? Is the badge with name more secure and/or expensive?
SSL sites with the green bar are using Extended Validation certificates.
Digicerts' Extended Validation
They are more expensive and from what I understand they do a more extensive background check before they issue it.
Related
Im having issues with angular.io in my enterprise network caused by the certificate. Looking more in detail I noticed its been signed for *.firebaseapp.com. However it looks valid in my phone. Android screenshot
It doesnt make any sense, you cant have a valid ssl connection if the certificate was signed for another domain. Does anoyone understand whats happening with that certificate and why its look valid for my android browsers?
Thanks
If you look at the certificate details all look at the long list of Subject Alternative Names you will see that *.angular.io is covered under there. You can read more about those here.
Basically, it's just a list of hostnames that can used with one certificate.
.
I created a site and put it on Heroku. I then added a custom domain (e.g. "site.example.com") in the Heroku control panel and I pointed the DNS to my Heroku address. This works fine, but when I visit the site, I get a big browser warning, saying the certificate is for herokuapp.com, not for "site.example.com". How do I turn off HTTPS or fix it in some other way? (I don't need my own SSL certificate for the site.)
Note: It's not Heroku's fault if your app is forcing people onto SSL. Check production.rb to make sure it doesn't say:
config.force_ssl = true
If it does, change it to false:
config.force_ssl = false
Unfortunately, you can't prevent someone from attempting to access your site via SSL. That is to say that anyone can simply add https to to beginning of ://site.example.com. I would recommend that you open a support ticket to allow the Support team to look into your current configuration. Unfortunately, the Piggyback SSL that exists at *.herokuapp.com for Cedar apps bleeds through unless you have your own SSL certificate that is specified using the ssl:endpoint add-on.
The fact is, even if the Piggyback SSL wasn't in place, your visitors would still receive an error when going to the SSL version of your site. You might consider purchasing a seriously cheap SSL cert from some place like Namecheap (looks like you can pick up a super-simple cert for $8/yr) JUST to get rid of the errors. You can then enforce redirection to the non-SSL version of your site and all is well!
This may not be the best practice but nevertheless if you desperately want to force "NO-SSL", then you may do it via JavaScript code as follows.
window.onload=function(){
$(function(){
if(window.location.protocol==="https:")
window.location.protocol="http";
});
}
Currently Azure Websites don't allow custom SSL certificates, but they have wildcard SSL enabled for the *.azurewebsites.net domain. I need a secure login form for my web app, but with no custom SSL, it appears that I'm SOL.
Is there any kind of workaround for this? Would it be possible somehow to have a login form at https://mydomain.azurewebsites.net that creates a forms authentication ticket that will then work at http://mydomain.com?
Couple of months ago I had exactly the same problem i.e. application was built on Azure Websites, had to run on custom domain other than *.azurewebsites.net and had to allow secure login process.
Workaround for that we used was to embed an iframe (using secure protocol and .azurewebsites.net domain name e.g. https://oursite.azurewebsites.net/login) into non-secure page on custom domain (e.g. http://mysite.com/login). And entire login process was performed in the iframe.
There is one thing which you should be aware of, namely, lots of customers checks whether the page where they provide their credentials was using secure connection or not. In our case, secure iframe in non-secure page was causing lots of customer complains. Workaround for that problem was to put a message confirming that the login process uses secure connection. The message made some improvements, however, still certain number of customers complains remained.
I hope that will help.
This isn't really an answer to your question, but Microsoft are very aware that custom mapped SSL to websites is one of the most requested features for Azure websites and they have said they are working on it.
Scott Hanselman himself confirms it here
In the meantime, Tom's answer is a perfectly valid workaround.
One thing I would be very wary of though is with something Tom brings up: the security warning that the browser will present. You'd be amazed how many people freak out when they see that message and don't go any further! We have a fairly active ecommerce site and there have been occasions where we have accidentally used a none secure image path on an SSL page and we have always received emails from customers asking if our site has been hacked or similar!
The disclaimer that Tom mentions is a good idea, but I think it will still put some people off.
I am working directly with the WAWS team right now to produce some public guidance for this. A GitHub repository with the requirements is currently being evaluated by the team (I sent it over to them literally 1 hour ago). Hopefully, the solution will be approved and made public within a few weeks.
I can say this - the workaround won't be fully supported or much custom guidance given on its usage aside from the repository and accompanying documentation. SSL is, literally, the #1 priority for the product, and hundreds of people are working insane hours to make it happen for everyone. This workaround should also be considered temporary, as you'll no longer need it once the full SSL functionality is launched.
The Question
Is there a way to detect wether a visitor trusts the SSL connection/certificate? I really could not find anything on the web or on stackoverflow. I think it's a pretty uncommon question.
A Use-Case
I'm using a certificate from StartSSL. It works fine for most common and modern browsers. But on my Windows Phone using IE I get a warning. That's because the root certificate is not known to IE on Windows Phone by default.
The solution is easy: just download the certificate - two clicks/taps. I would like to provide a tiny guide to the common visitor on how to do this. However, only visitors with problems should get the message.
Visitors who connect to your site via HTTPS simply won't get to your site if they don't trust your certificate. Once an exception has been added, there's no way for you to determine whether or not it's generally trusted or an exception.
Perhaps you could try to build a list of user-agents and make a guess as to what their default CAs should be, so as to be able to display an additional message in this case. It's not a perfect rule (since you can never full control what the client trusts, it's the user/admin's responsibility), and has the disadvantages of user-agent specific content; in particular, it's not necessarily reliable, you won't have a complete database, and users who've already added the exception or imported the certificate permanently would see this additional message (unless you use something like a cookie to remember).
If your initial page is over plain HTTP, you might be able to try an XHR request to your HTTPS site and report whether it worked at all. (You might need to take into account the Same Origin Policy.)
I am not sure whether there is a foolproof way to auto-detect this condition. You may have to rely on a workaround.
Detect whether the request is from a phone by inspecting user-agent in the header, check whether it's the first time they are accessing your site (absence of your site's cookie etc.) and if they are first time user, redirect response to (HTTP) page with instructions to install the certificate. You can provide a check box on that page for users to supress that redirect behavior in furture. If they want it to be supressed, set a cookie, or store their preference on server (if there is authentication).
I've read through related questions but couldn't quite find what I am looking for.
I have set up a domain just as "domain.com" and created two subdomains "client.domain.com" and "client-intern.domain.com". Further, there is a redirect active for "client.domain.com/intern" pointing to "client-intern.domain.com".
If I buy a single SSL certificate for "client.domain.com", will the data transfer also be secured when the client is going to "client.domain.com/intern"?
Or do I have to purchase a second certificate for "client-intern.domain.com"?
Thanks in advance for clarification,
Paul
UPDATE: If entering "client.domain.com/intern" into the web browsers address bar, this address remains there and the browser shows the content of "client-intern.domain.com" nonetheless.
You need a wildcard certificate to cover multiple subdomains (in your case domain.com, client.domain.com and client-intern.domain.com). Some CAs might offer you an option to include one or two subdomains into the certificate (as alternative name field) for free or for a small additional fee, but this is CA-dependent and in general the right way is a wildcard certificate. You can read about wildcard certs here (GlobalSign site).