Security

Good day, Everyone.

My security bubbas are using Tenable SC to scan my new ClearPass instances hosted in Azure.

They are telling me that the "self signed" certificates are being provided during authentication requests. This qualifies a security hit.

<quote>

When checking plugin 51192 in Tenable SC, the connection used is a secure socket layer (SSL) connection to the target host, as this plugin specifically detects and reports on untrusted SSL certificates, meaning it needs to establish an encrypted connection to the target port to analyze the certificate details.

...

Tenable SC attempts to connect to the target host's port using SSL and analyzes the certificate chain to determine if it can be trusted based on its known trusted certificate authorities.

...

57582:  SSL Self-Signed Certificate

Steps to Remediate:
Purchase or generate a proper SSL certificate for this service.

OUTPUT:

The following certificate was found at the top of the certificate chain sent by the remote host, but is self-signed and was not found in the list of known certificate authorities :

|-Subject : CN=<servername>/O=PolicyManager

</quote>

So the nuts and bolts of my question is:

What can I disable in my Trust List to eliminate this 'vulnerability' without breaking my database replication between the Publisher and Subscriber?

We're going to make these VAs 'Prod' soon, and I want to make sure that I'm not getting roasted over the coals by the Security Wonks.

Thanks in advance,

John

------------------------------
John MacDonald
----
Just another geek trying to figure things out.
------------------------------

What are they testing against that they are getting the certificate?

Every certificate that ClearPass uses can be replaced, even the database replication certificates.  Of course, that means you then have to manage those certificate manually at that point.

------------------------------
Carson Hulcher, ACEX#110
------------------------------

Thanks for the input, Carson.

This is all my security guys have given me:

51192:  SSL Certificate Cannot Be Trusted

Steps to Remediate
Purchase or generate a proper SSL certificate for this service.

OUTPUT:

The following certificate was at the top of the certificate
chain sent by the remote host, but it is signed by an unknown
certificate authority :

|-Subject : CN=<serverName>/O=PolicyManager
|-Issuer  : CN=<serverName>/O=PolicyManager

 

57582:  SSL Self-Signed Certificate

Steps to Remediate:
Purchase or generate a proper SSL certificate for this service.

OUTPUT:

The following certificate was found at the top of the certificate
chain sent by the remote host, but is self-signed and was not
found in the list of known certificate authorities :

|-Subject : CN=<ServerName>/O=PolicyManager

^ Not very helpful.

So, I asked for further information, and this is what they gave me (that I tried to abbreviate for simplicity in my original post):

When checking plugin 51192 in Tenable SC, the connection used is a secure socket layer (SSL) connection to the target host, as this plugin specifically detects and reports on untrusted SSL certificates, meaning it needs to establish an encrypted connection to the target port to analyze the certificate details.
 
This plugin examines the chain of X.509 certificates used by this service.
 
The server's X.509 certificate cannot be trusted. This situation can occur in three different ways, in which the chain of trust can be broken, as stated below :
 
- First, the top of the certificate chain sent by the server might not be descended from a known public certificate authority. This can occur either when the top of the chain is an unrecognized, self-signed certificate, or when intermediate certificates are missing that would connect the top of the certificate chain to a known public certificate authority.
 
- Second, the certificate chain may contain a certificate that is not valid at the time of the scan. This can occur either when the scan occurs before one of the certificate's 'notBefore' dates, or after one of the certificate's 'notAfter' dates.
 
- Third, the certificate chain may contain a signature that either didn't match the certificate's information or could not be verified. Bad signatures can be fixed by getting the certificate with the bad signature to be re-signed by its issuer. Signatures that could not be verified are the result of the certificate's issuer using a signing algorithm that Nessus either does not support or does not recognize.
 
In cryptography, X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates.[1] X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS,[2] the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures.
 
How it works:

Tenable SC attempts to connect to the target host's port using SSL and analyzes the certificate chain to determine if it can be trusted based on its known trusted certificate authorities.

