We have a Local Service Fabric Cluster running. We are using Windows Security to control who can administer the cluster.
When connecting to the Gateway Endpoint to use the configuration manager, we are currently connecting over HTTP, but we'd like to connect over HTTPS.
We have added an SSL Certificate that we use for connecting to the reverse proxy, and we'd like to use that same certificate to connect to the Gateway Endpoint.
I can see in the generated config on the cluster that the HttpApplicationGatewayEndpoint port is using https, which I think turned on because I set the "ReverseProxyCertificate" setting.
<NodeType Name="NodeType0">
<Endpoints>
<ClientConnectionEndpoint Port="19000" />
<LeaseDriverEndpoint Port="19002" />
<ClusterConnectionEndpoint Port="19001" />
<HttpGatewayEndpoint Port="19080" Protocol="http" />
<HttpApplicationGatewayEndpoint Port="19081" Protocol="https" />
<ServiceConnectionEndpoint Port="19003" />
<ApplicationEndpoints StartPort="20001" EndPort="20031" />
<EphemeralEndpoints StartPort="49152" EndPort="65535" />
</Endpoints>
<PlacementProperties>
<Property Name="NodeTypeName" Value="NodeType0" />
</PlacementProperties>
</NodeType>
How can I make the HttpGatewayEndpoint have Protocol="https" instead of "http"?
Related
I have wix setup project. Following are things to happen:
Enabling IIS
Instaling a self-signed certificate
Adding custom https port
And finally referencing the certificate to the port.
After the setup is successfully installed, the bindings added in Default Web Site are default ports for http (80), https (443) and the custom https port. But in IIS manager it can be ssen that both the https port does not have any certificate referenced.
Whereas, while checking fro command prompt with following command netsh http show sslcert ipport=0.0.0.0:443, the self-signed certificate is refernced to both the https ports.
Following is the certificate install code in wix setup project
<Component Id="Certificate" Guid="random-guid"
Permanent="yes" Directory="WWWROOT"
KeyPath="yes" >
<iis:Certificate Id="cert"
BinaryKey="Certificate.Binary"
Name="SelfSignedCertificate"
Request="no"
StoreLocation="localMachine"
StoreName="trustedPeople"
Overwrite="yes"
PFXPassword="PASSWORD"/>
<iis:WebSite Id="DefaultWebSite"
Description="Default Web Site"
ConfigureIfExists="no"
Directory="WWWROOT" >
<iis:WebAddress Id="AllUnassignedHttps"
Port="450"
IP="*"
Secure="yes" />
<iis:CertificateRef Id="cert"/>
</iis:WebSite>
</Component>
Question: Why is certificate refernced to both the https ports?
I have a Mule application which needs to talk an external server over HTTPS using 2 way SSL authentication.
My question is: How to enable Server Certificate verification in Mule ? It seems, by default Mule doesn't verify Server's Cert. I am using Mule v 3.3.0.
For example: '-k' option in curl disables server's cert verification.
In similar way, is there any configuration parameter by which I can enable/disable Server's cert verification ?
Thanks
Jai
For Mule versions before 3.6, the HTTP transport supports configuration of the trust store used by the HTTP outbound endpoint to determine whether the certificate presented by an HTTPS server should be trusted.
To provide a key store that contains the certificates of servers you need to trust, provide the <https:tls-server /> to the <https:connector />, and reference that connector in your <https:outbound-endpoint />:
<https:connector name="myHttpsConnector">
<https:tls-server path="truststore.jks" storePassword="supersecure" />
</https:connector>
<flow name="someFlow">
<https:outbound-endpoint host="remote-host" port="443" path="/api" connector-ref="myHttpsConnector" />
</flow>
The blog post linked in clare's answer explains this a bit, from both the server side and the client side. You can also refer to the HTTPS Transport Reference, although it doesn't explain the use of tls-server vs. tls-client.
You can check out this blogpost. It will show you how you can configure mutual authentication in Mule. HTH.
You can configure the HTTP Request connector in Mule >= 3.6.0 to use a trust store you create that contains the certificate(s) of the server(s) you need to trust using TLS Configuration.
It might look something like this:
<tls:context name="tlsContextForServiceFoo">
<tls:trust-store path="serviceFooServerCertificates.jks" password="supersecure"/>
<tls:key-store path="myClientCertificates.jks" keyPassword="extrasecure" password="ultrasecure"/>
</tls:context>
<http:request-config name="twoWayAuthServiceFooConfig"
protocol="HTTPS"
host="services.pentagon.gov"
port="443"
tlsContext-ref="tlsContextForServiceFoo" />
<flow name="useServiceFoo">
<http:request config-ref="twoWayAuthServiceFooConfig" path="/api/doStuff" method="POST" />
</flow>
I have setup my my cloud using the following
http://azure.microsoft.com/en-us/documentation/articles/cloud-services-configure-ssl-certificate/
and the web role using the following http://msdn.microsoft.com/en-us/library/ms731074%28v=vs.110%29.aspx
My problem that when I use emulator I get an error That the there is a name mismatch between a certificate and the website in this case(127.0.0.1)
What can be done to solve it.
So there are two approaches you could take:
Create a separate cloud project for each environment - This way you could create a self-signed certificate for your development environment and live with the warning that the certificate is not trusted.
Get a wildcard certificate for your application - This is the approach we have taken for our application (along with the 1st one). Basically we took a wildcard SSL certificate and used that certificate in our application. Then we added an entry in hosts file located in C:\Windows\System32\drivers\etc like this:
127.0.0.1 dev.cloudportam.com
Next, we added hosts header in our dev cloud project's csdef file.
<Sites>
<Site name="Web">
<Bindings>
<Binding name="Endpoint1" endpointName="Endpoint1" hostHeader="dev.cloudportam.com" />
<Binding name="Endpoint2" endpointName="SSL" />
</Bindings>
</Site>
</Sites>
<Endpoints>
<InputEndpoint name="Endpoint1" protocol="http" port="8080" />
<InputEndpoint name="SSL" protocol="https" port="8082" certificate="SSL" />
</Endpoints>
Now when we launch the application, it opens up https://localhost:8082/ and we just change the address to https://dev.cloudportam.com:8082 and everything works well.
I have a problem similar to (but not the same) as this:
Azure web role - Multiple ssl certs pointing to a single endpoint
My azure package contains multiple sites. Some of these sites are on domain abc and others are on domain def. I need to secure both domains with SSL but can't figure out how (if it's possible) to do this.
Here's an example of my config:
<Sites>
<Site name="sub1.abc" physicalDirectory="***">
<Bindings>
<Binding name="HttpIn" endpointName="HttpIn" hostHeader="sub1-staging.abc.com" />
<Binding name="HttpsInABC" endpointName="HttpsInABC" hostHeader="sub1.abc.com" />
</Bindings>
</Site>
<Site name="sub1.def" physicalDirectory="***">
<Bindings>
<Binding name="HttpIn" endpointName="HttpIn" hostHeader="sub1-staging.def.com" />
<Binding name="HttpsInDEF" endpointName="HttpsInDEF" hostHeader="sub1.def.com" />
</Bindings>
</Site>
</Sites>
<Endpoints>
<InputEndpoint name="HttpIn" protocol="http" port="80" />
<InputEndpoint name="HttpsInABC" protocol="https" port="443" certificate="abc" />
<InputEndpoint name="HttpsInDEF" protocol="https" port="443" certificate="def" />
</Endpoints>
<Certificates>
<Certificate name="abc" storeLocation="LocalMachine" storeName="My" />
<Certificate name="def" storeLocation="LocalMachine" storeName="My" />
</Certificates>
This configuration gives me the following error:
The same local port '443' is assigned to endpoints HttpsInABC and
HttpsInDEF in role ***.
Any suggestions on how I can work around this without having to host them separately?
Based on #JoelDSouza's answer:
Will using different ports work for you
What are the implications of SSL on ports 444/445/446 etc. in Windows Azure?
You can use multiple SSL certificates and add them all to the same endpoint by automating the process of installing the certificates on the machine and add HTTPS bindings to IIS.
IIS 8 (Windows Server 2012) supports SNI, which enables you to add a "hostheader" to the HTTPS binding.
I'm a Microsoft Technical Evangelist and I have posted a detailed explanation and a sample "plug & play" source-code at:
http://www.vic.ms/microsoft/windows-azure/multiples-ssl-certificates-on-windows-azure-cloud-services/
I fear you are out of luck - as noted in the article you linked to, one SSL certificate per server IP. I guess by hosting them separately (that feels odd to say considering it's cloud based) you will get two IPs and therefore can add an SSL certificate to each IP address.
You could perhaps move everything to one domain and use folders within that domain to host the separate sites - that's the only way you will be able to secure everything with your SSL certificate without having two hosting packages:
ie instead of:
www.domain1.com and www.domain2.com use www.mydomain.com/domain1/ and www.mydomain.com/domain2/
Will using different ports work for you? You can use SSL cert 1 with myapp.cloudapp.net:443 and SSL cert 2 with myapp.cloudapp.net:8443
If you don't need wildcard certificates you can use a multi-domain certificate. This way you only need one certificate. The downside is that each sub-domain needs to be specified, which can get expensive if you have a lot.
I've been tearing my hear out trying to figure out why SSL works in one of my Azure projects but not in another.
When I navigate to my site, say https://foo.com, I can't even connect to the site. Browsers can't connect at all and curl says "couldn't connect to host". However, if I go to my cloudapp.net URL (e.g. https://foo.cloudapp.net), it can connect but browsers will complain and say my cert is for *.foo.com. Note: I am able to connect to http://foo.com without any trouble.
Here's my code with certain values obfuscated.
ServiceDefinition.csdef:
<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="MyApp" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
<WebRole name="www" vmsize="Small">
<Sites>
<Site name="Web">
<VirtualApplication name="r" physicalDirectory="../Foo/Bar" />
<Bindings>
<Binding name="Endpoint1" endpointName="Endpoint1" />
<Binding name="Endpoint2" endpointName="Endpoint2" />
</Bindings>
</Site>
</Sites>
<Endpoints>
<InputEndpoint name="Endpoint1" protocol="http" port="80" />
<InputEndpoint name="Endpoint2" protocol="https" port="443" certificate="STAR.foo.com" />
</Endpoints>
<Imports>
<Import moduleName="Diagnostics" />
</Imports>
<Certificates>
<Certificate name="STAR.foo.com" storeLocation="LocalMachine" storeName="My" />
</Certificates>
</WebRole>
</ServiceDefinition>
my cert is uploaded, the thumbprint matches (in this example it's also "1234567890")
ServiceConfiguration.csfg:
<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="myApp" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="1" osVersion="*">
<Role name="www">
<Instances count="2" />
<ConfigurationSettings>
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
</ConfigurationSettings>
<Certificates>
<Certificate name="STAR.foo.com" thumbprint="1234567890" thumbprintAlgorithm="sha1" />
</Certificates>
</Role>
</ServiceConfiguration>
Azure Console:
I have verified that:
My cert is uploaded
It's SHA1
It's thumbprint matches what I've specified in ServiceConfiguration.cscfg (in this example it's "1234567890")
The certs for the Certificate Authorities are also present (for me it's "PositiveSSL CA" and "AddTrust External CA root")
For the Azure instance, it confirms there are 2 endpoints (port 80 and port 443)
Why would I not be able to connect at all via https://foo.com, but my https://foo.cloudapp.net will load (although triggering a browser warning)? This seem to indicate my configuration is correct but something else is off... ideas?
I think you may be looking in the wrong place for your problem!
How have you mapped foo.com to your site's address?
Note that Azure instances are given dynamic IP addresses - what address your site may be on NOW may not be what its on tomorrow. The recommendation for Azure is to add a "www" CNAME DNS entry in your domain records that points at "foo.cloudapp.net".
This way, when someone browses to www.foo.com, the DNS server will (invisibly) say "hey, actually, that site is as foo.cloudapp.net. The browser will then ask for the IP address of foo.cloudapp.net. This domain is managed by Microsoft who will return the current IP address for your site.
If you want foo.com to still get you to www.foo.com, you'll have to setup DNS redirection so that whenever someone types foo.com into their browser, they're redirected to www.foo.com. This will then cuase the browser to resolve foo.cloudapp.net and then the HTTP request will be sent to your site. Some domain hosters charge for this (typically a nominal fee), some offer it as a free service.
HTH.