Hi All, We are currently implementing 2-way SSL on our F5. Servers is using port 8011 and we need to encrypt only from client to F5. Now, we use self-signed certificate from F5 since the client don't want to spend money on signing certificates to CA. We can access the application via https but CLIENT wants client authentication to be enabled because when we access the application, wether the ssl certificate is installed on browser or not, we can still access the application. Thanks! Ferdz

So by "client authentication" I assume you're talking about client certificate authentication, yes? If so, are you using Access Policy Manager (APM) or just LTM and the client SSL profile? In either case, do you have the client authentication setting set to "request" or "require"?

we are using client SSL profile and selfsigned certificate. on the client ssl profile, when we set the client authentication to "request" or "require", the result is ssl error.

when we set the client authentication to "request" or "require", the result is ssl error. The self-signed certificate, I presume, is defined in the client SSL profile. This certificate is only really relevant to the client. When the client initiates an SSL session with the server (BIG-IP VIP), one of the first things the server does is send its certificate (the public certificate in the client SSL profile). The client (browser) must then decide if it trusts that certificate by way of a few checks: Is the certificate valid (unexpired, valid attributes)?Is the certificate trusted - can a complete chain from this certificate to a root certificate be established, and does the browser have access (and explicitly trust) the root certificate and potentially all CA certificates in between? If you use an IP address to access an SSL site, you'll most often get a security warning in the browser that the certificate is not trusted. This is usually because you've violated check 1 above - the name you asked for didn't match the name in the certificate. If you don't have an explicit trust established with the CA that issued the server's certificate, that's another reason for a security warning. In your case, since you're using a self-signed certificate, you'd necessarily have to install that certificate in the browser's trust store to avoid the security warnings. As for client certificate authentication, you need either the request or require options set in the client SSL profile to be able to prompt the user for a client certificate. They both, more or less, perform the same function - requesting a certificate from the client during the SSL negotiation. The most significant difference is how each deals with what the client sends. You can think of this process as a reverse of the server certificate and browser check process. In this case the server (BIG-IP) must be able to validate the certificate presented by the client. Is it a valid certificate? Can a chain of trust be established between the client's certificate and an explicitly trusted set of CA certificates? The require option is a definitive check. All of the tests must pass. The request option, however, is a "soft" check. It will generally not fail if any of the tests fail. So given the above, please answer these questions: Just to clarify, with a simple client SSL profile applied to the VIP, no client certificate authentication enabled, you can get to the application via HTTPS://, correct? If yes above, do you get a security warning in the browser that the server certificate is not trusted? Or have you installed that certificate in the browser's trust store? What specifically happens when you enable the request option in the client SSL profile? Do you have any iRules applied to the VIP while testing that are looking for certificate attributes? Are you seeing anything in the LTM logs that may indicate a problem?

HI Kevin, Yes, i can access it with client authentication(Client certificate set to "ignore")Yes, at first i get security warning.I stand corrected, if we use "request" we are directed to the application but if "required", it says "page cannot be displayed"no irules and no logs regarding certificates By the way, we use self-signed and ip address in accessing https://10.164.45.45 Thank you in advance! Ferdz

I stand corrected, if we use "request" we are directed to the application but if "required", it says "page cannot be displayed" And that makes sense. The client is passing a certificate to the BIG-IP that the BIG-IP MUST be able to validate (given the require option). For the BIG-IP to be able to validate the client's certificate, you must obtain and specify a "CA bundle". If you're familiar with browser's trusted certificate store, this is a bucket of certificate authority public certs that the browser EXPLICITLY trusts - by virtue of their existence in the store. When a server sends its cert to the client, the client browser must validate trust by way of creating a chain from the server's certificate to the issuing CA of that certificate (and potentially the issuing CA of that certificate if multi-level) and terminating at a trusted root certificate. Your self-signed certificate only differs in that it is its own self-signed root, so the browser would NEVER trust this certificate unless it was specifically installed in the browser's trust store. For client certificate authentication, this process is reversed, and the BIG-IP performs the same validity and trust checks that the browser did for the server's cert. The BIG-IP, however, doesn't have a single CA trust store, so each client SSL profile must be given one. If you look in the client SSL profile, you'll see an option for "Trusted Certificate Authorities". This option allows you to select a single certificate (or bundle of certificates) that the BIG-IP can use to establish trust with the client's certificate. If, for example, the client certificate is issued by Verisign, you need Verisign's public CA certificate applied to the Trusted Certificate Authorities option. If you expect to accept clients with certificates issued from multiple CAs, then you can create a bundle file - a text file that contains the PEM/Base64-encoded value of each CA's certificate. Example: -----BEGIN CERTIFICATE----- MIIEgTCCA+qgAwIBAgIBAjANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzER MA8GA1UEChMIdGVzdC5jb20xHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEUMBIGA1UEAxMLY2EudGVzdC5jb20wHhcNMTMwNTAxMDQyMzQ1WhcNMTYwMjE5 ... -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- JIIEgTGGB+qgAwIBAgIBAjANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzER FA9GB1UEChMIdGVzdC5jb20xHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEU8BIGA1UEAxMLY2EudGVzdC5jb20wHhcNMTMwNTAxMDQyMzQ1WhcNMTYwMjE5 ... -----END CERTIFICATE----- Put those into a text file and import them like you would a single certificate.