^ also, not very helpful. 

Maybe it will provide more clarity to you than it did for me.

Thanks again.

Sincerely and Respectfully,

John

------------------------------
John MacDonald
----
Just another geek trying to figure things out.
------------------------------

Original Message:
Sent: Feb 20, 2025 06:15 PM
From: chulcher
Subject: ClearPass (6.11.10) failing ACAS scan

What are they testing against that they are getting the certificate?

Every certificate that ClearPass uses can be replaced, even the database replication certificates.  Of course, that means you then have to manage those certificate manually at that point.

------------------------------
Carson Hulcher, ACEX#110
------------------------------

Without knowing what port or service the finding was made against, not very helpful.

My response would be "prove to me that the self-signed certificate allows for insecure communications or otherwise makes for an insecure environment" before I spent much time on this.  As mentioned, self-signed certificates can be safely used for the database connection since that trust is strictly for intra-cluster communication.

------------------------------
Carson Hulcher, ACEX#110
------------------------------

Original Message:
Sent: Feb 24, 2025 10:21 AM
From: kcracker1987
Subject: ClearPass (6.11.10) failing ACAS scan

Thanks for the input, Carson.

This is all my security guys have given me:

51192:  SSL Certificate Cannot Be Trusted

Steps to Remediate
Purchase or generate a proper SSL certificate for this service.

OUTPUT:

The following certificate was at the top of the certificate
chain sent by the remote host, but it is signed by an unknown
certificate authority :

|-Subject : CN=<serverName>/O=PolicyManager
|-Issuer  : CN=<serverName>/O=PolicyManager

 

57582:  SSL Self-Signed Certificate

Steps to Remediate:
Purchase or generate a proper SSL certificate for this service.

OUTPUT:

The following certificate was found at the top of the certificate
chain sent by the remote host, but is self-signed and was not
found in the list of known certificate authorities :

|-Subject : CN=<ServerName>/O=PolicyManager

^ Not very helpful.

So, I asked for further information, and this is what they gave me (that I tried to abbreviate for simplicity in my original post):

When checking plugin 51192 in Tenable SC, the connection used is a secure socket layer (SSL) connection to the target host, as this plugin specifically detects and reports on untrusted SSL certificates, meaning it needs to establish an encrypted connection to the target port to analyze the certificate details.
 
This plugin examines the chain of X.509 certificates used by this service.
 
The server's X.509 certificate cannot be trusted. This situation can occur in three different ways, in which the chain of trust can be broken, as stated below :
 
- First, the top of the certificate chain sent by the server might not be descended from a known public certificate authority. This can occur either when the top of the chain is an unrecognized, self-signed certificate, or when intermediate certificates are missing that would connect the top of the certificate chain to a known public certificate authority.
 
- Second, the certificate chain may contain a certificate that is not valid at the time of the scan. This can occur either when the scan occurs before one of the certificate's 'notBefore' dates, or after one of the certificate's 'notAfter' dates.
 
- Third, the certificate chain may contain a signature that either didn't match the certificate's information or could not be verified. Bad signatures can be fixed by getting the certificate with the bad signature to be re-signed by its issuer. Signatures that could not be verified are the result of the certificate's issuer using a signing algorithm that Nessus either does not support or does not recognize.
 
In cryptography, X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates.[1] X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS,[2] the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures.
 
How it works:

Tenable SC attempts to connect to the target host's port using SSL and analyzes the certificate chain to determine if it can be trusted based on its known trusted certificate authorities.

^ also, not very helpful. 

Maybe it will provide more clarity to you than it did for me.

Thanks again.

Sincerely and Respectfully,

John

------------------------------
John MacDonald
----
Just another geek trying to figure things out.
------------------------------


Original Message:
Sent: Feb 20, 2025 06:15 PM
From: chulcher
Subject: ClearPass (6.11.10) failing ACAS scan

What are they testing against that they are getting the certificate?

