Assistance with eHTTP Certificates and Spoofing/Forging

[NullSID]

Hi Folks!

I'm working with a customer that has an SCCM environment, (2309). Currently setup as eHTTP. We are working through the logistics with Security on setting up a CMG, but on a side note they've asked some questions that I'm not 100% positive how to answer. The first question being: "How do the Self Signed Certs protect against spoofing/forging?"

My assumption is that the signing certificate on the client validates the policies sent from the MP were not tampered with in any way. Then the encryption certificate establishes the secure connection from the client to the MP or MP to DP etc.

So you would have to compromise the signing certificate either through Phishing or Man in the Middle attack, and redirect it to a malicious SCCM infrastructure.

I'm a little fuzzy on the intricacies of Self Signed certificates and how they work within CM when it comes to this.

In light of not publishing the CRL list, they want to know if using a public cert for the entire CM infrastructure is a possibility? 

Can anyone help shed some light on this topic?

 

 

[anyweb]

I asked Copilot ! and here is what it said, quite interesting

In System Center Configuration Manager (SCCM) version 2309, self-signed certificates play a crucial role in securing communication between various components. Let me break it down for you:

1. Signing Certificate:

   • The signing certificate on the client validates that policies sent from the Management Point (MP) were not tampered with.
   • It ensures that the policies received by the client are authentic and haven’t been modified during transmission.

2. Encryption Certificate:

   • The encryption certificate establishes a secure connection between the client and various SCCM components (e.g., MP, Distribution Point).
   • It ensures that data exchanged during communication remains confidential and cannot be intercepted or altered.

3. Protection Mechanism:

   • To compromise the self-signed certificates, an attacker would need to:
     • Phish or perform a Man-in-the-Middle (MitM) attack to intercept the signing certificate.
     • Redirect the client to a malicious SCCM infrastructure.
   • By doing so, they could potentially manipulate policies or gain unauthorized access.

4. Public Certificates:

   • While self-signed certificates are commonly used within SCCM, using a public certificate for the entire SCCM infrastructure is indeed a possibility.
   • However, this approach requires additional configuration and coordination with your organization’s security team.

In summary, self-signed certificates protect against spoofing and forging by ensuring policy integrity and establishing secure connections. If you’re considering public certificates, consult with your security team to evaluate the trade-offs and implementation details¹².

 

[NullSID]

On 6/6/2024 at 5:20 PM, anyweb said:

I asked Copilot ! and here is what it said, quite interesting

In System Center Configuration Manager (SCCM) version 2309, self-signed certificates play a crucial role in securing communication between various components. Let me break it down for you:

1. Signing Certificate:

   • The signing certificate on the client validates that policies sent from the Management Point (MP) were not tampered with.
   • It ensures that the policies received by the client are authentic and haven’t been modified during transmission.

2. Encryption Certificate:

   • The encryption certificate establishes a secure connection between the client and various SCCM components (e.g., MP, Distribution Point).
   • It ensures that data exchanged during communication remains confidential and cannot be intercepted or altered.

3. Protection Mechanism:

   • To compromise the self-signed certificates, an attacker would need to:
     • Phish or perform a Man-in-the-Middle (MitM) attack to intercept the signing certificate.
     • Redirect the client to a malicious SCCM infrastructure.
   • By doing so, they could potentially manipulate policies or gain unauthorized access.

4. Public Certificates:

   • While self-signed certificates are commonly used within SCCM, using a public certificate for the entire SCCM infrastructure is indeed a possibility.
   • However, this approach requires additional configuration and coordination with your organization’s security team.

In summary, self-signed certificates protect against spoofing and forging by ensuring policy integrity and establishing secure connections. If you’re considering public certificates, consult with your security team to evaluate the trade-offs and implementation details¹².

 

Thanks for that. I wanted to validate this as it well similar to what Gemini gave me. I like having my ducks in a row so I don't present the wrong info. Appreciate the assistance.