Please someone help me clear below doubt. Below is the scenario i am demonstrating in LAB.
1) I have generated CSR on LTM and provided to CA (CA is my Windows server 2012)
2)With the help of open SSL on Windows server 2012 i generated public and private key pair and signed the CSR. "TESTVIP" is name of my newly signed certificate. I also extracted public key from CAserver.
3)I have imported "TESTVIP" certificate and private key in LB(got private key while generating CSR on LB).
Question1) When i am associating this (TESTVIP and private key) to client SSL profile it is giving me an error "KEY and certificate do not match. Though i have done it correctly.
Question2) Also i am trying to install CA public key in end user browser to trust the website, but it says "this file is invalid for use as following security certificate". How can i establish that green lock symbol in URL in such LAB scenario?
Any help would be appreciated.
I think you made some error here: "i generated public and private key pair and signed the CSR".
When you create a CSR, you do so based on a private key. If you created the CSR in BIG-IP, the private key is automatically created for you, and stored there.
If you create a public certificate based on a new private key you generated elsewhere, it will never match the private key stored in BIG-IP.
When you use public CAs, the whole point of using a CSR is that you don't ever have to share the private key. The concept here is similar - you provide the CSR so the CA signs it. No new private key is created.
About importing CA certificates to a test client, be aware that Firefox uses its own CA list. IE/Edge/Chrome use windows certificate store. You should import your CA certificate to either user or computer certificate store, under "Trusted Root Certification Authorities > Certificates".
Hope it helps.
I again tried generating same.
Associated private key
site2testvip.crt (only cert is sent, private key is retained) is sent to CA for signing. Below command issued in powershell to sign the CSR.
command 1: openssl genrsa -out windowscakeypair.key 2048 -->used to generate key pair
command 2:openssl rsa -in windowscakeypair.key -pubout -out windowsca_public.key -->To extract public key
command 3:openssl x509 -in site2testvip.crt -out newsite2testvip.crt -req -signkey windowscakeypair.key -days 365 --->To Sign the Certificate
Unfortunately it is giving an error. Once it is signed, newly generated cert is installed in client browser for https communication.
Hi mike, yes the private key is for CA itself. I have gone through many websites and asked same set of question on another forum, but still didn’t understand how this all fits in.
i would really appreciate if you tell me how to make https possible here. This would also help me in my organization where i am working.
Just one thing there: most browsers today consider certificates as unsafe when the Subject Alternative Name is not populated with the correct hostname, so when you create the CSR, be sure to also fill out the Subject Alternative Name field.
Let's say you are creating a certificate for the website "www.company.com". You would fill the Common Name field with "www.company.com" and the SAN field with "DNS:www.company.com". If you have aliases or other DNS names you want to use you can also use a SAN like "DNS:www.company.com, DNS:site.company.com, DNS:company.com".
Note that you don't need to export the private key from F5.
Now for the parts not covered in K14620...
1. Signing the CSR.
I like using openssl for the key/CSR/certificate checking, but honestly it's way easier to use a software like SimpleAuthority to create a CA and create or sign certificates. You can get it here: https://simpleauthority.com/
2. Making your own CA trusted in client machines
Export the public CA certificate to a PEM format or any other you prefer. In windows, click the file. Click the "Install Certificate..." button, it should open the "import certificate" wizard. Choose Current User or Local Machine. In the next step don't use the automatic option; force the certificate to be installed in the "Trusted Root Certification Authorities".
3a. Putting it all together v1 (full SSL offload)
Your Virtual Server will need at least 2 profiles: HTTP and Client-SSL. The client SSL profile will use the certificate and key you created, like explained in the article. If you're using plain HTTP on the server side, that's it.
3b. Putting it all together v2 (HTTPS in the backend)
Some organizations require full encryption also on server side. If this is the case you will also need a Server-SSL profile. You can use the default "serverssl", it'll gobble anything, including invalid certificates.