Every certificate that ClearPass uses can be replaced, even the database replication certificates.  Of course, that means you then have to manage those certificate manually at that point.

------------------------------
Carson Hulcher, ACEX#110

If self-signed certificates are used in a closed system, for inter machine communication or not to be used by a wider range of (unmanaged/uncontrolled) clients, I don't see a reason why using those would be a problem.

One problem with these vulnerability scanners is that they can't understand the context in which a deployment is designed and working. Detections are generic, and may not be applicable in every context. It's a good tool to find possible problems, but a bad tool to blindly follow every detection.

As Carson mentioned, first find out what is the certificate that the scanner found; ClearPass has multiple.

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your HPE Aruba Networking partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact HPE Aruba Networking TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or HPE Aruba Networking.

In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
------------------------------

Thanks for your thoughts, Gents (@chulcher and @Herman Robers).

I really appreciate your input.

Currently, our ClearPass configuration is as follows:

• RADIUS/EAP: Privately issued certificate from an internal CA
• HTTPS (ECC): Disabled
• HTTPS (RSA): Public CA (DigiCert)
• RadSec: Same privately issued certificate as above
• Database Server: Self-signed certificate

Since the Tenable scan is largely a 'black box' to me, I don't have details beyond my original post about how it is performing the scan. The two issues identified are both related to the self-signed certificates.

My current hypothesis is:

1. ClearPass is configured to use the self-signed certificate for database replication.
2. The ACAS (Tenable) scanner is hitting those ports (5432/5433) and attempting to establish an SSL connection.
3. This is triggering the failure.

This is just a working theory. I'm looking for any suggestions that might help me secure the CPPM instances, so our security team will stop 'yelling' at me.

As it stands right now, the only solution I can think of is to replace the database certificates with our internal CA certificates. However, from my understanding, this carries a number of risks that I'm dreading.

Thanks again for any thoughts and for your time reading my rambling post.

Sincerely,

John

------------------------------
John MacDonald
----
Just another geek trying to figure things out.
------------------------------

I wouldn't bother replacing the database certificates and tell those persons running the security scan to exclude that particular finding from their report, or note as an exception and move on.

------------------------------
Carson Hulcher, ACEX#110
------------------------------

Original Message:
Sent: Feb 24, 2025 10:29 AM
From: kcracker1987
Subject: ClearPass (6.11.10) failing ACAS scan

Thanks for your thoughts, Gents (@chulcher and @Herman Robers).

I really appreciate your input.

Currently, our ClearPass configuration is as follows:

• RADIUS/EAP: Privately issued certificate from an internal CA
• HTTPS (ECC): Disabled
• HTTPS (RSA): Public CA (DigiCert)
• RadSec: Same privately issued certificate as above
• Database Server: Self-signed certificate

Since the Tenable scan is largely a 'black box' to me, I don't have details beyond my original post about how it is performing the scan. The two issues identified are both related to the self-signed certificates.

My current hypothesis is:

1. ClearPass is configured to use the self-signed certificate for database replication.
2. The ACAS (Tenable) scanner is hitting those ports (5432/5433) and attempting to establish an SSL connection.
3. This is triggering the failure.

This is just a working theory. I'm looking for any suggestions that might help me secure the CPPM instances, so our security team will stop 'yelling' at me.

As it stands right now, the only solution I can think of is to replace the database certificates with our internal CA certificates. However, from my understanding, this carries a number of risks that I'm dreading.

Thanks again for any thoughts and for your time reading my rambling post.

Sincerely,

John

------------------------------
John MacDonald
----
Just another geek trying to figure things out.
------------------------------

Honestly, I like where your head is at. I'll broach that idea with leadership.

This feels like a giant 'nothing' burger.

We had a oft repeated phrase back when I was working directly in the military: "If you want to make a computer completely unusable, apply all of the DISA STIGs."

Thanks again for your time and input.

------------------------------
John MacDonald
----
Just another geek trying to figure things out.
------------------------------

