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).
Related
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.
I've always been an end consumer of HTTPS and have never really understood it that well but am looking to change that.
I am calling a RESTful web service over HTTPS. For example...
curl -X GET \
https://myCompanydns/rest/connect/v1.4/myEndpoint
With all my requests I send a basic authentication header i.e a username and password.
When I make these calls via my application I was expecting to have to add a certificate into like a jks (which I've had to do in the past) but on this occasion I've found that I can call the HTTPS web service without that.
For HTTPS to work I believe there is an SSL handshake? How is that happening successfully is this scenario without a jks?
Again, sorry for this beginner type question.
When doing a https://... request the client needs to verify that the servers certificate is the expected one - and not some man in the middle. This is done (among other things) by making sure that the servers certificate was issued by a trusted certificate authority (CA). Which CA is trusted is setup in the local trust store (i.e. local to the client). In the above call where no explicit trust store is given curl is using its default trust store. In the case where you've explicitly gave a jks you've provided the application with a specific trust store it should use.
For more on how the server certificates gets validated see SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?.
I am putting a web test up for clients that visit "https://oursite.com/poodlesecurityfailed.js"
Question,
Do I need a valid certificate even though its on a test domain for certificate negotiation? If client can visit it, they failed the poodle test. (SSLv3 is enabled) on that host.
Ideas?
Do I need a valid certificate even though its on a test domain for certificate negotiation? If client can visit it, they failed the poodle test. (SSLv3 is enabled) on that host.
Depends on the client.
If the clients is has enough knowledge to understand, that "invalid certificate" when accessing the site means in reality that the client has still SSL 3.0 enabled, then a self-signed certificate would be enough.
If you instead want to provide an explanation of the problem at this site and don't expect the client to explicitly accept an invalid certificate just to see this explanation, then you should better use a properly trusted certificate.
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.
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.