0

I am seeking clarification from anyone who is familiar with ADCS.

In reviewing the AD Object details, I am trying to understand why I am seeing 3DES in the application policy section of the certificate.

Specifically this property: > sPKI-Symmetric-AlgorithmPZPWSTR3DES`

Steps to product this:

  • Windows 2022 Server, ADCS services
  • Template duplicated from web server default

Extract the AD object for review

ldifde -m -v -d “CN=customwebserver,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=AD,DC=ORGDOMAIN,DC=TLD” -f customwebserver.ldf

Here is the Object reported

dn: CN=ORGWebServer,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=AD,DC=ORG,DC=TLD
changetype: add
cn: ORGWebServer
displayName: ORG Web Server
distinguishedName: 
 CN=ORGWebServer,CN=Certificate Templates,CN=Public Key Services,CN=S
 ervices,CN=Configuration,DC=AD,DC=ORG,DC=TLD
dSCorePropagationData: 20230506203143.0Z
dSCorePropagationData: 16010101000000.0Z
flags: 131649
instanceType: 4
msPKI-Cert-Template-OID: 
 1.3.6.1.4.1.311.21.8.8801485.870485.13651088.9531739.7367544.199.12269436.1006
 0170
msPKI-Certificate-Application-Policy: 1.3.6.1.5.5.7.3.1
msPKI-Certificate-Name-Flag: 1
msPKI-Enrollment-Flag: 0
msPKI-Minimal-Key-Size: 2048
msPKI-Private-Key-Flag: 101056528
msPKI-RA-Application-Policies: 
 msPKI-Asymmetric-Algorithm`PZPWSTR`RSA`msPKI-Hash-Algorithm`PZPWSTR`SHA256`msP
 KI-Key-Usage`DWORD`16777215`msPKI-Symmetric-Algorithm`PZPWSTR`3DES`msPKI-Symme
 tric-Key-Length`DWORD`168`
msPKI-RA-Signature: 0
msPKI-Supersede-Templates: WebServer
msPKI-Template-Minor-Revision: 34
msPKI-Template-Schema-Version: 4
name: ORGWebServer
objectCategory: 
 CN=PKI-Certificate-Template,CN=Schema,CN=Configuration,DC=AD,DC=ORG,
 DC=TLD
objectClass: top
objectClass: pKICertificateTemplate
pKICriticalExtensions: 2.5.29.15
pKIDefaultKeySpec: 1
pKIExpirationPeriod:: AEAepOhl+v8=
pKIExtendedKeyUsage: 1.3.6.1.5.5.7.3.1
pKIKeyUsage:: oAA=
pKIMaxIssuingDepth: 0
pKIOverlapPeriod:: AICmCv/e//8=
revision: 100
showInAdvancedViewOnly: TRUE
uSNChanged: 386490
uSNCreated: 14307
whenChanged: 20230506203143.0Z
whenCreated: 20220307012740.0Z

It looks to me like the session is using 3DES instead of something like AES256?

Application Policy Client Auth ALG

Has anyone ever seen or paid attention to this before?

I can't Google hard enough yet to determine if 'msPKI-Symmetric-Algorithm' is only for the exchange process, key archival between a certificate requesting machine and the certificate server, or the data protection between two the two hosts using this certificate.

I would love some insight, thanks for your time.

Update

Maybe I answer my own question, but this is the best source of information I can find:

msPKI-Symmetric-Algorithm: If this property type is present, the client MUST use the algorithm specified in this property to encrypt the private key corresponding to the public key in the request while generating the key archival enrollment request, as specified in sectioLooks to me that this only matters if the certificate being enrolled in is going to archive the key.

Still, is it a best practice to allow a private key to be sent to the CA only encrypted in 3DES?

I thought I'd change the values to AES and 256 to see if it breaks or not.

Still interesting that this is the default.n 1.3.2.1. In addition, the client SHOULD use this algorithm to encrypt the Client_HardwareKeyInfo ADM element as described in section 3.1.1.4.3.4.1.1.<45> If this property type is not present, clients MAY choose defaults based on local policy.<46>

from the Protocol Documentation: https://view.officeapps.live.com/op/view.aspx?src=https%3A%2F%2Fwinprotocoldoc.blob.core.windows.net%2Fproductionwindowsarchives%2FMS-WCCE%2F%255BMS-WCCE%255D-210625.docx&wdOrigin=BROWSELINK

Improve this question
New contributor
Cory Candia is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
0

1 Answer 1

Reset to default
0

This property is used only when key archival is enabled for certificate template and defines the symmetric key used to encrypt and store private key in CSR. There are only two scenarios when you ever use key archival:

  1. Email encryption certificate template
  2. EFS certificate template

There are no other practical reasons to use key archival. So in your particular case, you can safely ignore these algorithms, because they are not used.

You can safely update 3DES to AES256 without problems. 3DES is the default to make it compatible with Windows Server 2003-based CAs which do not support AES. Keep in mind that if you change 3DES to AES256, you need to update msPKI-Symmetric-Key-Length attribute as well to 256.

Improve this answer
4
  • I find it very interesting that this option doesn't seem to be exposed in the GUI that I have been able to find. I've been working with my internal CAs for a while, but only found this when I wanted to extract the templates for documentation/scripting.
    – Cory Candia
    22 hours ago
  • The only thing they expose is 'Use advanced Symmetric algorithm to send the key to the CA'. It doesn't say: "We'll use 3DES unless you check this box". Frustrating since we use smartcards & email encryption.
    – Cory Candia
    22 hours ago
  • do you have opinions on recovery agents vs private key restore? I've heard internet people say you don't have to worry about a recovery agent when you can just restore the terminated person's private key and decrypt their stuff. I guess it's a form of sanctioned impersonation. Probably in a perfect world, you'd rather have auditing of organization directed administrator recovery (recovery agent)?
    – Cory Candia
    22 hours ago
  • when you can just restore the terminated person's private key in that case there is obviously no need for a separate recovery agent. A recovery agent is for when there is not access to the private key.
    – Greg Askew
    21 hours ago

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .