Firstly I had working custom subdomain for my appservice.
Then I bought SSL wildcard Certificate and then generated pfx file with password. Next I uploaded certificate using Upload Certificate under Private Key Certificates. Certificate has Health Status = Healthy.
Finally, under binding tab I added TLS/SSL binging for my custom domain, choosen this certificate and its type = SNI SSL. Everything seems to be fine, undet custom domain there is SSL State = Secure and SSL Binding = SNI SSL.
When I go to my website - there is no information about any certificates.
I also tried the same with Create App Service Managed Certificate - the same effect, status Healthy, but certificate does not appear on the browser.
#mateuszwdowiak It sounds like you successfully added the SSL binding.
There are two main issues that I can think of that might have proceed the unexpected results that you encountered. Firstly, it can take some time for the SSL certificates to propagate out across the web. From my experience, I've seen it take up to 3 hours. Just because the Azure portal says it's binded, does not mean it will be getting served up just yet.
Secondly, I've seen browser cache also come into play.
It's been a few days but I wanted to see if you resolved this issue. If not, can you please try re-binding your wild card cert, wait up to 3 hours, and then using a fresh browsing session, attempt to browse your site. This should resolve the matter. If not, please reply back so we can assist you further.
Related
We have developed an angular website and we have both personal server and a registered domain extension. We were able to host through public ip using iis but when the domain name was used in throws NET::ERR_CERT_AUTHORITY_INVALID. It also redirects to https by default.
We also tried using xampp too. We don't want to use any cloud servers as our custom domain extension can't be used.
kindly help us to host the website.
As you mentioned the error message: ERR_CERT_AUTHORITY_INVALID.
This issue is related to your certificate. If you do not currently have a certificate, you can choose to create a self-signed certificate, or apply for a certificate from the Authority.
If you already have a certificate and still have this issue, you can check to see if it is expired and try renewing the certificate.
I purchased a standard SSL certificate through Azure, and it forced me to remove the www. prefix. I couldn't do DNS-type domain verification at the time, and imported the certificate got it verified on another means, and got the non-www url working with the new certificate.
However, when trying to bind the www version of the url, the imported certificate does not come up in the list, and the documentation indicates that this is only possible when the domain has been verified using DNS or email verification methods.
I subsequently inserted the required TXT record on the DNS for verification. However, the certificate still does not come up in the list for binding. Is there a way for me to get the verification done again and add www support, or is my only option to lose the money spent on a certificate and buy a new one?
I got hold of Azure support, and they introduced me to App Service Managed Certificates, which are free for Azure Web App use. So I created a new certificate for the www version of the domain and resolved the issue. I wonder if this covers all my web app needs and if I'll ever need to purchase a certificate again for Azure?
I used to run one of my websites (EyeDentity.Online) from a Windows VM on Azure. I had an SSL Certificate in IIS up to run it and all was well in the world.
Since I moved the Website to the Azure App Service and installed the SSL Certificate in Azure whenever I go to the Website for the first time in a browser session it tells me that the certificate is invalid.
It appears to quote the standard AzureWebsites.NET even though my certificate is bound to my website
How can I get this warning to go away as it may be scaring away users!
Things to check:
You must be on Standard or Premium level to bind to cert
Check SSL bindings section of Custom Domains and SSL blade to make sure you've
bound the domain to the right cert.
The description of the problem sounds like number 2 here. If you haven't changed this, then it will bind by default to the azurewebsites cert and not yours.
Some docs here: https://azure.microsoft.com/en-us/documentation/articles/web-sites-configure-ssl-certificate/
Your cert is for azurewebsites.net and not EyeDentity.Online. You should get a wildcard cert for your domain name:
*.azurewebsites.net should be: *.eyedentity.online
ref: https://azure.microsoft.com/en-us/documentation/articles/web-sites-configure-ssl-certificate/#1-get-an-ssl-certificate
"Before requesting an SSL certificate you must first determine which
domain names will be secured by the certificate. This will determine
what type of certificate you must obtain. If you just need to secure a
single domain name such as contoso.com or www.contoso.com a basic
certificate is sufficient. If you need to secure multiple domain
names, such as contoso.com, www.contoso.com, and mail.contoso.com,
then you can get a wildcard certificate, or a certificate with Subject
Alternate Name (subjectAltName)."
I have a bunch of node.js apps serving information to an apache site via websockets (ws://). The site itself doesn't have a domain name and is accessed through its IP address (that's non-negotiable, unfortunately...)
The problem is the following :
Without a secure connection, browsers will block the ws://
traffic, so I have to use SSL and secure websockets wss://
Without a domain name, I cannot secure the connection except by
generating a self-signed certificate.
Self generated certificates are not trusted by browsers and
display an error 'certificate not trusted...'. Last chrome update
made it even more annoying to get through the message.
In addition to that, the IP changes regularly and is sent to the users (2-3 people) when it happens. So a certificate issued for a specific IP wouldn't be ideal (if it's free I can deal with the hassle of refreshing the cert).
Does anyone have a solution ?
If you only have a user or two, you could create your own CA, and have each person install it on their browser. You would still need to update the cert every time the IP changes though. google.ca/search?q=create+your+own+ca
One great advantage of using Azure Websites is that I can get secure HTTP (HTTPS) without doing nothing: I simply type https://xyz.azurewebsites.net and it works. I don't have to worry about certificates because I use the subdomain that Azure gives me (in the example it would be xyz)
So, what I usually do is that people come by through some registered domain I have, eg. http://www.my-application-homepage.com, and there, if they want to use my application, I redirect them to the subdomain at azurewebsites.net, using HTTPS.
Now, having said that:
I'm in need of upgrading to Azure Cloud Services or Azure Virtual Machines, because these have capabilities that Azure Websites don't . These two also offer a free subdomain: xyz.cloudapp.net, but my question is: will I get HTTPS there too? and how?
I searched in google for some cloudapp examples and what I tested was the following:
1) Connect through HTTP (ie. type http://xyz.cloudapp.net). Result: worked
2) Connect through HTTPS (ie. type https://xyz.cloudapp.net). Result: didn't work (chrome gave ERR_CONNECTION_TIMED_OUT)
No. HTTPS is not offered for .cloudapp.net domain as of today. Also since you don't own .cloudapp.net domain, I don't think you can buy a SSL certificate for that. If you want you could create a self-signed certificate and use that.
I would walk through the documentation listed here:
http://azure.microsoft.com/en-us/documentation/articles/cloud-services-configure-ssl-certificate/
Since you're getting a timeout with HTTPS (rather than a certificate error), check that you have a HTTPS endpoint defined in ServiceDefinition.csdef.
Additionally, be aware that the redirect-to-subdomain approach isn't much more secure than using a self-signed certificate. The reason browsers reject self-signed certs is that they are vulnerable to spoofing attacks: a user can't detect if an attacker has, for example, hijacked the DNS to point to his IP address instead of yours, where he hosts a facade of your site that just collects passwords or whatever.
In your scenario, the cloned site could redirect to another a second clone, one that is a facade of your cloudapp.net site. It could be even be secured with the attacker's SSL certificate. Unless the user was trained to recognize the host name of the real cloudapp.net, she wouldn't know she was on the attacker's "secure" site.
** Update: This method is not valid as well, we got the certificate revoked after one week using it **
We use this approach for staging/dev servers:
If you don't want to use a self-signed certificate, one option is to purchase a cheap SSL certificate, e.g.:
https://www.ssls.com/comodo-ssl-certificates/positivessl.html
Then once you need to approve it you have to ask support to change the approver validation process: instead of sending an email to a admin#mydomain.cloudapp.net you can ask to change the validation process to placing a given file with a given file in the root of your website (you have to ask in the support / chat room about that option).
More info:
https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/791/16/alternative-methods-of-domain-control-validation-dcv