Hello,
I'm not sure this is the right place to make a feature request... Please excuse me if it is not.
I would like to be able to manage the security settings of the CA through PowerShell (setting CA administrators, certificate managers, etc.).
I think I saw a thread on technet where Brian Komar or yourself said that it was possible to do so with `certutil -setreg ca\security` but the format to use was not specified (and I'd guess it would require some SDDL...).
What I imagine is new cmdlets with signatures similar to the following:
```
Get-CASecurityAcl [-CertificationAuthority] <CertificateAuthority[]> [<CommonParameters>]
Add-CASecurityAcl [-InputObject] <SecurityDescriptor[]> [[-User] <NTAccount[]>] [[-AccessType] <AccessControlType>] [[-AccessMask] <CARight[]>] [<CommonParameters>]
Set-CASecurityAcl [-InputObject] <SecurityDescriptor[]> [<CommonParameters>]
Remove-CASecurityAcl [-InputObject] <SecurityDescriptor[]> [[-User] <NTAccount[]>] [[-AccessType] <AccessControlType>] [<CommonParameters>]
```
And a new CARight enum that would contain something like `Read`, `ManageCA`, `IssueManageCertificates` and `RequestCertificates`.
While I'm at it, it would also be interesting to have:
* wrappers around other `certutil -setreg` commands like being able to enable/disable role separation, configure restrictions for certificate managers and enrollment agents, audit filters, etc.
* get "resolved" AIA and CDP URLs (with placeholders resolved to their actual values for each CA certificates in use)
* edit certificate templates' settings (which would probably require modifying the template objects in AD directly...)
* Allow retrieving issued and revoked certificate requests all in one command (which should be possible if the internal Get-RequestRow cmdlet was refactored/made public and the filter on `Disposition` removed). Not sure it is possible to return pending/failed requests in one request though...
Whether you implement any of those proposals, thank you very much for making administrating AD CS with PowerShell so easy! Microsoft should definitely consider including your module natively in the OS to complement the too simple existing cmdlets.
Best regards,
Jordan
Comments: > They can't really expect sysadmins to be versatile in low-level C API main argument of PKI team in this question is performance. They always recommend to use native code (C++) when you want to do something with PKI. I understand why it is reasonable for example, in policy or exit modules, but can't stand with this argument when you do reporting or occasional configuration change, where 10ms in managed code or 1ms in unmanaged code makes no difference. Moreover, .NET team do not pay enough attention in managed cryptography. There is no yet a default classes to represent X.509 CRL, CTL objects, OCSP-related stuff and so on. One of the common task -- read certificate requests. The same thing. Moreover, when I started PKCS#7 certificate request managed implementation I found that PKCS namespace in .NET doesn't help at all, I was forced to write my own classes to decode PKCS#7 messages and unroll contained request. Almost everything exist in native C++ functions, but they are too complex. > And probably even better, the possibility to not pass a certificate object at all to the command but instead a CA object for what reason? With certutil -verify you are verifying the certificate, not CA object. Maybe you are talking about PKIView.msc, which do checks CA files (certs, CRLs and OCSP)?
I'm not sure this is the right place to make a feature request... Please excuse me if it is not.
I would like to be able to manage the security settings of the CA through PowerShell (setting CA administrators, certificate managers, etc.).
I think I saw a thread on technet where Brian Komar or yourself said that it was possible to do so with `certutil -setreg ca\security` but the format to use was not specified (and I'd guess it would require some SDDL...).
What I imagine is new cmdlets with signatures similar to the following:
```
Get-CASecurityAcl [-CertificationAuthority] <CertificateAuthority[]> [<CommonParameters>]
Add-CASecurityAcl [-InputObject] <SecurityDescriptor[]> [[-User] <NTAccount[]>] [[-AccessType] <AccessControlType>] [[-AccessMask] <CARight[]>] [<CommonParameters>]
Set-CASecurityAcl [-InputObject] <SecurityDescriptor[]> [<CommonParameters>]
Remove-CASecurityAcl [-InputObject] <SecurityDescriptor[]> [[-User] <NTAccount[]>] [[-AccessType] <AccessControlType>] [<CommonParameters>]
```
And a new CARight enum that would contain something like `Read`, `ManageCA`, `IssueManageCertificates` and `RequestCertificates`.
While I'm at it, it would also be interesting to have:
* wrappers around other `certutil -setreg` commands like being able to enable/disable role separation, configure restrictions for certificate managers and enrollment agents, audit filters, etc.
* get "resolved" AIA and CDP URLs (with placeholders resolved to their actual values for each CA certificates in use)
* edit certificate templates' settings (which would probably require modifying the template objects in AD directly...)
* Allow retrieving issued and revoked certificate requests all in one command (which should be possible if the internal Get-RequestRow cmdlet was refactored/made public and the filter on `Disposition` removed). Not sure it is possible to return pending/failed requests in one request though...
Whether you implement any of those proposals, thank you very much for making administrating AD CS with PowerShell so easy! Microsoft should definitely consider including your module natively in the OS to complement the too simple existing cmdlets.
Best regards,
Jordan
Comments: > They can't really expect sysadmins to be versatile in low-level C API main argument of PKI team in this question is performance. They always recommend to use native code (C++) when you want to do something with PKI. I understand why it is reasonable for example, in policy or exit modules, but can't stand with this argument when you do reporting or occasional configuration change, where 10ms in managed code or 1ms in unmanaged code makes no difference. Moreover, .NET team do not pay enough attention in managed cryptography. There is no yet a default classes to represent X.509 CRL, CTL objects, OCSP-related stuff and so on. One of the common task -- read certificate requests. The same thing. Moreover, when I started PKCS#7 certificate request managed implementation I found that PKCS namespace in .NET doesn't help at all, I was forced to write my own classes to decode PKCS#7 messages and unroll contained request. Almost everything exist in native C++ functions, but they are too complex. > And probably even better, the possibility to not pass a certificate object at all to the command but instead a CA object for what reason? With certutil -verify you are verifying the certificate, not CA object. Maybe you are talking about PKIView.msc, which do checks CA files (certs, CRLs and OCSP)?