Hi All,

I am running into an issue with NDES / SCCM Intune Certificate Provisioning.

My iOS device can successfully receive the Root CA payload, and the Wireless Profile. However, the SCEP certificate is not being issued to the device.

When I look in the logs on the NDES server (NDES.log), i see the following lines

<![LOG[Failed to retrieve client certificate. Error -2147467259]LOG]!><time="20:48:44.215+00" date="08-17-2015" component="NDESPlugin" context="" type="3" thread="4064" file="httprequest.cpp:240"><![LOG[Exiting VerifyRequest with 0x80004005]LOG]!><time="20:48:44.215+00" date="08-17-2015" component="NDESPlugin" context="" type="1" thread="4064" file="ndesplugin.cpp:874">

The NDES server is able to communicate with the CA, and the client is able to successfully hit the external DNS name of the NDES server on port 443.

The whole process seems to be working just fine except for the SCEP cert generation to the client.

I have verified that the CRP on the SCCM server logs are clean and all show expected results.

The NDES user is a local admin on the NDES server and I have verified that the Application Pool identity references the NDES user.

Any idea what is going on here?

TIA!

Hi,

where can I download on the MS site the up-to-date security tools & security templates, etc. for Windows Server 2016 hardening (DCs, Member Servers, SQL, Exchange, etc.)?

Best regards

Birdal

Hello everyone,

First: Iam fully aware that these is not best practise or anything near it.

We enroll certificates for our users and have implemented certificate roaming. Our Users work on terminalservers. Everything works fine. Our Users have no access to mmc powershell local drives.

No the problem. We have an mail appliance what does the mail encyrption. The mailserver (no exchange) sending mails to this appliance and the mail will signed with the private key of the user. For this reason the appliance need the privatekeys of the users.

My task is now to extract the certificats of the users "somehow" out of there profile. I am not really aware of how to do this. Maybe with a startscript certutil... maybe I can extract it somehow out of active directory (but I guess its protected somehow).

If anyone has an idea how to do this... For every answer i would be grateful :=)

Best regards Andreas Ernst MCITP:EA, MCP, MCTS, MCSA 2016

Hi,

I have a invalid location for Delta CRLs in my configuration. How can I remove it?

-ae

I am the administrator of a small non-profit using Server 2012R2 essentials on a single server.  We use RRAS and NPS to allow an L2TP tunnel to be established for a remote location and for administration.  We are currently being dinged by a PCI-DCC scan for 3DES and Diffie Hellman group 2 on UDP port 500.  I have made the following registry changes and restarted the server:

1.   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers key to disable 3DES and all of the other lesser ciphers,

2.   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman key to set serverminbitkeylength to 800.  

When I run the IKE-Scan tool against port 500, it continues to show SA=(Enc=3DES Hash=SHA1 Group=2:modp1024.  

How do I completely disable/remove 3DES from this server and set the DH Group to 14 or higher so that 2 of the 3 errors I am being dinged for go away?

Thanks in advance

Hello Folks,

I have a quick query, under the location:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults\Provider, for a crypto provider, what doesType Dword signify, for example, one of the crypto providers holds the value for Type as 1 and some 18 and 24.

If I modify the value will this going to affect in any way?

Hi,

I have been unable to find this online. Can we add a Subordinate CA server running Windows Server 2012 R2 to an existing AD CS infrastructure that is a Windows Server 2008 R2 Root CA?

Hi,

I have been unable to find this online. Can we add a Subordinate CA server running Windows Server 2012 R2 to an existing AD CS infrastructure that is a Windows Server 2008 R2 Root CA?

Hi,

I have servers with warning that a certificate will expire.  I believe every year, this machine auto-renews, but how do I confirm that because I don't remember now and I couldn't find my past documentation?

I looked at the expiring certificate and it is using a COMPUTER TEMPLATE.  When I look at my CA Server Security Tab -> Enroll is checked for Domain Computers (see picture below).  Does this mean it will auto-enroll?  This setting has been like this for many years and this setting must be the reason that this specific MACHINE Certificate will auto-renew but I need confirmation from someone who understands it better :) 

