Does anyone know if you can bind a CTL to a website if it is using the central certificate store?
Normally I'd use the netsh http command to bind a CTL, but it doesn't seem to accept the sslctlidentifier switch
Related
I have build a new webapp on Azure. So i followed that steps:
Add A Record (A/#/52.173.76.33), a CNAME (CNAME/www/saschamannsde.azurewebsites.net) and a TXT (TXT/#/saschamannsde.azurewebsites.net)
Added a custom domain to the webapp (Then it is listed as available host)
Upload the PFX and CER and bind it to my domain.
Azure now shows me, that it is a valid Certificate with my hostname saschamanns.de and issued by Sectigo RSA Domain Validation Secure Server CA (ID 134d36755287a5e0718554ff9c9103d13f331d34).
If i now typing https://saschamanns.de the browser tells me, i have a false cert, issued for shortener.secureserver.net.
Inside the Supportpage of Azure it tells me two problems:
Certificate mismatch detected (
The hostname saschamanns.de is configured to a Certificate with the thumbprint 134d36755287a5e0718554ff9c9103d13f331d34 on this Azure web app. However, the site returned a certificate with thumbprint 22873d8fefeb318394d1b906a5e4657876552d80.) A traceroute gives me:
https://paste.ubuntu.com/p/5427RCBmMF/
And it looks like it routes to the MS Routes.
DNS resolution error detected (As per the current DNS settings, URL saschamanns.de resolves to 184.168.131.241. The web app on Azure however is configured to listen on 52.173.76.33.)
But i have already set the IP to 52.173.76.33. The other IP comes from my Domain Manager GoDaddy.
Maybe anyone can help to identify the problem?
From the Dig web interface , saschamanns.de is also pointing to 184.168.131.241 . What is this 184.168.131.241 ip ?
saschamanns.de. 599 IN A 184.168.131.241
saschamanns.de. 599 IN A 52.173.76.33
If you browse the web app , certificate ( Thumbprint : 22873d8fefeb318394d1b906a5e4657876552d80) showing in browser is issued to shortener.secureserver.net .
Certificate which is binded to web app is not issued to saschamanns.de
Can you try bind the certificate again to web app by removing the existing one. Hopefully that should resolve the issue.
I also just ran into the same issue. Basically, the reason why I got the certificate mismatch error was according to the Forwarding Feature of GoDaddy.
If you use the forwarding feature - it will add a locked "A record" entry to the domain pointing to ip.secureserver.net which in my case was 184.168.131.241.
However tanner west explains the forwarding issue in a gist article.
In a nutshell, don´t use the forwarding feature and edit the DNS forwarding manually.
This is the feature I am talking about.
Say, I have two app service (HTTPS only is enabled):
https://myapp1.azurewebsites.net
https://myapp2.azurewebsites.net
I can call both app service endpoints using HTTPS successfully.
Then I created a traffic manager and add above two endpoints to traffic manager, say:
myapps.trafficmanager.net
After the traffic manager is created and endpoint added, the trafficmanger host name myapps.trafficmanager.net is also automatically added into custom domains of two app services. But without SSL binding to traffic manager host name.
Then if I call traffic manager endpoint using HTTPS: https://myapps.trafficmanager.net, I will got untrusted SSL cert error/warning. That is expected.
Since traffic manager just works on DNS level, the real request is actually send to the app service endpoint which has correct SSL cert binding. My question is:
From security point of view, is it safe to call the non-cert binding traffic manager endpopint using HTTPS in my code (say, using .NET HttpClient) but just ignore the cert error?
I recently set one of these up as well and fought with it for a bit. The short answer is that it is probably safe, but it sounds like you may be using the Traffic Manager incorrectly. You shouldn't be using the URL in the Traffic Manager as your end point if you want to use SSL. Instead configure your vanity domain name, mycoolsite.com to point to myapps.trafficmanager.net, using a DNS CNAME record.
If you want to use SSL and a single URL you should configure the custom URL and install an SSL cert at the service level. It should be same custom URL on both app services. This must be configured at in the app service, not in Traffic Manager.
I had to read this a few times to understand how it works under the hood, but it was helpful.
So in summary, to set it up properly, the steps would be:
Configure custom/vanity domain on both app services
Install the SSL cert on both app services
Setup and configure the Traffic Manager
Point the custom/vanity URL to the traffic manager using a DNS CNAME record
There is no need to bind a cert with traffic manager since the server certificate is not validated when using traffic manager health probes via HTTPS. Moreover, the traffic manager works at the DNS level. The clients connect directly to the selected endpoint, not through Traffic Manager.
In this case, you could use HTTPS for endpoints and use health probe via HTTPS. Even you could not bind a cert with traffic manager, you could make sure that the monitoring port is configured correctly in Traffic Manager (e.g. 443 instead of 80) and also your monitoring path points to a valid page for your service.
Another SO answer explains this more details. If you still want to make this warning disappearing, you can get a free SSL from letsencrypt.org and add that to your custom domain with the *.trafficmanager.net.
I'm trying to use https://mysite.trafficmanager.net that should resolve to https://myfunction.azurewebsites.net without adding my own SSL cert or domain.
When I go directly to https://myfunction.azurewebsites.net the cert is valid, but when I go to https://mysite.trafficmanager.net I get a cert error saying the cert is issued to *.azurewebsites.net
Do I have to purchase my own SSL to get this to work? It seems like the certs should just work within the Azure family and that I'm just missing a configuration setting.
You get a cert error since myfunction.azurewebsites.net have a certificate for *.azurewebsites.net but not *.trafficmanager.net so traffic manager site is not secured unless you have a custom domain + SSL cert.
The azure traffic manager works at DNS level. This means that it does not handle any request, just making the right redirection. The clients connect directly to the selected endpoint, not through Traffic Manager.
If you want to access the endpoint via HTTPS, you just need to bind an SSL certificate on your endpoint. If you want this error to disappear, you can read this Azure networking feedback.
For a dev\test scenario, there are a couple options you may want to
consider:
Buy a real cert and domain/sub-domain for your dev-test setup.
Create a self-signed certificate for your site with the *.trafficmanager.net SAN added to it and install this self-signed cert to the Trusted Certificate Authorities store on your clients to not
get browser warnings.
I have an F5 load-balanced 4-server cluster environment that I'm building, so I'm looking to centralize our certificates to prevent needing to install them all on every server. Windows 2012 / IIS 8 seems to have centralized certificates, but that is only to secure my endpoint in IIS for inbound traffic.
What about for outbound traffic? They all will be initiating TLS transactions to external entities, so I need a way to store all these on a single server and have each of the IIS boxes "tap into" that cert store for the private and public keys that are necessary to send that TLS message.
Any suggestions?
You're looking for an HSM which the F5 will support and IIS also supports a few major vendors (Thales and Safe-Net both have IIS supported HSMs). They're not cheap from what I remember but that's exactly what you're looking for.
If you don't want to go that route, you can opt for the dirty solution of using the BIG-IP as your cert store and rely on self-signed certs on the IIS pool members.
Inbound: Incoming traffic terminates on BIG-IP using the valid CA-signed cert SSL Client profile. BIG-IP re-encrypts to IIS using a generic SSL server profile. Not pretty but it works.
Outbound: You would have to use the BIG-IP as the default gateway of the IIS server so you can direct the outbound TLS from BIG-IP instead of IIS directly.
Devcentral: SSL Acceleration - Can I encrypt outbound traffic
Hope this helps.
-Chase
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