scepman / install

SCEPman | Cloud-based Certification Authority
https://scepman.com/
8 stars 10 forks source link

Recently, client certs issued has 'Path Length Constraint' change from 'None' to '0' #11

Closed gokou88 closed 1 year ago

gokou88 commented 1 year ago

I'm currently using an Intune configuration profile to retrieve a client certificate from SCEPman community edition service. The certificate is being used by Pulse Secure VPN client for authentication. Recently (about last week), the certificate-based connection has been denied. The log entry for the Pulse client is

"'JamCertLib' Certificate 666FE530B1F53000FB5CC0E477A08D0054A62F36 does not meet the required 'has no path length constraint' condition, skipping it (rank 0)."

In checking the latest issued client cert versus a cert that worked from last month, the Path Length Constraint field under Basic Constraints has changed from None to 0. I believe this is the cause of the failure. Is there anyway I can change the parameter back to None for newly issued certificates?

gokou88 commented 1 year ago

Also, am I correct in stating that since the client certificate is an "End Entity" certificate, the Path Length Constraint should be set to None rather than 0.

bb-froggy commented 1 year ago

Sorry for not answering for almost three weeks. This repository wasn't in my watch list. You can get fast responses via a support ticket (https://www.scepman.com/help/) where there are more people to see the ticket. Many customers praise the quality of the SCEPman support and say that we respond very quickly and take customer feedback to heart :-). This is also the correct way to report this, since the issue seems not to be related to the installation of SCEPman, but its operations. This repository is just about getting the Azure resources set up.

Apart from that, I also believe that "None" is the better value, but it probably doesn't matter if it is declared as an end entity certificate. I would have to read the RFC again to be sure about the expected behavior. Anyway, if the certificate is distributed via Intune, then it is likely Intune that adds the Basic Constraints extension, not SCEPman.

bb-froggy commented 1 year ago

You are right, it must be "None" as per RFC 5280, Section 4.2.1.9, where it says:

CAs MUST NOT include the pathLenConstraint field unless the cA boolean is asserted and the key usage extension asserts the keyCertSign bit.

Thus, Intune seems to request an invalid BasicConstraints extension in its newer versions. SCEPman should detect and correct that. This will go into the upcoming 2.3 version.

bb-froggy commented 1 year ago

SCEPman 2.3.695 in Internal Channel has fixed this. The BasicConstraints now correctly has no pathLenConstraint for issued end-entity certificates. This change will move to Beta and Productions channels in the next days and weeks.