I need to communicate via BizTalk WCF Adapter (probably Custom or WSHttp) with a webservice secured with WS-Security: X.509 Certificate Token Profile 1.1
The requirement are below (taken from SoapUI):
Key Identifier: Issuer Name and Serial Number
Signature Algorithm: xmldsig#rsa-sha1
Signature Canonicalization: xml-exc-c14n#
Digest Algorithm: xmlenc#sha256
Use Single Certificate: true
Does anyone have any idea how to translate this requirements to BizTalk WCF Custom adapter?
Related
Good evening, the ANAC (National Anti-Corruption Authority), in order to configure cooperation services in mutual authentication, asks to send a client certificate (even self-signed) in X.509 format, with the extension "TLS Web Client Authentication" enabled.
It also asks to provide the public certification chain used to sign the client certificate.
Question: How do I generate the certificate? OpenSSL? And with which public certification chain do I sign it? Thanks in advance for any suggestions.
I'm debugging SSL errors between Websphere MQ Server and Client using T.Rob's suggestions and need help understanding the SSL handshake (SSL connect to MQ using .net mq client SSLV3?).
My WMQ 7.5 client application is C code and uses a keystore (.kdb). Utilizing a CHLTAB provided by the WebSphere admin. The WMQ server is running Java and the channel is defined with mutual authentication.
The article states that in the SSL/TLS handshake, the server always sends its public certificate in response to a connections request. The client then must validate that certificate by first checking the signature and validity date, then looking in its trust store for the thing that signed the certificate.
Here's my confusion: Since my keystore on the client side has only the application personal cert, how does the client validate the public certificate sent by the server? I have provided the Common Name of my application cert to the WebSphere server admin but nothing more than that.
Thanks in advance for the clarification!
The bit about "my keystore on the client side has only the application personal cert" is troubling. That won't work. The client KDB must have the server's public key. If the MQ server has SSLCAUTH(OPTIONAL) the the server's public cert is all that's required in the KDB for the connection to succeed.
The first part of the TLS handshake is where the client validates the server's certificate. The use of public/private key pairs is how the authenticity of the thing on the other side is assured. In order for that to happen the server must have its own personal certificate and the client must have the public key of the root of the signer chain. In the case of self-signed certificates the public portion of the personal cert must be trusted by the client. In the case of CA-signed certs the CA Root must be trusted by the client. Whichever one it is, the client must trust something used to sign the server's personal cert or that cert can't be validated.
The TLS handshake is symmetrical so the second part works exactly the same as the first but the roles are reversed. Therefore, in cases where mutual authentication is enabled the client must have its own personal cert (because that contains the private key) and the server must trust whatever signed the client's matching public key. If the client cert is self-signed the QMgr has to trust it. If the client's cert is CA-signed, the QMgr must trust the signer. Either way, the QMgr has to have a cert to validate the client in its KDB.
Following this logic, for anonymous client connections the required parts are the personal certificate in the QMgr's keystore (because it contains the QMgr's private key), and the matching trusted certificate in the client's KDB or for Java the Trust Store. Neither of these is optional.
If the client is to be authenticated you still need the same two certs as for anonymous clients because that part of the handshake has to complete before the client is authenticated. In addition, now you also need the client to have its own personal certificate (because it contains the client's private key) and the QMgr now needs to trust whatever signed the client's certificate - the client cert if self-signed or the signer root if CA-signed.
As a side note, There is also some confusion in the post because it says that "My WMQ 7.5 client application is C code and the WMQ server is running Java." There is nothing in the queue manager that uses Java on the server side. There are Java components installed to do things like manage JNDI objects and run the sample code. In modern MQ versions Java runs the Web Console. But there are no Java components in the QMgr itself and no Java components in the path of the incoming channel connection request. That's all habdled by the QMgr's listener, agent, and other internal processes. So I'm not at all sure what is being referred to there other than that the notion of Java running on the MQ server side and participating in the TLS handshake might be a source of some of the confusion mentioned in the post. ;-)
I want to establish a secure connection using TLS to m12.cloudmqtt.com (MQTT Cloud - cloudmqtt.com) for my owntracks MQTT client (Android device).
According to documentation at OWNTRACKS (http://owntracks.org/booklet/features/tls/ ) one has to provide CA CERT and the CLIENT CERT.
CA CERT I can understand according to documentation at cloudmqtt.com (www.cloudmqtt.com/docs-faq.html#TLS_SSL) is a trusted public CA. (That I can obtain from any cert store)
But for CLIENT CERT, how do I obtain this? Do I need to obtain a certificate ( for my android MQTT Client) from the above CA. Or is any other way possible to encrypt the session ?
Client certificates are only needed if the broker supports certificate based client authentication. The connection will still be encrypted and you can verify the broker is who they claim to be.
The cloudmqtt doc does not mention certificate based client authentication. So the implication is that they do not support client authentication.
You should be able to set Owntracks up with a username and password and TLS without a client certificate
When securing WCF services with server and client certificates there is an easy way to ensure the identity of the service provider certificate (server certificate), by comparing the public key or finger print of the sender certificate with an expected value.
On http://msdn.microsoft.com/en-us/library/ff648360.aspx this is explained in step 8. You can config your app.config file in the endpoint section with an identity element where you can pass in the expected encoded finger print value of the server certificate. A comparison between received service certificate and expected value ensures I am talking to the server I expect.
But now I consider the servers point of view. The server can have several RootCA certificates in its certificate store. If the client certificate send from the requester was issued (and signed) by one of these RootCA my service will trust this client certificate. How can I ensure that my service will only trust certificates issued by one determined RootCA? And how can I configure the one trusted RootCA?
(I think this could be some kind of an equivalent way of certificate pinning for client certificates issued by on RootCA)
The only way to achieve this would be to roll your own custom x509 certificate validator. Then for each incoming request you can simply check to make sure the client certificate was issued by your root CA. It's actually quite easy to do. You can find the steps to implement this here:
How to: Create a Service that Employs a Custom Certificate Validator
I'm trying to create web application with client certificates, generated programmatically. My main problem is following: I've added generated .p12 keystore to my web browser, but it doesn't send certificate to the server.
How does browser understand which x509 certificate it should use? And is it possible to debug SSL in Chrome of Firefox?
SSL/TLS server sends Certificate Request message (see RFC 4346 for TLS 1.1 or others). In this message there is only certificate type and acceptable certificate authorities names, so server doesn't tell anything about particular certificate.
The possible reason is that your certificate of invalid type (i.e. DSA instead of RSA but key exchange algorithm depends on client RSA certificate), or server requests certificate of different certificate authority.