As part of ensuring secure communication in our company we are trying to export SMIME certificate issued by Digicert unto our clients but we encountered few issues with regards to private keys not included or exportable during the exportation process via the certmgr console.
Below is a Brief description of the error and the various troubleshooting attempts.
During the export i noticed the option to select Personal Information Exchange - PKCS #12 (.PFX) option was greyed out on the cert export wizard as seen in the screenshot below Certificate Export Wizard
I tried to troubleshoot the issue by first inspecting if there is a corresponding private key present for the imported certificate but as seen in the screenshot below there was none available. Certificate in Certmgr
I went further to try a repair job on the cert store by executing the certutil -repairstore my "serial" command in order fix in case the cert was corrupted but got the error below certutil repairstore error
As recommended in this Digicert article https://knowledge.digicert.com/solution/SO1335.html I tried to check permissions by opening each file in key container path C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys with Notepad in folders which corresponds to respective key containers. Access was denied as you can see in the message on screenshot below Machinekeys permission
I checked the permissions on the C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys folder and got the following results below icacls on Machinekeys folder Interesting enough the permissions on the folder kind of conforms with the required default permission recommended by Microsoft as documented here https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/default-permissions-machinekeys-folders
At this point, I am somewhat unsure about what actions to take. Could it be possible that the certificate was imported without an accompanying key? I don't believe so, as exporting the same certificate after copying it to another client yielded the expected results. Is it conceivable that the certificate has become corrupted or that access continues to be denied to the subfolders within the key containers? Interestingly, this scenario appears to be quite sporadic, as it functions correctly on certain clients in distinct locations. Might it be plausible that the functioning group are specific users or clients belonging to a particular group that possesses the necessary permissions locally on the client, on the network or on the domain? I would appreciate any hints or suggestions.