28 Jan 2019 07:53:38 PM   

Computer: [Exchange Server]   

Description:    

* Event Time: 28 Jan 2019 06:53:48 PM   

* Source: MSExchange Web Services   

* Event Log: Application   

* Type: Warning   

* Event ID: 26   

* Event User: N/A   

* The Exchange certificate [Subject]   

  CN=Exchange.domain.com

[Issuer]   

  CN=LocalCertificateServer, DC=Domain, DC=Com    

[Serial Number]   

  XXXXX    

[Not Before]   

  3/27/2018 8:01:04 AM   

[Not After]   

  3/27/2019 8:01:04 AM   

[Thumbprint]   

Hi,

How can I set lsass process SACL in windows 2008 using command line?

Thanks

How to update security and cumulative  update of windows server 2016 . without internet  what means by some CVE like below how to resolve the vulnerability.

Hello,

I'm trying to implement DocRecrypt ability for all of our client computers in the event we need to unlock a password protected Office file. More documentation here:
https://docs.microsoft.com/en-us/deployoffice/security/remove-or-reset-file-passwords-in-office

So my steps have been the following:

-Install Office Security Administrative Template GPOs on domain controller.

-Create User certificate on domain controller under Administrator account.
-Created a GPO with Escrow Key #1 enabled and assigned the thumbprint of the User certificate that I created.
-Linked this GPO to my domain and forced update to all client computers

-Created a password protected test file on client computer. Moved it to domain controller and tried to un-protect using DocRecrypt.

Unfortunately, it doesn't seem like this certificate is being applied to new password protected documents on the client machine as DocRecrypt says no certificate found. Either that or it somehow can't find the certificate on the domain controller. Any ideas what I might be doing wrong here?

Since I installed the new administrative templates on the domain controller, is the issue that these templates need to be installed on the client machines as well to function once they pull from the GPO? Is there a way to remotely install these new templates to all client computers or would I have to do this manually if this is indeed the issue?

Hi all,

As you might know, when creating a failover cluster, Windows Server 2016 generates a self-signed certificate and installs it to all nodes. 

Because these certificates expire in one year, we got monitoring alerts. To fix these alerts some certificates were removed from the cluster nodes. Since then, we've been unable to add new cluster nodes to the cluster due to schannel issues. I'm suspecting the removal of the cluster certificates to be the cause. 

Is there any way to renew or replace failover cluster certificates? I cannot find a thing on Google about this, only that Windows Server 2016 uses certificates for failover clustering. 

Hi, wondering if anyone is using Bitlocker volume encryption with Microsoft PKI implementation in a non-AD environment? I have it setup but we keep getting a 0x80310072 error "Group Policy does not permit user certificates, such as smart cards, to be used with BitLocker." every time I try to make an encrypted volume specifying a valid certificate. I tried using both a computer and user certificate and ensured they are in the recovery tool as well. 

manage-bde -on D: -cert -cf $filename.cer

Am I missing a local group policy setting or some other requirement? 

I have SCEP configured:

which works perfectly fine. Updates are downloaded by scheduled task to share daily, clients update from this share on schedule

Polices apply fine & show correctly in

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Policies\Microsoft\Microsoft Antimalware\Signature Updates

FallbackOrder = FileShares|MicrosoftUpdateServer|InternalDefinitionUpdateServer

But if the user takes laptop home the updates do not happen. Of course they would not happen from the share (as it is not accessible), but SHOULD happen directly from MS site

I can even try to force manual update from GUI, it always error out the same.

MpCmdRun: Command Line: "C:\ProgramData\Microsoft\Windows Defender\platform\4.18.1807.18075-0\MpCmdRun.exe" SignaturesUpdateService -UnmanagedUpdate
 Start Time: ?Sun ?Aug ?19 ?2018 14:36:21

