The Web Site for the CA Must be Configured to use HTTPS

KB ID 0000838 

Problem

When attempting to contact a server running the Certification Authority Web Enrolment role, you may see the following error.

In order to complete certificate enrolment, the Web site for the CA must be configured to use HTTPS authentication

Solution

The correct fix is to set the web server (IIS) to serve the certificate website securely using https, though you can just set Internet explorer to ‘work’ from your client machine if you are in a hurry.

Make Internet Explorer Accept Your Certification Authority

Note: This would need to be done on every machine that you wanted to access the Certificate Services web portal from.

1. From within Internet Explorer > Internet Options > Security > Trusted Sites > Sites.

 

2. Untick ‘Require server verification (https:) for all sites in this zone’ > Then add in the URL of the CA > Close.

3. With Trusted sites still selected > Custom level > ‘Initialize and script ActiveX controls not marked as safe for scripting’ > Enable > OK > Yes.

4. Restart the browser and try again.

Set IIS to serve Certificate Services Securely (via https).

This assumes you have your CA and the web portal installed correctly.

1. On the Certificate Services Server > Launch IIS Manager > Expand {server-name} > Sites > Default Web Site > Right Click > Edit Bindings > https > Edit > Select the self signed server certificate [NOT the CA ONE] > OK.

Note: If https is missing simply add it!

2. Expand Default Web Site > Certsrv > SSL Settings.

 

3. Tick ‘Require SSL’ > Apply.

4. That should be all you need, if it does not take effect straight away then drop to command line and run iisreset /noforce.

Related Articles, References, Credits, or External Links

NA

Cisco ASA – Disable SSLv3 (Force TLSv1.0) – Mitigate POODLE

KB ID 0001052

Problem

By default the Cisco ASA will allow connection via SSLv3. The POODLE exploit works by forcing SSL to fall back to SSLv3 and then decrypting that communication. However you are still not completely protected as per this Threat Validation, so the ASA platform can still be attacked via TLSv1.0. Note: At time of writing TLSv1.2 is not supported, but it is on the road-map for version 9.3(2).

So this procedure will not completely eliminate the threat, but it’s as mitigated as it’s possible to be at this time, (And TLSv1 is considered more secure than SSLv3 anyway).

Solution

1. You can check your firewall is contactable via SSLv3, here I’m on MAC OSX and I’ve got OpenSSL installed. If I try to initiate an SSLv3 connection it works.

[box] openssl s_client -connect {IP_or_Hostname} -ssl3 [/box]

Or if you have nmap installed you can use that as well;

[box]nmap –script ssl-enum-ciphers {IP_of_Hostname}[/box]

2. Below you can see I’m confirming the SSL settings (i.e. it will accept SSLv3). Then I force the firewall to only accept TLSv1.0.

[box]

Petes-ASA# configure terminal
Petes-ASA(config)# ssl client-version tlsv1-only 
Petes-ASA(config)# ssl server-version tlsv1-only 

[/box]

You can see, afterwards when I view the SSL options, only TLSv1 will be accepted.

3. If you prefer to use the ADSM, then you will find the same settings at, Configuration > Remote Access VPN > Advanced > SSL Settings;

The SSL version for the security appliance to negotiate as a ‘server’ = TLS V1 Only

The SSL version for the security appliance to negotiate as a ‘client’ = TLS V1 Only

 

4. Don’t forget to ‘Apply’ and then save the changes.

Cisco ASA Testing for SSLv3

Simply perform the tests that I did above;

1. Proving the absence of SSLv3 with OpenSSL.

2. Proving the absence of SSLv3 with nmap.

Related Articles, References, Credits, or External Links

NA