Few Query about wcf with SSL & Certificate - wcf

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.

Related

HAPROXY ingress controller setup using mTLS with configmap with just the ingress load balancer because it's ssl offloaded. No need for backend check

I was able to achieve ssl offloading with Haproxy. So great product and appreciate that capability!
With that said, I need to doing mutual TLS but am a little confused on how that will work with the ingress controller configmap.
Going through this reference i've created a client cert, intermediate cert and root cert.
To note, I am terminating the ssl cert (which is from letsencrpt) on the load balancer currently.
However, the client cert and org CA are different than the lesencrypt tls/ssl cert that I have assigned as the SSL now; does that matter?
So, the first question I would have is does the ssl-certificate have to be set to the CA that will sign the client and server certs or can I just use the new ones I created in the instruction.
Setting up the configmap.
This is the part i'm confused on.
You can setup server-ca and server-crt but I don't think that applys here because after the ssl offloading there is nothing meant to be checked. However, I do want mTLS via the ssl termination.
So there is an configuration client-ca
Sets the client certificate authority enabling HAProxy to check clients certificate (TLS authentication), thus enabling client mTLS.
NB, ssl-offloading should be enabled for TLS authentication to work.
The client in this case being the actual client I want which is the device/frontend. Not the loadbalancer acting as a client to the backend server.
When I look at how this is setup:
frontend mysite
bind 192.168.56.20:80
bind 192.168.56.20:443 ssl crt /etc/haproxy/certs/ssl.crt verify required ca-file /etc/haproxy/certs/intermediate-ca.crt ca-verify-file /etc/haproxy/certs/root-ca.crt
http-request redirect scheme https unless { ssl_fc }
default_backend apiservers
Is it possible to do the same with the controller configmap as what is listed here below? There's a lot more going on that what I am seeing as flags / configurations that are in this methodology of applying client mTLS. Is there a way to achieve this in kubernetes without configmap?
The ssl parameter enables SSL termination for this listener. The crt parameter identifies the location of the PEM-formatted SSL certificate. This certificate should contain both the public certificate and private key.
You can restrict who can access your application by giving trusted clients a certificate that they must present when connecting. HAProxy will check for this if you add a verify required parameter to the bind line, as shown:
the ssl argument enables HTTPS
the crt argument specifies the server SSL certificate, which you will typically obtain from a certificate provider like Let’s Encrypt
the verify required argument requires clients to send a client certificate
the ca-file argument specifies the intermediate certificate with which we will verify that the client’s certificate has been signed with our organization’s CA
the ca-verify-file argument (introduced in HAProxy 2.2) includes the root CA certificate, allowing HAProxy to send a shorter list of CAs to the client in the SERVER HELLO message that will be used for verification, but keeping upper level CAs, such as the root, out of that list. HAProxy requires the root CA to be set with this argument or else included in the intermediate-ca.crt file (compatibility with older versions of HAProxy).
Also, my reasoning for now wanting to use letsencrypt and rather a private CA is because I can't renew device certificates every 60 - 90 days. That would not be efficient. In this case, and please let me know otherwise, I think it better to use either a real key/cert provider or in development testing utilize the openssl certs like in the HAProxy instruction.
It's odd but you really have to think about what a "client" is with these abstractions because I would never use this for a normal web page login but rather the server to server communication and in that sense this server is a client to this server. Or in my case this device is a client to this loadbalancer.

TLS and clientAuthRequired of operation security for fabric

I have two questions about operation security of fabric.
1.In the official documentation( https://hyperledger-fabric.readthedocs.io/en/latest/operations_service.html?highlight=security#operations-security ), it says:"When TLS is enabled, a valid client certificate must be provided in order to access all resources unless explicitly noted otherwise below." Does this mean that when I access the operation RESTFUL API(e.g.GET /logspec) by curl or POSTMAN, I need to provide client certificate, right? If so, the client certificate must be generated by the corresponding organization's Fabric CA, right?
2.The documentation also says:"When clientAuthRequired is also enabled, the TLS layer will require a valid client certificate regardless of the resource being accessed.". I can't figure out what is the difference between "TLS" and "clientAuthRequired" configuration. Could any expert tell me this?
Thanks very much!
Yes ... it means that when TLS is enabled you will require a client certificate (expect where noted refers to the fact that the /healthz endpoint does not require a client certificate). The client certificate must be issued by a CA configured using the operations.tls.clientRootCAs.files property for the peer and/or the Operations.TLS.RootCAs property for the orderer.
If clientAuthRequired is enabled, then all endpoints will require a client certificate (again for now this means that /healthz would require a client cert).

ssl_error_rx_record_too_long - client and server SSL certs for the same IP

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.

tomcat client authentication using clientAuth=want

My application requires client authentication for a specific URL, after client authentication succeeds the application itself also does some verification on the client certificate subject (using spring security x509 filter). I wanted to configure tomcat to force client authentication (clientAuth=true) for the specific URL, but based on this post it seems I can't do this only using tomcat - configure tomcat for client authentication only for specific URL patterns.
My question is, if I use clientAuth=want, will the following be as below when the server requests a certificate:
If device has an identity certificate but not trusted by the CA configured in tomcat truststoreFile, no certificate will be passed and the request will fail in the spring security filter (certificate will be null)
If device has an identity certificate trusted by the CA configured in tomcat truststoreFile, but is invalid (not sure what validations are done) or expired, either the authentication will fail in tomcat (before the security filter) or as in option 1 no certificate will be passed and the request will fail in the spring security filter (certificate will be null)
Is there a security hole I may be missing using this configuration of want + security filter? I guess the question is - if a certificate is eventually passed from the device to the server, the server will always validate it (not expired, trusted etc) even when using clientAuth=want and will not allow the client to continue if the certificate is invalid? The case where no certificate is passed is covered by the security filter that will check the certificate is not null..
Thanks!
Your assumptions in both 1. and 2. are correct. Tomcat will not allow untrusted or invalid certificates through to your application. If you get a null certificate, you can assume that either no certificate was passed, or an untrusted/invalid certificate was passed.
On the project I am working on we have the same requirement as you: client certificates for certain URLs only. We found out by experimentation how "clientAuth=want" works.

403.7 IIS 7.5 SSL client certificate authentication issue

I am testing a web service with an external partner using 2 way SSL under IIS 7.5. I am requiring SSL, requiring a client cert, and using one to one mapping to authenticate to a domain account. I have configured everything and it works fine on our network (I am able to provide a client cert, get authenticated and invoke the service from browser and test harness).
From outside of our network (in most cases, see below), I am getting a 403.7 error. I have gone through the machine level certificate store and made sure the certificates and CAs are trusted.
Here's the weird thing. I obtained a Type I cert to test from home (and got 403.7 like our intended partner is). So I setup Fiddler to debug SSL and send my certificate, and this works for some reason. I setup a test harness to pass the exact same certificate, and got 403.7. I test in my browser (IE 9), don't get a prompt for a client cert, and get 403.7.
Any help appreciated.
Bill
Last time I checked, IIS was using re-negotiation (by default) to get the client certificate: there is a first handshake where the server doesn't request a client certificate, followed by another handshake (encrypted this time) where the server requests the certificate (via a TLS CertificateRequest message). This will prevent you from seeing anything from Wireshark, unless you configure it to use the server's private key and decipher the traffic (note that this only works with some cipher suites).
One way to see the client-certificate negotiation is to configure IIS to use initial client certificate negotiation, using netsh and clientcertnegotiation=true (which is about initial negotiation). At least the CertificateRequest and the certificate will be sent in clear during the handshake, so you should be able to see this with Wireshark.
If the client isn't sending a certificate to the server as a response to the CertificateRequest, you'll still see an empty Certificate message from the client.
If you don't export the private key with the certificate to use with Fiddler or whichever other client, there is no chance that it will be able to use the certificate. It may at best try to send the certificate, but the handshake will fail (since the CertificateVerify message needs to be signed by the client's private key).
I guess you may encounter a problem whereby:
not presenting a certificate is accepted by the server (it's effectively optional),
presenting an invalid certificate makes it fail and causes this 403.7 status code (many servers and SSL/TLS stacks would implement this as a fatal error, but TLS specification doesn't say that unsupported_certificate, certificate_revoked, certificate_expired, certificate_unknown should be fatal, so this is at the server's discretion).
Are you using the same physical machine to test both the in-network and external-network connections? If not, are you sure that the external-network client has the private key accessible?
I have not configured Fiddler client authentication before. Does it read the client certificate and key from the standard certificate stores? Does it read directly from a PKCS12?
One other thing that may be helpful is inspecting the TLS handshake in WireShark. Specifically, check out the Server's "Certificate Request" message, as the data here clues the client (IE9) which client certificates it should display in the prompt. Compare this for the internal and external connections.