MpEnsureProcessMitigationPolicy: hr = 0x0
Start: Signatures Update Service
Update Started
Search Started (MU/WU update) (Path: https://fe2.update.microsoft.com/v6/)...
Search Completed 
Update failed with hr: 0x80072f8f
Update completed with hr: 0x80072f8f
End: Signatures Update Service
MpCmdRun: End Time: ?Sun ?Aug ?19 ?2018 14:36:23

But I can download the full signatures mpam-fe.exe and run it (as the very user) and it updates fine

Something is just odd, any ideas anybody?

Seb

(I asked the following question in the Server forum, someone suggested asking in this forum instead...)

I need help with a lot of registry warnings on my Server 2012 R2 domain controller, 3 per day, all the same, sample below. Can anyone help me resolve this issue?

Registry entry sample:

Log: Application
Source: CertificateServicesClient-AutoEnrollment
Event ID: 64
Description: Certificate for local system with Thumbprint _____ is about to expire or already expired. (Thumbprint removed for security purposes.)
Provider:
   [ Name]  Microsoft-Windows-CertificateServicesClient-AutoEnrollment 
   [ Guid]  {F0DB7EF8-B6F3-4005-9937-FEB77B9E1B43} 
   [ EventSourceName]  AutoEnrollment 

I started scanning my cert store for likely certs w/o success, then resorted to a full powershell dump to a text file and still couldn't find a cert with a matching thumbprint. My powershell script is:

cd CERT:\\
ls . -Recurse

I got nearly 1300 lines of output (i.e. zillions of certs), but the thumbprint in the registry warning is not listed.

Hi

I have certificate authority ( Root + issuer + subordinate server) based on win server 2008

i will upgrade the certificate authority server 2008 to 2016 , Then i have to migrate sha1 to sha2

i need the steps to do that please.

are there any risk for the old issued certificates with sha1 after upgrade process?

shall i uograde my domain controllers which has CA installed to 2016 then decommission old DCs 2008 and migrate CA sha1 to sha2 ??? or start migrate sha1 to sha2 on old DC 2008 and after that migrate my DC with CA from 2008 to 2016 ?

MCP MCSA MCSE MCT MCTS CCNA

Hello

I have a problem with a variety of CA hierarchies and certificate path validation on Windows Server 2016 where the Issuing CA and End Entity (leaf) certificate contain customised certificate/issuance policies. First up, it is necessary to note that on Windows Server 2019, Windows Server 2012 R2, Windows Server 2008 R2 and Windows 10 Pro (1803), these certificate path validation issues DO NOT occur.

To set the scene, I will use as an example one of the CA hierarchies and provide CAPolicy.inf examples for the Root CA and Issuing CA.

Root CA CAPolicy.inf

[Version] 
Signature="$Windows NT$"

[PolicyStatementExtension] 
Policies=CPS

[CPS] 
OID=2.5.29.32.0
Notice="This CA issues certificates in accordance with the ACME Certificate Policy (CP) which may be viewed at http://pki.acme.com"
URL=http://pki.acme.com/doc/certpolicy.pdf

[Certsrv_Server] 
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
AlternateSignatureAlgorithm=0
CRLDeltaPeriod=Days
CRLDeltaPeriodUnits=0

Issuing CA CAPolicy.inf

[Version]
Signature="$Windows NT$"

[PolicyStatementExtension]
Policies=CPS,BasicAssurance,MediumAssurance,HighAssurance
Critical=0

[CPS]
OID=1.3.6.1.4.1.12345.509.2
Notice="This CA issues certificates in accordance with the ACME Certificate Policy (CP) which may be viewed at http://pki.acme.com"
URL=http://pki.acme.com/doc/certpolicy.pdf

[BasicAssurance]
OID=1.3.6.1.4.1.12345.509.2.2

[MediumAssurance]
OID=1.3.6.1.4.1.12345.509.2.3

[HighAssurance]
OID=1.3.6.1.4.1.12345.509.2.4

[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=5
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=0

As a further example, here is a 'certutil -dump' of a sample End Entity (leaf) certificate:

X509 Certificate:
Version: 3
Serial Number: 330000000440f4cb878b18a8ce000000000004
Signature Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.11 sha256RSA
    Algorithm Parameters:
    05 00
Issuer:
    CN=ACME Issuing CA
    O=ACME
    C=COM
  Name Hash(sha1): 74609145bc39cad8598a403cb134b63da138f84e
  Name Hash(md5): e61e39e5344e4869b7c857666cc429d8

 NotBefore: 01/02/2019 09:58
 NotAfter: 01/02/2020 09:58

Subject:
    CN=ACME Test User
  Name Hash(sha1): 375d1aa5d8f2b95afb306e67ad3344303e4a31d7
  Name Hash(md5): 87377cfe61a09345596953976f50e828

Public Key Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.1 RSA
    Algorithm Parameters:
    05 00
Public Key Length: 2048 bits
Public Key: UnusedBits = 0
    0000  30 82 01 0a 02 82 01 01  00 ac 9b fa 3d f7 cf 93
    0010  1b 5c 1c 4a 2e d9 50 95  e5 78 0e c5 31 ad c4 70
    0020  24 86 73 c8 2a 43 a0 12  cb b1 75 68 6c 82 a4 e8
    0030  8b 91 d3 ac 20 e1 e7 e5  3c 91 9b 6c 87 ef 30 45
    0040  d1 73 af ad 5a 1a 89 b7  32 f6 35 80 3c d0 72 ed
    0050  75 ad ff dd 48 17 8c fb  f2 05 fa db 2b 82 1e 6e
    0060  a5 61 61 10 7c 07 38 38  7d 05 ce 1f 49 ea 5d fe
    0070  cf cb 8b ec 94 8d 18 11  ec 3f 61 d0 5b 9a 0a e4
    0080  87 f6 81 48 ef 21 01 71  f7 a2 d7 2b 77 a5 8f 07
    0090  89 a6 d4 16 57 78 e7 0a  11 12 5b 03 dd fd b7 df
    00a0  60 30 96 b2 f5 5f 5b 58  3b 9d 7a cd e9 28 87 56
    00b0  8f be e1 aa 84 0b df 00  f7 43 3a f6 0d 07 60 ac
    00c0  08 f1 31 fa 9d df 17 80  18 6d e3 29 1d 1f b4 08
    00d0  e5 f3 53 6a e9 44 7c c1  2c cd 56 c3 a5 aa ce a4
    00e0  1b 97 63 28 f5 90 ea 0d  e2 27 ab 26 3c 2e ab 64
    00f0  d2 64 6e 24 c3 ec 6f b4  16 73 c7 5b fc 66 e5 5e
    0100  c0 5e 57 ec 95 b3 9b 32  55 02 03 01 00 01
Certificate Extensions: 10
    1.3.6.1.4.1.311.21.7: Flags = 0, Length = 30
    Certificate Template Information
        Template=1.3.6.1.4.1.311.21.8.11936801.7620917.2376341.5310192.8755573.76.11438511.8040194
        Major Version Number=100
        Minor Version Number=11

    2.5.29.37: Flags = 0, Length = 22
    Enhanced Key Usage
        Encrypting File System (1.3.6.1.4.1.311.10.3.4)
        Secure Email (1.3.6.1.5.5.7.3.4)
        Client Authentication (1.3.6.1.5.5.7.3.2)

    2.5.29.15: Flags = 1(Critical), Length = 4
    Key Usage
        Digital Signature, Key Encipherment (a0)

    2.5.29.32: Flags = 0, Length = 21
    Certificate Policies
        [1]Certificate Policy:
             Policy Identifier=1.3.6.1.4.1.12345.509.2
        [2]Certificate Policy:
             Policy Identifier=1.3.6.1.4.1.12345.509.2.4

    1.3.6.1.4.1.311.21.10: Flags = 0, Length = 28
    Application Policies
        [1]Application Certificate Policy:
             Policy Identifier=Encrypting File System
        [2]Application Certificate Policy:
             Policy Identifier=Secure Email
        [3]Application Certificate Policy:
             Policy Identifier=Client Authentication

    1.2.840.113549.1.9.15: Flags = 0, Length = 37
    SMIME Capabilities
        [1]SMIME Capability
             Object ID=1.2.840.113549.3.2
             Parameters=02 02 00 80
        [2]SMIME Capability
             Object ID=1.2.840.113549.3.4
             Parameters=02 02 00 80
        [3]SMIME Capability
             Object ID=1.3.14.3.2.7
        [4]SMIME Capability
             Object ID=1.2.840.113549.3.7

    2.5.29.14: Flags = 0, Length = 16
    Subject Key Identifier
        5c 02 21 d3 b2 3c a4 a3 4e d8 52 46 75 c6 65 b8 32 96 b3 83

    2.5.29.35: Flags = 0, Length = 18
    Authority Key Identifier
        KeyID=82 2f 78 de b4 27 25 82 3c 70 ec 4c b7 eb 48 25 b1 14 e4 6a

    2.5.29.31: Flags = 0, Length = 5c
    CRL Distribution Points
        [1]CRL Distribution Point
             Distribution Point Name:
                  Full Name:
                       URL=http://pki.acme.com/pki/ACME Issuing CA.crl (http://pki.acme.com/pki/ACME%20Issuing%20CA.crl)

    1.3.6.1.5.5.7.1.1: Flags = 0, Length = 62
    Authority Information Access
        [1]Authority Information Access
             Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
             Alternative Name:
                  URL=http://pki.acme.com/pki/ACME Issuing CA.crt (http://pki.acme.com/pki/ACME%20Issuing%20CA.crt)

Signature Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.11 sha256RSA
    Algorithm Parameters:
    05 00
Signature: UnusedBits=0
    0000  87 a7 13 2e a5 d8 87 6f  fe 30 15 02 0f c7 88 0f
    0010  43 07 95 a8 b9 45 7b 49  1f d6 78 25 e9 63 a9 6a
    0020  f4 43 70 db b7 5b f5 a3  34 51 7a ff 50 e7 4e bf
    0030  5e fa 75 98 7e 85 3b d2  01 6f d9 aa be 08 a2 e3
    0040  9b 73 64 91 11 75 0a 8b  cf 2e 50 4a 88 34 b5 e1
    0050  43 05 27 49 a1 92 a2 f5  38 b8 81 c5 54 d9 0e 34
    0060  61 07 4e c6 25 b7 52 0d  a1 c9 65 67 b7 a0 2d 40
    0070  f3 5b e6 6e 86 62 97 25  28 83 85 0e 65 46 5b 67
    0080  9c 69 cb 05 d8 0a 04 7d  1b 69 74 64 96 87 5f 69
    0090  4c 9d e6 08 a9 35 05 3f  2b 3b 5c 50 47 db b2 cf
    00a0  1d 83 23 1a e7 33 ab 63  e1 60 cd c3 c9 a9 6a 08
    00b0  17 be a2 4d 6e f0 ae 63  24 f6 b5 62 13 49 66 e2
    00c0  63 b2 a1 e5 bf 39 c7 44  37 cf 8a ed 90 65 37 76
    00d0  c1 e4 f4 ab 26 d0 14 dc  ed 18 fa fd 71 7a 18 55
    00e0  d0 a1 99 4f 8f e6 41 95  ae b2 42 40 11 a2 00 ac
    00f0  54 dc e4 37 bb 64 d5 1c  fd c1 44 70 d2 10 37 94
Non-root Certificate
Key Id Hash(rfc-sha1): 5c0221d3b23ca4a34ed8524675c665b83296b383
Key Id Hash(sha1): b8aff931f3733b2e0c584bb82e18334c6c22e868
Key Id Hash(md5): 42320c6b0b7c382a556ec174c42b1c7a
Key Id Hash(sha256): 2f4720fc069f03b51eae235ffc397637f8316bb3e33a470438d5e44e7115638e
Cert Hash(md5): c161d5c8c238ca1b47cd453d42337de6
Cert Hash(sha1): 7cd14dde80a6466c35424850a02647e120dfbe16
Cert Hash(sha256): 79c1e5fdf25575bf073ada8e153dba9eca35a02679390ed21087aa3a697ec2ec
Signature Hash: 66c8658bdefcdd812d6a2107ecceeebc66c6ebe13f2a8aba2b7e9d36c2b2aedc
CertUtil: -dump command completed successfully.

Certificate validation of the above End Entity (leaf) certificate on Windows Server 2016 is as follows:

Issuer:
    CN=ACME Issuing CA
    O=ACME
    C=COM
  Name Hash(sha1): 74609145bc39cad8598a403cb134b63da138f84e
  Name Hash(md5): e61e39e5344e4869b7c857666cc429d8
Subject:
    CN=ACME Test User
  Name Hash(sha1): 375d1aa5d8f2b95afb306e67ad3344303e4a31d7
  Name Hash(md5): 87377cfe61a09345596953976f50e828
Cert Serial Number: 330000000440f4cb878b18a8ce000000000004

dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwRevocationFreshnessTime: 4 Days, 9 Hours, 34 Minutes, 56 Seconds

SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwRevocationFreshnessTime: 4 Days, 9 Hours, 34 Minutes, 56 Seconds

CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
  Issuer: CN=ACME Issuing CA, O=ACME, C=COM
  NotBefore: 01/02/2019 09:58
  NotAfter: 01/02/2020 09:58
  Subject: CN=ACME Test User
  Serial: 330000000440f4cb878b18a8ce000000000004
  Template: ACME User
  Cert: 7cd14dde80a6466c35424850a02647e120dfbe16
  Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    CRL 03:
    Issuer: CN=ACME Issuing CA, O=ACME, C=COM
    ThisUpdate: 01/02/2019 09:49
    NextUpdate: 08/02/2019 10:09
    CRL: de478de37cfef404d2fd1db9d7ffac92339d5052
    Delta CRL 04:
    Issuer: CN=ACME Issuing CA, O=ACME, C=COM
    ThisUpdate: 02/02/2019 11:27
    NextUpdate: 03/02/2019 11:47
    CRL: c0bcddc38f10970e21e9364870a0b5c719a1c3e5
  Issuance[0] = 1.3.6.1.4.1.12345.509.2 ACME Certificate Policy
  Issuance[1] = 1.3.6.1.4.1.12345.509.2.4 ACME High Assurance
  Application[0] = 1.3.6.1.4.1.311.10.3.4 Encrypting File System
  Application[1] = 1.3.6.1.5.5.7.3.4 Secure Email
  Application[2] = 1.3.6.1.5.5.7.3.2 Client Authentication

CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=0
  Issuer: CN=ACME Root CA, O=ACME, C=COM
  NotBefore: 30/01/2019 10:42
  NotAfter: 30/01/2029 10:52
  Subject: CN=ACME Issuing CA, O=ACME, C=COM
  Serial: 6a00000002ae8643429cad26ad000000000002
  Template: SubCA
  Cert: 7eca216ccbc6fb44503da1be8af98aa3e8ae430d
  Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    CRL 02:
    Issuer: CN=ACME Root CA, O=ACME, C=COM
    ThisUpdate: 29/01/2019 11:01
    NextUpdate: 26/01/2020 11:21
    CRL: d71be6f684e6588e440d01cc9a4cdd95cc64bc2b
  Issuance[0] = 1.3.6.1.4.1.12345.509.2 ACME Certificate Policy
  Issuance[1] = 1.3.6.1.4.1.12345.509.2.2
  Issuance[2] = 1.3.6.1.4.1.12345.509.2.3
  Issuance[3] = 1.3.6.1.4.1.12345.509.2.4 ACME High Assurance

CertContext[0][2]: dwInfoStatus=10c dwErrorStatus=0
  Issuer: CN=ACME Root CA, O=ACME, C=COM
  NotBefore: 29/01/2019 10:50
  NotAfter: 29/01/2039 11:00
  Subject: CN=ACME Root CA, O=ACME, C=COM
  Serial: 26681fdf3be62ab24a6d301a33db61ac
  Cert: 9e0b451c6997efe03369b3b31c35980c73782f9a
  Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
  Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

Exclude leaf cert:
  Chain: a8ee1227adffcb2d7094fd57e94eec11c2b581b6
Full chain:
  Chain: 15b569354f1a96764e9d61cab02a33e7b6d64d8b
  Issuer: CN=ACME Issuing CA, O=ACME, C=COM
  NotBefore: 01/02/2019 09:58
  NotAfter: 01/02/2020 09:58
  Subject: CN=ACME Test User
  Serial: 330000000440f4cb878b18a8ce000000000004
  Template: ACME User
  Cert: 7cd14dde80a6466c35424850a02647e120dfbe16
Cannot find object or property. 0x80092004 (-2146885628 CRYPT_E_NOT_FOUND)
------------------------------------
CertUtil: -verify command FAILED: 0x80092004 (-2146885628 CRYPT_E_NOT_FOUND)
CertUtil: Cannot find object or property.

Certificate validation of the same End Entity (leaf) certificate on Windows Server 2012 R2 (same result on Windows Server 2008 R2, Windows Server 2019, Windows 10):

Issuer:
    CN=ACME Issuing CA
    O=ACME
    C=COM
  Name Hash(sha1): 74609145bc39cad8598a403cb134b63da138f84e
  Name Hash(md5): e61e39e5344e4869b7c857666cc429d8
Subject:
    CN=ACME Test User
  Name Hash(sha1): 375d1aa5d8f2b95afb306e67ad3344303e4a31d7
  Name Hash(md5): 87377cfe61a09345596953976f50e828
Cert Serial Number: 330000000440f4cb878b18a8ce000000000004

dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwRevocationFreshnessTime: 4 Days, 9 Hours, 43 Minutes, 9 Seconds

SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwRevocationFreshnessTime: 4 Days, 9 Hours, 43 Minutes, 9 Seconds

CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
  Issuer: CN=ACME Issuing CA, O=ACME, C=COM
  NotBefore: 2/1/2019 9:58 AM
  NotAfter: 2/1/2020 9:58 AM
  Subject: CN=ACME Test User

Serial: 330000000440f4cb878b18a8ce000000000004

  Template: ACME User
  16bedf20e14726a0504842356c46a680de4dd17c
  Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    CRL 03:
    Issuer: CN=ACME Issuing CA, O=ACME, C=COM
    ThisUpdate: 2/1/2019 9:49 AM
    NextUpdate: 2/8/2019 10:09 AM
    52509d3392acffd7b91dfdd204f4fe7ce38d47de
    Delta CRL 04:
    Issuer: CN=ACME Issuing CA, O=ACME, C=COM
    ThisUpdate: 2/2/2019 11:27 AM
    NextUpdate: 2/3/2019 11:47 AM
    e5c3a119c7b5a0704836e9210e97108fc3ddbcc0
  Issuance[0] = 1.3.6.1.4.1.12345.509.2 ACME Certificate Policy
  Issuance[1] = 1.3.6.1.4.1.12345.509.2.4 ACME High Assurance
  Application[0] = 1.3.6.1.4.1.311.10.3.4 Encrypting File System
  Application[1] = 1.3.6.1.5.5.7.3.4 Secure Email
  Application[2] = 1.3.6.1.5.5.7.3.2 Client Authentication

CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=0
  Issuer: CN=ACME Root CA, O=ACME, C=COM
  NotBefore: 1/30/2019 10:42 AM
  NotAfter: 1/30/2029 10:52 AM
  Subject: CN=ACME Issuing CA, O=ACME, C=COM
  Serial: 6a00000002ae8643429cad26ad000000000002
  Template: SubCA
  0d43aee8a38af98abea13d5044fbc6cb6c21ca7e
  Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
    CRL 02:
    Issuer: CN=ACME Root CA, O=ACME, C=COM
    ThisUpdate: 1/29/2019 11:01 AM
    NextUpdate: 1/26/2020 11:21 AM
    2bbc64cc95dd4c9acc010d448e58e684f6e61bd7
  Issuance[0] = 1.3.6.1.4.1.12345.509.2 ACME Certificate Policy
  Issuance[1] = 1.3.6.1.4.1.12345.509.2.2
  Issuance[2] = 1.3.6.1.4.1.12345.509.2.3
  Issuance[3] = 1.3.6.1.4.1.12345.509.2.4 ACME High Assurance

CertContext[0][2]: dwInfoStatus=10c dwErrorStatus=0
  Issuer: CN=ACME Root CA, O=ACME, C=COM
  NotBefore: 1/29/2019 10:50 AM
  NotAfter: 1/29/2039 11:00 AM
  Subject: CN=ACME Root CA, O=ACME, C=COM
  Serial: 26681fdf3be62ab24a6d301a33db61ac
  9a2f78730c98351cb3b36933e0ef97691c450b9e
  Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
  Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

Exclude leaf cert:
  b681b5c211ec4ee957fd94702dcbffad2712eea8
Full chain:
  8b4dd6b6e7332ab0ca619d4e76961a4f3569b515
------------------------------------
Verified Issuance Policies:
    1.3.6.1.4.1.12345.509.2 ACME Certificate Policy
    1.3.6.1.4.1.12345.509.2.4 ACME High Assurance
Verified Application Policies:
    1.3.6.1.4.1.311.10.3.4 Encrypting File System
    1.3.6.1.5.5.7.3.4 Secure Email
    1.3.6.1.5.5.7.3.2 Client Authentication
Leaf certificate revocation check passed
CertUtil: -verify command completed successfully.

I have built several variations of the above CA hierarchies, different Policy/Issuance OIDs etc. and always the same problem Windows Server 2016/certutil -verify fails to verify the certificate chain. Other Windows OS's as listed above can validate the chain successfully.

With an Enterprise Issuing CA built on Windows Server 2016, whilst the CA issues certificates with Policy/Issuance OIDs with no problem, the concern is that there may be a problem later down the line with these certificates when they are being used by applications. So far TLS certificates issued by a Windows Server 2016 CA containing custom Policy/Issuance OIDs can be validated successfully by clients when presented by a web server.

Has anyone else experienced the above problem with Windows Server 2016? Alternatively, can anyone see anything obvious in the above which would cause certificate chaining to fail? I am starting to err on the side of believing that this is a Windows Server 2016 bug on the basis that Windows OS's before and after Windows Server 2016 can validate the chain successfully.

Any help gratefully received (and thanks for reading if you got this far!)

Note: this question seems similar but has so far not been answered: https://social.technet.microsoft.com/Forums/en-US/b0f2baed-766a-4b29-af3c-0d9f2f48ceca/windows-server-2016-cant-verify-chain-of-certificates-with-customized-issuance-policies-applied?forum=winserversecurity