They're essentially saying that the server supports older ciphers that could "potentially" be used for malicious activity. A registry "hack" will stop the ISA Server from responding to those older ciphers. Let me see if I can't find it (I just recently had to review this for SOX compliance). On Thu, Dec 31, 2009 at 7:46 AM, Mike Anderson <mike@xxxxxxxxxxxx> wrote: > Hello All, > > > > We have Win2K3 web server behind an ISA 2004 Server, which hosts our > website (with a SSL Certificate for doing credit card transactions). > > > > As of 3 months ago, we started getting these warning e-mails from our > credit card merchant people stating that we failed their PCI Compliance > test. If we don’t get this fixed, we will start to be penalized and we > can’t let that happen. > > > > SSL Certs are probably one of my weakest areas and I just know enough to > get by. The PDF generated from their automated system, outlined the trouble > areas and offered some websites we could visit that could help remedy the > problem. I must say, being a technical person myself, I had a hard time > navigating the documents in addition to understanding how they applied to > our problem. > > > > The next 2 blocks of text are the 2 primary areas that killed our PCI > Compliance score, and if we can fix this, we should be okay once again. > BTW, the following blocks of text, correspond to TCP, Port 443 & HTTPS… > > > > The first one: > > > > Synopsis : The remote service supports the use of weak SSL ciphers. > Description : The remote > > host supports the use of SSL ciphers that offer either weak encryption or > no encryption at all. > > See also : http://www.openssl.org/docs/apps/ciphers.html *Solution*: > Reconfigure the affected > > application if possible to avoid use of weak ciphers. *Risk Factor*: > Medium / CVSS Base Score > > : 5.0 (CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N) Plugin output : Here is the list > of weak SSL ciphers > > supported by the remote server : Low Strength Ciphers… > > > > The second one: > > > > Synopsis : The remote service encrypts traffic using a protocol with known > weaknesses. > > Description : The remote service accepts connections encrypted using SSL > 2.0, which > > reportedly suffers from several cryptographic flaws and has been deprecated > for several years. > > An attacker may be able to exploit these issues to conduct > man-in-the-middle attacks or > > decrypt communications between the affected service and clients. See also : > > http://www.schneier.com/paper-ssl.pdf *Solution*: Consult the > application's documentation to > > disable SSL 2.0 and use SSL 3.0 or TLS 1.0 instead. *Risk Factor*: Medium > / CVSS Base Score > > : 2 (AV:R/AC:L/Au:NR/C:P/A:N/I:N/B:N) > > > > Now my question is, does the ISA Server come into play with this whole > thing? Or is the primary problem relating to our Web Server and how the SSL > Cert was originally created? I didn’t create the initial key and purchase > the original certificate, but I know darn sure that the person who did, > would have selected the strongest encryption available at the time – which > would have given us the peace of mind secure transactions. > > > > I know that in order to get the SSL to pass through the ISA Server, we had > to export the SSL Cert from the Web Server and install it on the ISA > Server. Was there something different that I should have done during that > process? Do we possibly have to trash our existing SSL Cert, and reapply > for a newer strong one? > > > > Again, I apologize for being so green in this area – I can only be good at > so many things J > > > > Thank you all again in advance, for all your wonderful help. > > > > Mike > > > -- Cordially yours, Jerry G. Young II Microsoft Certified Systems Engineer