Certificate not trusted in when redirect URL

However for the https connection I always receive this certificate error that this one is not trusted.what certifciate subject are you using in clientssl profile? does it contain both www.mcneilonline.co.uk and www.mcneilonline.co.uk?

 

 

sol13471: Creating SSL SAN certificates and CSRs using the Configuration utility or tmsh

 

http://support.f5.com/kb/en-us/solutions/public/13000/400/sol13471.html

Hi,

 

 

 

I'm using the default certficate.

 

 

General Properties

 

Name default

 

Certificate Subject(s) localhost.localdomain, MyCompany

 

 

Certificate Properties

 

Expires May 21, 2021

 

Version 3

 

Serial Number

 

Subject Common Name: localhost.localdomain

 

Organization: MyCompany

 

Division: IT

 

Locality: Seattle

 

State Or Province: WA

 

Country: US

 

 

Issuer Self

 

 

 

Howver, the certificate for the website itself on a Juniper device. Other URL's work like that (where no redirect is needed, so no client ssl profile is used). This works.

 

So I guess because a redirect is needed on HTTPS traffic for this Virt. Server, the certificate needs to be on the F5 and needs to be selected as client SSL profile on the virtual server, right ? Or is there another way ?

 

 

 

Thanks,

 

Frederik

 

 

 

So I guess because a redirect is needed on HTTPS traffic for this Virt. Server, the certificate needs to be on the F5 and needs to be selected as client SSL profile on the virtual server, right ? yes.

 

 

the certificate for the website itself on a Juniper device.you have to copy certificate and key from juniper and import into bigip, set them in clientssl profile and then assign it to the virtual server.

You can alternately not have any client or server SSL profiles on the virtual server and just let the SSL pass directly through to the server. As long as 1) the host name the client is asking for is in the server's certificate (subject or subject alt name), and 2) the certificate is trusted by the client, you should be good to go.

 

 

The downside of the above approach is that you lose the layer 7 flexibility on the BIG-IP for this traffic (HTTP iRules, cookie persistence, etc.). Your better bet, as Nitass shows, is to terminate the SSL on the BIG-IP (and optionally re-encrypt but not absolutely necessary). This requires you to put the server's certificate and key on the BIG-IP and assign them to the client SSL profile used by the virtual server. If you must re-encrypt, you can most likely just apply the generic serverssl profile to the virtual server as well.

 

Thanks a lot Kevin & nitass.