2 way SSL implementation

Kevin_Stewart
Employee
Sep 10, 2013
I'm a little more confused now. Do you have an SSL VIP (port 443) that has:

a client SSL profile to decrypt the client SSL
optionally a server SSL profile to re-encrypt to the back end server

Does the back end server need encryption?
Spidey_29396
Nimbostratus
Sep 10, 2013
Number 1 answer is yes, number 2 answer is no. We have two VIPs, one is http and one is https, but same pool members http, we are trying to offload ssl for the https VIP. we want to have cliet certificate authentication between f5 and client.
Kevin_Stewart
Employee
Sep 10, 2013
Please verify that the client going through the HTTPS VIP is getting redirected to an HTTPS URL.

Also, for testing, disable the HTTP VIP so that all traffic is forced through the HTTPS VIP.

And to clarify, the HTTPS VIP should not have a server SSL profile.
Spidey_29396
Nimbostratus
Sep 10, 2013
Hi Kevin,

Yes it is being directed even if we only type https://10.10.10.10 it is being rdirected to https://10.10.10.10/ordering?WDSL

We cannot disable the http because it is already in production

For server ssl, it is set into none
Kevin_Stewart
Employee
Sep 10, 2013
Okay, just to level set, this SSL-only configuration worked in your lab, but doesn't work in production, correct? And the only difference that you can see is the presence of a redirect? What if you go directly to "https://10.10.10.10/ordering?WSDL"? Are you getting any server side logs? Any LTM logs? Are there any differences besides these in the two configurations? And in the clients and/or servers?
Spidey_29396
Nimbostratus
Sep 10, 2013
Yes, that's the only difference..if we go directly to https://10.10.19.10/ordering?WDSL, still same result " connection interrupted"

Ill check if there are ltm logs or server logs for testing tomorrow
Spidey_29396
Nimbostratus
Sep 11, 2013

Hi Kevin,

I think it is working now in production, i simulated again in Lab because i can still see certifcate error on accessing the application, is this normal?

Certificate Error says IP address mismatched.

Thanks! Ferdz
Kevin_Stewart
Employee
Sep 11, 2013
Yes, that's absolutely normal. There's two things going on:

You're using what appears to be the default client SSL certificate/key on the BIG-IP.

You're accessing the VIP with an IP address.

A browser will generally complain if:

The x509 subject of the certificate that is provided by the server in the SSL negotiation doesn't match what is requested (happens when you use an IP address to access the site)

The certificate provided by the server/VIP in the SSL negotiation is somehow invalid (expired, revoked, etc.)

The client cannot create an explicit trust chain from the server's certificate to the issuing CA certificate(s). These are the certificates in the browser's intermediate and trusted authority trust stores.

You'll eventually need to import a good cert/key pair to the BIG-IP and then modify the VIP's client SSL profile to use these.
Spidey_29396
Nimbostratus
Sep 11, 2013
Thank you kevin.ill let the client know about your findings

Forum Discussion

2 way SSL implementation

Recent Discussions

When user goes through LB the server page has stripped information

HIGHLY RECOMMENDED LOST CRYPTOCURRENCY RECOVERY SERVICE/ DIGITAL TECH GUARD RECOEVRY

Help with an I-rule rewrite

When adding new GTM(DNS) to the existing group, if software version is not same, what will happen?

Keep encoding when request is handled by irule

Related Content

Implementing SSL Orchestrator with OPSWAT MetaDefender

Implementing SSL Orchestrator - Validation & Troubleshooting

Implementing SSL Orchestrator - L2 Mode Deployment

Implementing SSL Orchestrator - L3 Mode Deployment

Implementing SSL Orchestrator - Network Insertion Use Cases