Original Message:
Sent: Feb 24, 2025 10:33 AM
From: chulcher
Subject: ClearPass (6.11.10) failing ACAS scan

I wouldn't bother replacing the database certificates and tell those persons running the security scan to exclude that particular finding from their report, or note as an exception and move on.

------------------------------
Carson Hulcher, ACEX#110
------------------------------


Original Message:
Sent: Feb 24, 2025 10:29 AM
From: kcracker1987
Subject: ClearPass (6.11.10) failing ACAS scan

Thanks for your thoughts, Gents (@chulcher and @Herman Robers).

I really appreciate your input.

Currently, our ClearPass configuration is as follows:

• RADIUS/EAP: Privately issued certificate from an internal CA
• HTTPS (ECC): Disabled
• HTTPS (RSA): Public CA (DigiCert)
• RadSec: Same privately issued certificate as above
• Database Server: Self-signed certificate

Since the Tenable scan is largely a 'black box' to me, I don't have details beyond my original post about how it is performing the scan. The two issues identified are both related to the self-signed certificates.

My current hypothesis is:

1. ClearPass is configured to use the self-signed certificate for database replication.
2. The ACAS (Tenable) scanner is hitting those ports (5432/5433) and attempting to establish an SSL connection.
3. This is triggering the failure.

This is just a working theory. I'm looking for any suggestions that might help me secure the CPPM instances, so our security team will stop 'yelling' at me.

As it stands right now, the only solution I can think of is to replace the database certificates with our internal CA certificates. However, from my understanding, this carries a number of risks that I'm dreading.

Thanks again for any thoughts and for your time reading my rambling post.

Sincerely,

John

------------------------------
John MacDonald
----
Just another geek trying to figure things out.

Just to close the loop.

It looks like we are going to be able to list this as an exception to the scanning. Currently our Azure hosted CPPM VAs have Network Security (firewall) rules in place that only allow the Tenable (ACAS) scanners and the two subnets associated with our CPPMs to communicate to the TCP ports used for database replication (5432 and 5433). Since we have that rule in place and all other traffic to those ports would be dropped, our Security folks have said that we can call them good. This is the draft mitigation statement that I provided our Security team for documentation:

The ClearPass Policy Manager cluster uses self-signed certificates to enable communications between the Publisher and Subscriber for database replication. The virtual appliances only present this certificate on TCP ports 5432 and 5433 for inter-device communications. Network security port rules are configured to allow communications on these ports from the Tenable SC scanner devices and the partner (publisher or subscriber) and block all other attempts to reach the ports.

Thanks again, Herman and Carson.

------------------------------
John MacDonald
----
Just another geek trying to figure things out.
------------------------------

Or, for S&Gs, modify that firewall policy to not allow the scan.  That'd also fix the issue.

------------------------------
Carson Hulcher, ACEX#110
------------------------------

Original Message:
Sent: Feb 24, 2025 02:00 PM
From: kcracker1987
Subject: ClearPass (6.11.10) failing ACAS scan

Just to close the loop.

It looks like we are going to be able to list this as an exception to the scanning. Currently our Azure hosted CPPM VAs have Network Security (firewall) rules in place that only allow the Tenable (ACAS) scanners and the two subnets associated with our CPPMs to communicate to the TCP ports used for database replication (5432 and 5433). Since we have that rule in place and all other traffic to those ports would be dropped, our Security folks have said that we can call them good. This is the draft mitigation statement that I provided our Security team for documentation:

The ClearPass Policy Manager cluster uses self-signed certificates to enable communications between the Publisher and Subscriber for database replication. The virtual appliances only present this certificate on TCP ports 5432 and 5433 for inter-device communications. Network security port rules are configured to allow communications on these ports from the Tenable SC scanner devices and the partner (publisher or subscriber) and block all other attempts to reach the ports.

Thanks again, Herman and Carson.

------------------------------
John MacDonald
----
Just another geek trying to figure things out.
------------------------------