Damans227 opened a new pull request, #13787:
URL: https://github.com/apache/cloudstack/pull/13787

   ### Description
   
   The root-ca plugin never checked that certificates were actually signed by 
the CloudStack root CA. `checkClientTrusted()` checked revocation, validity and 
SAN, but not the signature. `checkServerTrusted()` did nothing at all, so any 
server certificate was trusted. `isManagementCertificate()` trusted any cert 
with the right SAN, signed or not.
   
   This adds the missing signature check to all three, checked against every CA 
in the configured chain (so CA rotation still works). It's controlled by a new 
config key, `ca.plugin.root.ca.signature.verification`, off by default so 
upgrades are a no-op.
   
   For `checkClientTrusted`/`checkServerTrusted`, this follows the same pattern 
as the plugin's other checks: it only actually rejects a bad cert when 
`ca.plugin.root.auth.strictness` is also `true`. Otherwise it just logs. 
`isManagementCertificate` always enforces it once enabled, since it's not part 
of that strict/non-strict handshake logic.
   
   ### Types of changes
   
   - [x] Enhancement (improves an existing feature and functionality)
   
   ### Feature/Enhancement Scale or Bug Severity
   
   #### Feature/Enhancement Scale
   
   - [x] Minor
   
   ### How Has This Been Tested?
   
   Added unit tests for valid certs, certs signed by a rogue CA, certs signed 
by a non-primary CA in a rotated chain, and the no-CA-available case, in both 
strict and non-strict mode, across all three checks.
   
   #### How did you try to break this feature and the system with this change?
   
   Checked the flag defaults to off so nothing changes for existing 
deployments. Checked a cert signed by a different CA gets rejected once both 
flags are on. Checked CA rotation still works. Checked the missing-CA case 
doesn't throw an unhandled exception mid-handshake.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to