1 Reply Latest reply: Jan 28, 2013 11:26 AM by MrHoffman
Brian Dieckman Level 1 Level 1



We have implemented QualysGuard Enterprise Suite here and two of my servers keep popping up with an SSL vulnerability.


The "Solution" section of the report says "Disable support for anonymous authentication."


The only service running on either machine is AFP. In the "Access" tab of the "Settings" for AFP on both servers, I have unchecked "Enable Guest access" and "Enable administrator to masquerade as any registered user" though I doubt either of those selections have anything to do with SSL...


Since SSL is often used in remote control schemas, I've also set "Remote Login" and "Remote Management" to allow access for only Administrators but again I see no settings specifically for SSL.


Finally, I have set the root certificates for these servers to "Always Trust." (Previously the certificates reported "This root certificate is not trusted")


Can you think of anything I've missed with regards to SSL authentication?





  • MrHoffman Level 6 Level 6

    Short answer: Contact the vendor.  Ask them what this means, and what the risk is.


    There's one previous similar report.  


    As the most likely path to resolution, contact the vendor for this QualysGuard product and ask for assistance in determining the trigger for and their opinion of the risk and suggestion(s) for resolving this.  (The diagnostic is similar to a common phrase over in Windows Server configurations, so I'm wondering if the system might have misidentified the OS X Server systems.)  QualysGuard support likely knows the tool the best, after all. 


    Failing resolution of that support request to QualysGuard, I'd suppress this diagnostic, ignore it, or potentially remove the tool.


    Background: SSL is a fundamental security protocol, and very commonly used on the Internet.  SSL is a very common approach used to secure TCP connections against monitoring, spoofing and various other attacks.  While there are various attacks against SSL and fundamental questions around the security of the certificate chain of trust, SSL is still the best available choice.


    I am generally somewhat skeptical around products with "enterprise" or "suite" in the name, and of tools that "monitor", "tune", "optimize" or "secure" systems.   Some of these tools can be good and useful.  Many of these tools can generate spurious messages or odd misbehaviors or bugs; errors on one system or one configuration that might not be applicable to the current case being detected and reported; a "false positive".  Other tools spend substantial time and effort tossing blizzards of inconsequential messages into logs and dialog boxes, seemingly in an effort to prove their worth, sometimes causing stability problems, or just getting in the way. 


    Put another way, I prefer to be skeptical around all of these sorts of tools.