HTTPS certificate issues...

[Dominick Converse]

I have used OpenSSL to generate my CSR and key, I submitted the CSR to my CA and they issue the signed cert back. I have been unable to load this cert and key into the WSA. It keeps telling me that this is a server certificate a signing certificate is required. I have been unable to get this to work or use any certificate that I generate. What other options exist besides using the WSA generated certificate and key and having to deploy this to over 100k workstations. Using my CA to signed the cert and take advantage of a certificate already loaded on my workstations is the preferred direction but the WSA does not seem to be flexible to use anything that we create.

Thanks

Dominick

[Jernej Vodopivec]

Hi Dominick,

you said you have CA installed in your environment. And you said you've already deployed CA certificate to 100k workstations. I guess you haven't deployed it one by one, am I right?

One way could be that if you use Microsoft Active Directory in your environment you can deploy WSA certificate to all 100k workstations by creating Group Policy Object. You'll configure GPO to deploy WSA certificate in Trusted Root CA container on all workstations. That should take you 3 minutes max.

If you don't use AD what do you use to centrally configure workstations?

[Dominick Converse]

You are correct and we can use a GPO to deploy to all the workstations, currently we create the workstation builds to include the certificates and we are trying to utilize the certificates that already exist on all workstations from our CA. The WSA generated certificate does not meet the minimum standards required for certificates in my environment and require me to use OpenSSL to generate the cert for all the workstations. In an environment my size, you like to touch the workstations minimally.

[Jernej Vodopivec]

What are the minimum standards required for certificates in your environment?

[Dominick Converse]

2048-bit and better than sha1 as a minimum.

[Jernej Vodopivec]

You have two options:

1. Upload CA's private key and certificate to WSA.

2. You can use intermediate certificate with WSA:

- upload root CA's certificate to WSA: Network > Certificate Management .

- create private key + csr with openssl and sign it with root CA

- import key + certificate to WSA

- deploy certificate to workstations in intermediate CA container

I haven't tried it yet but it should work. But you'll still have to deploy a additional certificate to workstations.

[Dominick Converse]

We have tried option 2 and the WSA rejects the certificate and key as a server certificate, it demands a signing certificate. The only certificate that it seems to accept is the one that you are able to generate on the WSA itself. This does not meet our minimum requirements.

[Jernej Vodopivec]

I'll try to do the same in my lab tomorrow and I'll let you know what are exact steps nnes to be taken if I succeed.

Like I said I haven't tried it yet. ;)

[Jernej Vodopivec]

Hey Dominick, I've succesfully configured this in my lab environment. Here are the steps I've taken:

1. create 2048 bit private key: openssl genrsa -out key.pem 204

2. create csr: openssl req -new -key key.pem -out csr.pem

3. submit csr to my enterprise CA installed on windows 2012r2 server - basaed on "subordinate CA" template

4. save certificate in base64 form

5. install CA certificate on my browser trusted CA container (you said you've already done that)

6. install CA certificate on WSA: Network->Certificate Management

7. install key.pem and certificate in base64 form on WSA: Security Services-> HTTPS proxy

It works without any problem.

[Ken Stieers]

Jerenj,

Someplace in a different thread Dominick explained that they dont have an internal Enterprise CA... They pulled it all out.  He's been trying to use a cert from a public CA (Comodo)since the trust is already there.  

Dominick, I think you're going to have to distribute a cert (root or actual generated from the appliance) no matter what you do.  As far as I can tell, no CA is going to sell you what you need. 

What you could do is stand up a standalone root cert on a test vm, make sure to create its root cert with what you need for Bits and hash, and either generate a subordinate cert per Jerenj's notes or export the root cert and use it like you would the demo cert.   Either way each domain needs to add a cert to the appropriate group policy...Then just nuke the vm since you dont need it to actually gen certs...

[Jernej Vodopivec]

Ken, I've missed that thread :)

If that's the case then Dominick will have to deploy one certificate on all workstations at least.

And I think the easiest and shortest way to do that is to simply download cert from WSA and deploy it in Trusted root CA container on all workstations by creating simple GPO. You even don't need to create temporary CA. You can assign this GPO to only few workstations in the beggining for testing purposes. And if everything goes well you reassing it to all computer nodes.

[Ken Stieers]

Yes, sxcept the I think the demo is 2048 bit/sha1, and he needs 2048bit/sha256. 

[Jernej Vodopivec]

Of course, I forgot about that;)

[Dominick Converse]

Thanks for the comments, that is what I was expecting but figured I would ask to see if anyone else has had other luck. I have a Linux server that I will use to generate a self-signed cert and key via OpenSSL, upload it to the WSA and then push out the cert using a GPO to all workstations. I am building a config file to allow for subject alternative names because I have 8 WSA's and only want to create on cert and key.

Dominick

[Ken Stieers]

You don't have to do a SAN cert.  This is essentially a "root cert", like any other big public CA's cert.

This cert is used to create a NEW cert, on the fly, for every HTTPS site your users hit.   Since the root cert is in the root store these new ephemeral certs are trusted...

Its name is never actually checked against anything, but the cryptographic relationship is...