Brocade vTM Load Balancer 600 L 10.1 unable to decrypt traffic from HTTPS to backend node

[mrt2828]

Problem: External HTTPS user needs to access the load balancer for decrypt, then encrypt to query backend node server. We generated a private key, had the cert signed by CA, sent the user the public key as well as loaded the .pem into the load balancer. Subsequently, the HTTPS user generates a private key and sends us his public which we load into the LB Certificate catalog. The problem is that when the HTTPs queries from the public site, we get bad certificate errors, Certificate Required and not sent, or no shared ciphers. It makes me think tha the encryption to the backend node may not be happening. Does anyone have any ideas?

Thanks.

[mbodding]

Hi MRT,

The vTM can do client authentication in SSL, you need to enable it on the vserver and upload the CA which signed the clients certificate to the vTM. This goes into the CA catalog, not the Server certs catalog.

If the clients cert is self-signed, then you could upload that, but I'm not sure if it would work (basic constraints would probably be wrong). But even if it does it would be a huge security risk. Your client could sign certs for other people and the vTM would accept them. Eeek! Obviously if this vTM is only serving that one client, then it may not be an issue for you. But be warned!!

You should really run your own CA for this and have clients geneate the key pairs, and then email you CSRs for you to sign. Then configure vTM to require clients to have certificates signed by your CA.

Note that the vTM can not pass through the clients certificate to the backend server. The vTM does not have the clients private key. If you need the server to have that information, then you should look at the options under SSL to include the data in HTTP headers, which your application or webserver can then look for.

Cheers,

Mark

[mrt2828]

Mark,

Thank You. This was very helpful. Just a couple other questions. In order for the vTM you mentioned configuring SSL headers. WHen configuring the headers, where does the private key information come from. Second question, will the web client need to load the vTM's public key in order to authenticate? 

Thanks,

MRT

[mbodding]

Hi MRT,

The SSL Headers which can be passed through include details about the server certificate used when "ssl_headers" are enabled, and about the clients certificate when "ssl_client_cert_headers" are enabled.

The "ssl_headers" option adds:

--------------------------------------
Header name | Sample Value
SSLClientCipher | SSL_RSA_WITH_AES_128_GCM_SHA256, version=TLSv1.2, bits=128
SSLClientCertStatus | NoClientCert or OK
SSLSessionID | 8723367551317ABE5443278C6E… (64 hex characters)

--------------------------------------

The ssl_client_cert_headers adds:

-----------------------------------------

Header name | Sample Value

SSLClientCertVersion | 3

SSLClientCertSerialNumber | 742662

SSLClientCertIssuer | C=US, ST=CA, L=San Jose, O=MyOrg

SSLClientCertSubject | C=US, ST=CA, L=San Jose, O=MyOrg

SSLClientCertNotValidBefore | 1155304575 (unixtime)

SSLClientCertNotValidAfter | 1186840575 (unixtime)

SSLClientCertSubjectPublicKeyRSA | (2048 bit)

SSLClientCertSignatureAlgorithm | md5withRSAEncryption

SSLClientCertHash | 873FECCB50E0C1D34711ABE65BA70BA7

SSLClientCertSHA1Fingerprint | 7D90A8EB6081183C0560970A7DA77306C40E5DD2

SSLClientCert (if enabled) |The entire PEM-encoded certificate text.

-------------------------------------------

The client never sends the private key, so vTM does not have access to that information, nor should it. You do have access to the SSLClientCert though, and vTM will have verified that the client is in posession of the private key during the SSL negotiation.

The web client would only need to have the vTMs public certificate installed if there were no chain of trust back to a trusted CA. If you have had the certificate on vTM signed by Thawte, Verisign or some other public CA provider, then the client probably doesn't need it.

Cheers,

Mark