I have a wcf application (standalone service self hosted). This is NOT hosted in IIS and hosting it in IIS is not an option.
The service exposes a WCF service. I know that the service contract works because it works with HTTP as transport.
Now, I need to move to https. The intent is to secure the transport only. Client authentication is not required as we assume that anybody connecting to service is within the network.
After making changes to app.config to access httpsTransport in and updating the URLs across board, i started working on associating cert with port. The explanation is in http://msdn.microsoft.com/en-us/library/ms733791.aspx I followed instructions under section "To bind an SSL certificate to a port number". This worked nicely within the local machine. Note that root certificate and development certificate is generated using makecert.exe
When i host the same service in Windows server 2003, all hell breaks loose. The clients do not even get to see the endpoint (note that it's not firewalled as http works). I have followed the steps outlined in the document mentioned above (using httpcfg.exe). This does not work. OpenSSL mentions that server did not provide a certificate.
What can be the problem?
Did your server start correctly on 2003?
Did you configure your client to look for the server's certificate like following snippet? Pleaes check you didn't mistype the name of the certficate.
<endpoint binding="netTcpBinding" bindingConfiguration="DirectConnection"
behaviorConfiguration="Behavior"
contract="AContract"
name="ServiceContract" >
<identity>
<dns value="ServerCertificate.Com" />
</identity>
Turned out that using self signed certificates could not be used on windows 2003 server (this particular instance). I am guessing it's being treated as untrusted cert. Once we got the official certs, things just worked with no changes.
Related
We're developing a C#/.NET WCF web service that needs be installed on an (enterprise) customer's machine, which may or may not have Apache/IIS running as well.
Communication with our service has to be secured with SSL, but what if the existing Apache/IIS is already using an SSL cert for this address? Can we share it since the host is the same?
For example:
Host: sasquatch.ourcustomer.com
Their existing stuff: Apache or IIS is running on port 80
Our newly installed stuff: Our service is running on port 9999
If Apache/IIS has its own cert, should/can we use it too?
If not, what should we do?
A certificate identifies a host and not a service. It is independent from the port you use or the application providing the service. If you have multiple services on the same host it is still the same host, so you can use the same certificate.
I'm implementing mutual SSL between service A and service B. Service A uses both 1-way and 2-way SSL. 1-way for the communication between a user and website A, and 2-way SSL to forward requests from that user to the service B in a secure way.
1-way SSL in service A is specified in Tomcat server.xml. 2-way SSL is implemented using JSEE secure socket communication on the client side (service A), and Tomcat config (service B). Atm. when I try to access service A I get ssl_error_rx_record_too_long error.
According to this answer ssl_error_rx_record_too_long and Apache SSL one of the reasons may be the fact that I'm using more than one SSL certificate for the same IP. Is this really the case that you can't use the same IP for several certificates? Even if one certificate is a server certificate (for 1-way SSL) and another is a client certificate (for 2-way SSL)?
This may not be the cause of my problem, but I just want to make sure if it's actually possible to have several certificates for the same FQDN. Thanks for help!
ssl_error_rx_record_too_long generally has nothing to do with certificate configuration, but the fact that what's talking on that port isn't actually using SSL/TLS.
The answers (and even the update to the question) in the question you linked to also point to this problem (e.g. missing SSLEngine on). You probably forgot something like SSLEnabled="true" in your connector configuration.
As I was saying in an answer to your other question, being able to configure two server certificates on the same IP address isn't really a problem for your case.
it's actually possible to have several certificates for the same FQDN
It is possible to configure multiple certificates on the same IP address and port using the Server Name Indication TLS extension, but both servers and clients would need to support it. In particular, this is not supported by the JSSE in Java 7 on the server side (only on the client side), but there are workarounds if you're willing to put a reverse proxy in front of your Java server.
This wouldn't be possible to do this with the same FQDN, since it's what allows to pick the certificate. This being said, having multiple server certificates for the same FQDN on the same IP address is generally pointless. Supporting multiple certificates is precisely useful when you need to support distinct names.
We have a WCF Self hosted application that uses SSL but we have it on port 15014. I when through and did everything that MSDN lists for attaching the SSL cert to the port and the code. It works when i browse to 'https://secure.mydomain.com:15014'. The issue is when i look at that connection through wireshark i only see tcp as the protocol and not SSLv?. I don't see any client handshake at all. This leads me to believe that it is not really secure. Am i correct on this?
I have a WCF service running under IIS configured to use SSL, with a valid certificate already installed and running.
Visiting the website with
https://my_website/anypage.aspx
I can access the page.
Visiting the url
https://my_website/mywcfservice.svc
I can see the webservice page:
"You have created a service. To test this service, you will need to create a client and use it to call the service(...) ". Note that I'm receiving anyway the warning page saying "There is a problem with this website's security certificate" where I click "Continue to this website".
in server side, the web.config is configured with:
<security mode="Transport">
<transport clientCredentialType="None" />
</security>
...
...
In client side, I'm not using proxy or config file. I'm connecting using code only, like:
this.Channel = new ChannelFactory<T>(binding, new EndpointAddress(serviceUri));
((WSHttpBinding)this.Channel.Endpoint.Binding).Security.Mode = SecurityMode.Transport;
((WSHttpBinding)this.Channel.Endpoint.Binding).Security.Transport.ClientCredentialType = HttpClientCredentialType.None;
this.Channel.CreateChannel();
I have strong rules to connect from client by code so I can't use other way. the channel is well opened but when I'm calling any method I receive error "the remote certificate is invalid according to the validation procedure."
Without https was working ok.
In client side I have a many certificates in "Trusted Root Certification Authorities\Certificates". All of them are also trusted in server side.
Where could be the issue, in client or server side ??
Maybe I need to specify one very precise certificate to use in client side ??
any help appreciate, thanks.
Note that I'm receiving anyway the warning page saying "There is a problem with this website's security certificate" where I click "Continue to this website".
Your client machine does not trust the SSL certificate that you are using on the server. The WCF error you receive is the equivalent to the message that you are getting when you try to hit the service in your browser.
In client side I have a many certificates in "Trusted Root Certification Authorities\Certificates". All of them are also trusted in server side.
You need to configure your client machine to properly trust your SSL certificate. Once you can access the service in your browser with no errors, your client code should work.
I have a self-hosted WCF service with TCP binding, now trying to layer on SSL.
The cert I got from the CA has two values for "Subject Alternative Name":
www.mysite.com
mysite.com
I only want to present "mysite.com" to WCF clients, somehow this www.mysite.com (which the CA added, I did not ask for www.mysite.com).
I am using the below code server-side. What do I have to tweak to "hide" the www.mysite.com address?
svc.Credentials.ServiceCertificate.SetCertificate(
StoreLocation.CurrentUser , StoreName.My , X509FindType.FindBySubjectName , "mysite.com" );
So right now when the client connects, I get
"Identity check failed for outgoing message. The expected DNS identity of the remote endpoint was 'mysite.com' but the remote endpoint provided DNS claim 'www.mysite.com'. If this is a legitimate remote endpoint, you can fix the problem by explicitly specifying DNS identity 'www.mysite.com' as the Identity property of EndpointAddress when creating channel proxy. "
I don't want the client to know anything about www.mysite.com. I only want them to use what the serve presents, and I want the sever to only present mysite.com.
Why do you want to hide it? A certificate with SAN alternatives means it is value for all of those FQDNs, so it will work on both www.mysite.com and mysite.com.
Additionally from the looks of your call to SetCertificate the subject name of the certificate is what you want, mysite.com and that's what's checked first.
The full text of the error message comes in the form of
Identity check failed for outgoing message. The expected DNS identity
of the remote endpoint was 'X' but the remote endpoint provided DNS
claim 'Y'
Now this has nothing to do with the certificate, but the host that IIS is configured for, or, in the case of self hosting, the host/machine Windows is configured to be. You can override the host that WCF will use by adding a new configuration setting for the endpoint;
<identity>
<dns value="mysite.com"/>
</identity>
or setting it in code when you create the endpoint.