I'm trying to set up a WCF-service with SSL on Azure.
Can someone please explain a bit about the differences of using certificates is these cases?
Certificate for https-binding in IIS
ServiceCertificate in Web.Config
ClientCertificate in Web.Config
Certificate in ServiceDefinition.csdef
Certificate in ServiceConfiguration.Local.cscfg
Certificate in ServiceConfiguration.Cloud.cscfg
More I should know about?
I want to publish several service-endpoints within the same role, some with SSL and some without. Do I need binding-certificates at all or is it service-certificates I should use?
Start by reading WCF Transport Security with Certificate Authentication and Configuring SSL for an application in Windows Azure
Certificate for https-binding in IIS - exactly what it says, the cert is used by IIS to create a secure binding on a site/service, typically on port 443
ServiceCertificate in Web.Config - WCF service-side binding cert used for WCF Transport Security with Certificate Authentication - private key cert used to authenticate client request signed with the corresponding public key
ClientCertificate in Web.Config - WCF client-side binding cert used for WCF Transport Security with Certificate Authentication - public key cert used to sign a request for authentication to a service using Transport Security with the corresponding private key
Certificate in ServiceDefinition.csdef - default certificate used to create a secure endpoint in Azure worker & web roles. NOTE: This is the certificate Azure installs in IIS to bind to the service endpoint (see #1)
Certificate in ServiceConfiguration.Local.cscfg - same as 4, just used in a "Local" build/deployment configuration
Certificate in ServiceConfiguration.Cloud.cscfg - same as 4, just used in a "Cloud" build/deployment configuration
Related
I've read quite a few articles on the client certificate authentication in IIS but they mostly talk about the Required mode for the client certificate. In this case, the authentication is fully done on the web server side and the user is redirected to the error page in case the certificate is missing or invalid. What I need is to configure IIS to check the client certificate if it exists and pass the results as http headers to my backend. It can be easily done with nginx or apache web servers. The client authentication can be set up as optional. Then, the web server checks the certificate and pass the results of the check as SSL_CLIENT_CERT (PEM representation of the certificate) and SSL_CLIENT_VERIFY (the result of the check - SUCCESS, NONE,...) headers to the application backend. So, on the backend part, I can read the headers and use the values to do the actual authentication -- find a user in the database, issue an auth token. Is it possible in IIS? If yes, is there any documentation on how to bypass the certificate and the check state as http headers?
After a while, I'm writing an answer to my question.
IIS has to be set up with ARR extension to act as a reverse proxy. Then, the client certificate authentication can be enabled for the default web site. Here are several links to instructions how to achieve it:
https://blogs.msdn.microsoft.com/benjaminperkins/2014/06/02/configure-application-request-routing-arr-with-client-certificates/
https://blogs.msdn.microsoft.com/asiatech/2014/01/27/configuring-arr-with-client-certificate/
and couple of links to very solid explanations of the SSL/TLS handshake and certificates in general:
https://blogs.msdn.microsoft.com/kaushal/2013/08/02/ssl-handshake-and-https-bindings-on-iis/
https://blogs.msdn.microsoft.com/kaushal/2013/01/09/self-signed-root-ca-and-intermediate-ca-certificates/
https://blogs.msdn.microsoft.com/kaushal/2015/05/27/client-certificate-authentication-part-1/
Basically, the Application Request Routing (ARR) extension should be enabled for the IIS to act as a proxy. Then, you set up proxy bypass routes. Next, you need to set up a valid server certificate for the IIS server and use it in the Default Web Site https bindings. The certificate should be issued by a CA which certificate should be placed into the Trusted Root Certification Authorities and Intermediate Certification Authorities of the Local Computer. Then, you should require SSL in the SSL settings of the Default Web Site with the client certificates setting equal to Accept. In this case, any client that connects to the web server will be asked for a valid client certificate that has been issued by the same CA as the server certificate.
Actually, IIS sends a list of distinguished names of root issuers that are trusted by the web server to the client browser. The browser finds an intersection of this names with client trusted certificate issuers and looks for valid certificates that have been issued by the issuers in the intersection. After that, the user selects one of them (or none) and the selected certificate is checked against the CA certificate. If the certificate passes the check the request is "redirected" to the backend application with the certificate in the X-ARR-ClientCert header. The name of the header can be changed in the Server -> Configuration Editor -> system.webServer/proxy -> clientCertHeaderName IIS parameter. In case the user selects (or has) none of the required certificates, the request is "redirected" to the app backend without the header.
Seems, there is no need in the SSL_CLIENT_VERIFY header with the state of the check at all. If the certificate is valid it is passed in the header. If the certificate is missing the header is empty. If the certificate is provided by the client but is invalid then the request fails and is not "redirected" to the backend app server at all. Seems, it is a rare case but I have an example.
Imagine, a server certificate is issued by a CA with a distinguished name XXX, and there is a client certificate YYY (on the client computer) that is issued by a CA with the distinguished name XXX but those CAs are not the same (one or both of them are self-signed). In this case, the YYY certificate is present in the certificate selection dialog that is shown by a browser but the certificate doesn't pass the further validation against the real web server CA.
That's it. Also, seems IIS has no way to require (or accept) a client certificate for some app endpoints (addresses) only. I haven't found any other option apart from enabling in for the whole web site.
IIS ARR can also be configured with a client certificate for the backend or upstream server. In this case users connecting to this IIS do not need to provide the certificate as it will be attached by IIS automatically.
This configuration is available on IIS server level only.
We have a websphere application that must connect to a webservice over https. Websphere Application server has version 8.5.5
We have the wsdl of the service, so we were able to create the client using the JAX-WS wizard in eclipse 4.5.
The SSL connection requires both accepting the server certificate and authentication with client certificate (private key).
The restriction we have is that the SSL configuration must be at application level, and not at server level. In a first time we were able to configure the server with the repective certificates in the default truststore and keystore, but that configuration was not accepted.
So we created a SSL configuration with a keystore that includes both the signer certificates of the server of the webservice and the personal certificate (with the private key) of the client. Type is JKS.
We suppose that we have to create in some way a "Web services Client security bindings" in Applications > Application Types > WebSphere enterprise applications > application_name > Manage Module > module_name > Web services: Client security bindings, but that list is empty:
Currently when we try to test the service client we get the exception:
exception: javax.xml.ws.soap.SOAPFaultException:
javax.net.ssl.SSLHandshakeException: General SSLEngine problem
You need to import the SSL certificate into the Web SPhere truststore, you can do it from here:
Security > SSL certificate and key management > Key stores and certificates > CellDefaultTrustStore > Signer certificates > Retrieve from port
or
You can directly upload the certificate from:
SSL certificate and key management > Key stores and certificates > CellDefaultTrustStore > Signer certificates > Add signer certificate
Hope this solves your issue.
here i am asking few basic question about wcf ssl & certificate
i am new in wcf and also to be very honest that i have basic problem to understand the SSL & certificate.
1) i like to know that when we enable SSL then every time we need to use certificate or the same way when we attach certificate with wcf then SSL will be used implicitly.
2) SSL & Certificate both are same or different in concept ?
3) when we self host wcf service then can we enable SSL or certificate...which one will be applicable ?
4) tcp binding for certificate is not related with http. so when we work with tcp binding then can we enable SSL for tcp binding.
5) what is difference between SSL & Certificate ?
6) when we use certificate at service end then client end which consume & call the service they always need to install certificate. if not then when client need to install certificate & when not required. one guy told me that client need to install certificate only when mutual authentication is required but i do not know about what mutual authentication ?
i know i asked very basic question. if possible please explain all my points in details to clear my doubts. thanks
UPDATE
1) i like to know that when we enable SSL then every time we need to use certificate or
the same way when we attach certificate with wcf then SSL will be used implicitly.
you said as follows :-
When enabling Transport security the endpoint address must include the HTTPS protocol,
otherwise an exception will be thrown when you go to start the service. For HTTPS to work on that endpoint,
then you need an X.509 Certificate bound to the specified port as well.
why you said this :- When enabling Transport security the endpoint address must include the HTTPS protocol
https come to play when we host our wcf service in IIS. suppose when we host wcf service in self host
and tcp used as binding then why we need to include https in endpoint because you said enabling Transport
security and endpoint address must include the HTTPS protocol....is it correct ? may be i could not understand
what you are trying to say. can you please explain in detail what you are trying to say for the point 1
6) when we use certificate at service end then client end which consume & call the service they always
need to install certificate. if not then when client need to install certificate & when not required.
one guy told me that client need to install certificate only when mutual authentication is required
but i do not know about what mutual authentication ?
here i just trying to know that when wcf service will hosted and attached with certificate then is it mandatory
that client who consume the service he/she need to use certificate at client end ?
i guess it is not mandatory. only two end use certificate when mutual authentication would be consider.
am i right ?
in case of mutual authentication server & client end need to install or use same certificate or client can use different certificate purchase from abc.com and server end purchase certificate from xyz.com.
please clearly discuss my above two points in details. thanks for your time & answer.
Okay here we go:
1) i like to know that when we enable SSL then every time we need to
use certificate or the same way when we attach certificate with wcf
then SSL will be used implicitly.
When enabling Transport security the endpoint address must include the HTTPS protocol, otherwise an exception will be thrown when you go to start the service. For HTTPS to work on that endpoint, then you need an X.509 Certificate bound to the specified port as well.
2) SSL & Certificate both are same or different in concept ?
SSL certificates are a type of X.509 Certificate*. In TLS (which SSL is a predecessor of), virtually all certificates are X.509 certificates.
3) when we self host wcf service then can we enable SSL or
certificate...which one will be applicable ?
When using Transport level security, the Self-Hosted Service will make use of the X.509 certificate bound to the port of the endpoint that it is listening at. Setting the service certificate will have no impact in this case.
4) tcp binding for certificate is not related with http. so when we
work with tcp binding then can we enable SSL for tcp binding.
Yes, Transport level security provided for TCP is Windows security by default which is SSL over TCP. When using SSL over TCP, you must explicitly specify the certificate by using the SetCertificate method on the Self-Hosted Service.
5) what is difference between SSL & Certificate ?
As stated above, essentially SSL is a subset of X.509 Certificates - technically speaking the relationship isn't as simple as that, but typically you use X.509 Certificates for SSL\TLS.
6) when we use certificate at service end then client end which
consume & call the service they always need to install certificate. if
not then when client need to install certificate & when not required.
one guy told me that client need to install certificate only when
mutual authentication is required but i do not know about what mutual
authentication ?
Mutual SSL authentication is when the client and server each provide a digital certificate so each party can verify the identity of the other. Here's a great article on Mutual SSL Authentication if you're interested.
This isn't necessary though and only one of the many options you have when using Transport security - see more options here: HttpClientCredentialType.
You can also still do security at the Transport level while passing credentials at the Message level by using TransportWithMessageCredential - then you can use set Client Credentials to use a BasicHttpMessageCredentialType and use UserName instead.
*: Other types of certificates can be used for SSL\TLS such as OpenPGP - but it is far from common.
I have been given a wsdl and xsd file from a company partner to access their https service.
I have installed the client certificate and can access their API using SoapUI after configuring the security in soapUI.
what are the next steps to consume the API in a .net application?
I have generated the proxy using svcutil.
I have added the certificate to the local machine and current user - trusted root certification authorities
The cert is from the service provider and works through soapUI. its not self signed.
When i make the call to the service i get Could not establish secure channel for SSL/TLS with authority 'WEB_SERVICE_URL:11851'.
Do i need to configure https in the config file or what am i missing?
thank you
It turned out i had to specify the certificate in code
// Create the binding.
BasicHttpBinding customerBinding = new BasicHttpBinding();
customerBinding.Security.Mode = BasicHttpSecurityMode.Transport;
customerBinding.Security.Transport.ClientCredentialType =
HttpClientCredentialType.Certificate;
// Create the endpoint address. Note that the machine name
// must match the subject or DNS field of the X.509 certificate
// used to authenticate the service.
EndpointAddress customerEa = new
EndpointAddress("https:URL_OF_SERVICE:11851/WebServices/GetCustomerDetailsService");
// Create the client.
customerClient = new GetCustomerDetails1Client(customerBinding, customerEa);
// The client must specify a certificate trusted by the server.
customerClient.ClientCredentials.ClientCertificate.SetCertificate(
StoreLocation.CurrentUser,
StoreName.My,
X509FindType.FindBySubjectName,
"CERTIFICATE_NAME");
I am writing a WCF service where I need to access the Hash Code of client certificates that are used to connect to the service.
I am looking for a property or method similar to Request.ClientCertificate from ASP.NET 2.0 days but cannot find anything that allows easy access to the client certificate.
Our service is set up such that it is running with SSL using basicHttpBinding and security mode of "Transport".
IIS has been set up to Require SSL and Accept certificates.
One thing to note is that our server certificate used to secure the endpoint is from a different CA to that of the client certificates - the client certificates are intended to be validated solely through custom code (thus the need to get the hash code of a connecting certificate).
I have created a custom implementation of the IDispatchMessageInspector to see if there is any access to a client certificate from there but to no avail.
Has anyone attempted this and had success before?
Looks like what the best option for you would be to implement a custom Certificate Validator for your service. This is basically a class that derives from X509CertificateValidator and is then registered through the config file.
There's more complete information on how to do this on this article.
For reference if anyone else attempts to apply client certificate authentication the following steps were required to get it to work (we are using basicHttpBinding within WCF for this instance and running in a local instance of IIS):
Set up IIS to use a HTTPS binding for the site and secure this in IIS with a server certificate
Within IIS change the SSL Settings for your site to Require SSL and Require client certificates (It must be Require - Accept will not work)
Within the WCF configuration ammend the basicHttpBinding and set security mode to "Transport" and the transport clientCredentialType to "Certificate"
Ensure that the root certificate (the one used to create any client certificates) is within the "Trusted Root Cerrtification Authorities" for the Local Computer on which IIS is running.
NOTE If you are in a development environment you may need to generate your own root certificate, the makecert command line application is very useful for this; simply run the following command:
makecert -n "CN=My Test Auth" -r -cy authority -a sha1 -sv "My Private Key.pvk" TestAuth.cer
This creates a certificate called TestAuth.cer (which needs to be added to the Computer's "Trusted Root Cerrtification Authorities") and a private key file called "My Private Key.pvk".
Now to generate a client certificate you can run this command:
makecert -a sha1 -n "CN=myConnectionCert" -ic "TestAuth.cer" -iv "My Private Key.pvk" -ss My
This created a certificate with a subject of myConnectionCert and adds it to your personal certificate store - when you now access the site (to view the service page for example) IE should prompt you to select the certificate - chose the one you have just created and you should see the service page as normal.