Aim:
I want to use free SSL certificate on Cloudflare on the website that is current hosted on Azure.
Background
A SSL certificate has been bought from Azure, but we found that we need to upgrade our subscription before able to bind it to our website. Hence, we decided to use Cloudflare free plan that also offers SSL. The domain provider that we use is godaddy.
Problem:
I have followed the instructions here, and now on the Cloudflare, I could see the status for SSL certificate as Active Certificate. However, when I enter the url as https://mywebsite (https), it says that This certificate is not valid (host name mismatch), which is shown on the screenshot below:
Questions
Why does the current SSL certificate points to .azurewebsites.net? Shouldn't it points to cloudflare, after changing the nameservers? What does it mean by host name mismatch?
Current status for SSL certificate on Cloudflare is Active Certificate, does it mean that it's verified and currently applied to the website?
Thank you very much!
You are correct, if it is configured properly it should display the correct certificate in your browser. Possible reasons that it doesn't show correctly: old certificate cached in browser, old nameservers cached, you're not using cloudflare for the appropriate DNS records.
1b. As for the host name mismatch, you typed in example.com and it returned a certificate for a different domain. This means that the data can still be encrypted during transmission but that you are probably not communicating with who you think you are.
Not necessarily. In the article that you link is a great diagram of this process (5th image). You are using Flexible SSL. In order for this to work your website needs to go to Cloudflare's servers first. You can have an active certificate but that doesn't mean that it's been applied to your website. Make sure that the domain and/or any subdomains are on cloudflare and that data is routed through Cloudflare's servers.
Related
I don't quite understand SSL certs. I have a website, www.contoso.com , from WIX, and then I have a subdomain, book.contoso.com , as an Azure web app.
I want to make the subdomain secured, and I was going to purchase an SSL cert from Azure. I was thinking that I might change the subdomain later, as in the "book." part. I was thinking that I might even make the subdomain my main website, as in point the "www." towards the Web App.
If I purchase the SSL cert, can I do this, change the subdomain and will the cert still be valid?
Thanks
Get a Wildcard SSL certificate to secure the domain name and unlimited subdomains under a single SSL installation. Azure supports third-party Wildcard certificates, but I'd consider a cheaper option from an SSL vendor than the one offered by Azure.
When you request the Wildcard certificate, add an asterisk (*) in front of the domain name you want to secure. For instance, *.contoso.com. This way, you can secure as many subdomains as you want.
The trickiest part is to install your Wildcard cert. Here's an Azure SSL installation guide you may find useful.
Ok, I have finally managed to get my node.js container up and running using a scalable container group and a custom domain.
The problem that now remains is: How do you get the self-signed certificate to be used by Bluemix when accessing the app through https://my-app.mydomain.com?
Https works, but it shows the wildcard *.mybluemix.net certificate instead of the one I added to the domain that I added to my organisation. Visiting https://my-app.mybluemix.net is ok since then the wildcard mybluemix.net certificate is valid.
Yes, I have seen this one as well as read the SSL part of the Bluemix docs.
developerWorks: SSL Certificates and Bluemix Custom Domains
Your DNS should use an A record pointing to 75.126.81.68. This IP address is used by Bluemix for SSL traffic in the US-South region.
If you are using an A record with 75.126.81.66 or use a CNAME record pointing to your app's route (e.g. my-app.mybluemix.net), then you will see the *.mybluemix.net certificate instead of your custom certificate that you uploaded to Bluemix and associated to your custom domain.
We have two websites in Azure under different subscriptions which use the same UCC SSL certificate. Everything had been good for a long time until a week or two ago we noticed that one of the sites does not really have our certificate (although it was configured in Azure successfully). When browsing to it using "https" we can see that "https" becomes red, and if we click on it it says: "Server's certificate does not match the URL". The detailed information about the certificate says that it was issued to "*.azurewebsites.net", not to our domain. So seems like the default Azure certificate is used instead of ours.
At the same time our second website works perfect with "https", and the certificate shown is correct. I re-installed the certificate to both sites and re-created SSL bindings using SNI SSL, but it still works only for one of them.
Any ideas on what can cause this?
In the Azure website configuration switch from SNI SSL to IP Based SSL.
Once you do that you should have a Virtual IP Address that can be found in the Dashboard tab of the Website on the Azure portal.
In your web hosting provider make sure the www and # records point to the Virtual IP Address instead of pointing to your xxx.azurewebsites.net URL.
I have multiple sites that need to have SSL certs installed on them but Amazon EC2 only allows one public IP. I can't use SNI since I need to support IE 7 and up. Is there a way I can have one instance with multiple domains each having SSLs?
Here is what I followed. I made a Private IP and another Elastic IP address that points to that private IP on the same Instance and followed these instructions
http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/config-windows-multiple-ip.html
One way around this is to use a UCC Certificate which will validate multiple domains.
This is very simple to set up as you serve up the same certificate for every domain but there a couple of wrinkles that may or may not matter in your case:
The certificate "Issued To" information will only list the primary domain name. A user would have to view the detailed certificate information to see this - the browser will correctly show the current domain as "verified".
All of the domains are listed in the certificate, so if you do not want sites to appear 'connected' to each other, you should not use this type of certificate. Once again, the user would have to display the certificate details to notice this.
I was asked to create a sharepoint web application with ssl on a server with sharepoint 2010 installed. The problem is that this port seems to be in use for hosting our subversion repository. So when i try to browse my sharepoint site, it just shows a page with my repository. I've read about installing certificates and configuring multiple sites on one port with host headers but i never succeeded to complete this job. I would really appreciate some help here.
Thanks!
Assuming you're talking about individual SSL certificates (as opposed to a single wildcard certificate), I believe each website HAS to have its own IP address. AFAIK it is not possible to run multiple websites with multiple SSL certificates under the same IP address.
Depending on who is hosting the server, you would need a new IP address to be allocated to the server, and then within IIS you use the new IP address against the hostheader of your new website. You should find that the certificate works correctly, if not then try removing the certificate from the website and re-allocating it.
You would only be able to use a wildcard certificate if the primary domains of the websites were the same (e.g. website1.mydomain.com and website2.mydomain.com).
Thomas,
I've run into a similar situation before where the requirements dictated that we use 1 ip address, but the domains will be different (eg. website1.com, somesite.org, website2.us).
You can achieve this by using a Unified Communications certificate with Subject Alternative names. Currently, Digicert offers a UC certificate that can achieve this, but some other CA's will not.
Essentially you will have 1 certificate bound to :443 on the same ip address. The big drawback to this is that if the cert goes down, all the sites SSL will not work.
You have to manually (via powershell) bind each domain to port 443 however, but the instructions are fairly simple.
Server Name Indication would be another way, but it's not even an option in IIS 6