I am setting up a two tier PKI architecture. When configuring the Root CA I made a typo in the URL for for some of the repositories that went unnoticed  until I finished configuration on the ICAs. I decided to uninstall ADCS on the two ICAs, reinstall it, and issue them new certificates that had the corrected values. 

The problem is now that I cannot start the CS service without disable checking for CRLs because it reports my CRL server is offline.

Active Directory Certificate Services did not start: Could not load or verify the current CA certificate.  SUN Behavioral Certificate Authority ICA1 The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE).

PKIview shows they are online, and can download. And the ICA certificate seems to pass all health checks. My guess is that I have some orphaned configuration settings somewhere from the old installation, but I cant find it. 

certutil -verify -urlfetch C:\issuingICA1.crt
Issuer:
    CN=SUN Behavioral Certificate Authority
  Name Hash(sha1): 5397c531fcc0d367bbe90a6902a18b0bc19ea8bb
  Name Hash(md5): 0308e448c70b204cd8deaace6a129327
Subject:
    CN=SUN Behavioral Certificate Authority ICA1
    DC=sun
    DC=local
  Name Hash(sha1): 23d1ae6e6072d585da914eae713af3aabece2c75
  Name Hash(md5): ad70aaf70d6f711526bc6b64914a288e
Cert Serial Number: 1a0000000704307ca595cc5fbf000000000007

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: 32 Minutes, 9 Seconds

SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwRevocationFreshnessTime: 32 Minutes, 9 Seconds

CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
  Issuer: CN=SUN Behavioral Certificate Authority
  NotBefore: 5/31/2019 3:24 PM
  NotAfter: 5/31/2029 3:34 PM
  Subject: CN=SUN Behavioral Certificate Authority ICA1, DC=sun, DC=local
  Serial: 1a0000000704307ca595cc5fbf000000000007
  Template: SubCA
  Cert: 7689421401077c5f65c43af3b3676f506bc8bc95
  Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
  ----------------  Certificate AIA  ----------------
  Verified "Certificate (0)" Time: 0
    [0.0] http://pki.sunbehavioral.com/pki/SUN-ROOTSUN%20Behavioral%20Certificate%20Authority.crt

  ----------------  Certificate CDP  ----------------
  Verified "Base CRL (10)" Time: 0
    [0.0] http://pki.sunbehavioral.com/pki/SUN-ROOT.crl

  Verified "Delta CRL (10)" Time: 0
    [0.0.0] http://pki.sunbehavioral.com/pki/SUN-ROOT+.crl

  ----------------  Base CRL CDP  ----------------
  OK "Delta CRL (10)" Time: 0
    [0.0] http://pki.sunbehavioral.com/pki/SUN-ROOT+.crl

  ----------------  Certificate OCSP  ----------------
  No URLs "None" Time: 0
  --------------------------------
    CRL 10:
    Issuer: CN=SUN Behavioral Certificate Authority
    ThisUpdate: 5/31/2019 4:11 PM
    NextUpdate: 6/1/2039 4:31 AM
    CRL: 2cdd336f50a9b053f321a566e9731b3f0cb1c02a
    Delta CRL 10:
    Issuer: CN=SUN Behavioral Certificate Authority
    ThisUpdate: 5/31/2019 4:11 PM
    NextUpdate: 6/2/2019 4:31 AM
    CRL: 74c0698e31f8c24bfd70a87480498ebaff58fa22

CertContext[0][1]: dwInfoStatus=10c dwErrorStatus=0
  Issuer: CN=SUN Behavioral Certificate Authority
  NotBefore: 5/22/2019 9:56 AM
  NotAfter: 5/22/2039 10:06 AM
  Subject: CN=SUN Behavioral Certificate Authority
  Serial: 1d7aa3a5ed6c17814a516849996371f3
  Cert: f4d9b6c19ef2b2038f42da33bcb2844cdb113efb
  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)
  ----------------  Certificate AIA  ----------------
  No URLs "None" Time: 0
  ----------------  Certificate CDP  ----------------
  No URLs "None" Time: 0
  ----------------  Certificate OCSP  ----------------
  No URLs "None" Time: 0
  --------------------------------
  Issuance[0] = 1.3.6.1.4.1.53953.1

Exclude leaf cert:
  Chain: 07c3f4a4cd85bbe1f65325b78ddc959b83987c71
Full chain:
  Chain: 418b0685e5f45385dd7460bedcd6386253e49992
------------------------------------
Verified Issuance Policies: None
Verified Application Policies: All
Cert is a CA certificate
Leaf certificate revocation check passed
CertUtil: -verify command completed successfully.

C:\windows\system32>

I have a group of Windows 2012 R2 servers that keep getting "hits" on Nessus scans via ID 57582 & 51192 both regarding self-signed certs and ports 3389& 1433 RDP and SQL respectively

57582=SSL Self-Signed Certificate

51192=SSL Certificate Cannot Be Trusted

Can anyone give me a link on how to resolve these vulnerabilities:  I found the below blurb during a search, but not enough info to resolve: 

"DP (Port 3389) generates self-signing certificates by default. This will actually keep auto-generating these self-signed certs. I cannot find the Microsoft link we used to fix this, but I remember it. If the server is already issued a compliant certificate, you have to add it to the certificate store on the server, more specifically the private key tab. Once we did that, it leveraged the issued cert. and stopped auto-generating the self-signed ones and all the vulnerabilities went away. If you search for something like that, I am sure it will come up. We found it on the Microsoft Social TechNet forums, if that helps."  "SQL (Port 1433) has a self-signed certificate created by the default installation, but can be configured as well."  

Please help, Jim

Hi, I am tying to set up an offline Policy CA an keep running into a "The revocation function was unable to check revocation because the revocation server was offline" error.

Please let me know if more info is needed.

Thanks

Environment:

VMWare Workstation 14 Pro 

Windows Server 2016 VMs

nCipher HSMs protecting the CA private keys

Offline Root  CA (already configured and running with a dedicated HSM)

Offline Policy CA - will share private key protection with Root CA HSM

2 Online Issuing CAs - will both be protected by a network HSM

DC, CDP, Webenrolment, etc.

We have an application which automates excel with data from our application reports.  To speed things up when the the volume of the report is relatively high, we write a sequential csv file and then import it into the spreadsheet.

This file write process takes a few seconds on Windows Server 2012R2 - but when we upgraded to Server 2016 it was running over 5 minutes and slowed to a crawl.

On a guess we disabled Windows Defender on both Windows Server Standard 2016 systems - and the speed returned to a few seconds.

What is going on here?  I wouldn't expect the AV to slow things down by a factor of 100 or more???

Glenn Barber

I am trying to get a report of revoked list of certs for last 24 hours. But when i run the output time shows in powershell windows is different compare to original revocation time in CA console. Original console shows time below for the Req ID: 6

When i check in output for the cert Req ID "6" it shows below time under "Revoked When".

Attached screenshot.

Below the code i am using:

Get-RevokedRequest -CertificationAuthority $env:COMPUTERNAME -Filter "RequestID -eq 6" -Property * | Select RequestID, @{Label="RequesterName";Expression={($_."Request.RequesterName")}}, CommonName, Notafter, EMail, DistinguishedName, @{Label="Revoked When";Expression={($_."Request.RevokedWhen")}} | Format-Table -AutoSize

Is it a bud? i am running this command directly on the internal CA server itself? not remote also the timezone is Pacific time (US and Canada) even the DC also in same time zone. Not sure why the output comes with different time.

Hi,

I want to export the root and intermediate CA certificates in base64 format using powershell on the intermediate CA.

Certutil has the switch "-ca.chain" which gives me the root and intermediate certificates in PKCS7 format. I could probably extract the root and intermediate CA certificates in base64 from this file somehow, if I only knew how. :)

I found this code from here: <Cannot post links until my account is verified>

[reflection.assembly]::LoadWithPartialName("System.Security")$data = [System.IO.File]::ReadAllBytes("certificates.p7b")$cms = new-object system.security.cryptography.pkcs.signedcms$cms.Decode($data)$cms.Certificates | foreach {New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 $_} | echo

But I'm not sure how to re-write that to give me the base64 output of each certificate.

While above solution probably works just fine, I would like to do this in a more elegant way, directly in powershell without using certutil.

Any ideas on how I could accomplish this?

Thanks!

Best regards,

Jim

We have a range of Windows 10 computers in our estate - some with no TPM chip, some with TPM 1.2, and some with TPM 2.0.

I want to configure a certificate template to optionally perform TPM Key Attestation if the client is capable, to enable clients that support TPM Key Attestation to do so whilst we phase out non-capable devices.

AD CS exposes the certificate template option "Required, if client is capable":

Allows users on a device that does not support TPM key attestation to continue enrolling for that certificate. Users who can perform attestation will be distinguished with a special issuance policy OID. Some devices might not be able to perform attestation because of an old TPM that does not support key attestation, or the device not having a TPM at all.

The certificate template is configured as follows:

• Compatibility Settings

  • Certification Authority: Windows Server 2016
  • Certificate recipient: Windows 8.1/Windows Server 2012 R2

• Request Handling

  • Purpose: Signature and encryption
  • Allow private key to be exported: No
  • Archive subject's encryption private key: No

• Cryptography

  • Provider category: Key Storage Provider
  • Algorithm name: RSA
  • Minimum key size: 2048
  • Providers:
    • Microsoft Platform Crypto Provider
    • Microsoft Software Key Storage Provider
  • Request hash: SHA1

• Key Attestation

  • Required, if client is capable
  • Perform attestation based on:
    • User credentials
  • Perform attestation only (do not include issuance policies)

When enrolling for this certificate template on a computer without a TPM chip, the request fails with error:

An error occurred while enrolling for a certificate. A certificate request could not be created.

Url: ad1.corp.contoso.com\Contoso Root CA

Error: One or more arguments are not correct. 0x800700a0 (WIN32/HTTP: 160 ERROR_BAD_ARGUMENTS)

If Key Attestation is turned off (Required, if client is capable > None), the enrollment succeeds. The PKI is otherwise healthy (CDP/AIA accessible, CRLs valid etc), and there is no block on Issuance Policy issuance (e.g. 'Endorsement Key Certificate Verified' can be manually issued into a certificate).

Any suggestions how to handle this?

Zorky HPC

Hi all,

Recently, we reviewed the security of our network and was noted that the network (mainly Windows 2012 servers) is using the following cipher suites.

- RC4-MD5
- RC4-SHA
- EXP-RC4-MD5
- DES-CBC3-SHA
- EXP-DES-CBC-SHA
- EXP-RC2-CBC-MD5
- DES-CBC-SHA
- EDH-RSA-DES-CBC-SHA
- EDH-RSA-DES-CBC3-SHA
- DES-CBC3-MD5
- TLS1-CK-DHE

How can I disable them?

However, the most important of all, how do I know if there is any impact to the other part of the existing network?

Thanks and regards,

Joseph Liu

i'm bit new to ADCS, there was a issue raised from our client saying the certificate Web enrollment page is accessible for anyone connected to network. It works this way, 1) accessing the URL https://xx.xx.xx.xx/certsrv/Default.asp, this URL doesn't have HTTPS and shows up a warning have to proceed unsafe  2) Passing through (continue to website) the HTTP connection establishes and browser asks for authentication (username , password) and 2 options,"submit" and "cancel" 3) When hit on Cancel it shows authentication denied error with error code 404. 4) At this point by hitting on refresh it lands on Web Enrollment page instead of asking for authentication again, which is a authentication by-pass. This works successfully for every user, especially on Chrome and Internet Explorer and fails on Firefox browser. What exactly could be happening?, how can this be fixed?  

Hi,

Could anybody give me a hint on how to grant RPC permissions for specific group / service account ondomain controllers? 

We are deploying lic. inventory tool and instead of installing agent in T0 (where DCs are) I decided to do an inventory of all DCs over a network from single probe server that is also placed in T0 - this provides me better security. But unfortunately, it requires some perms on such target netw. device to gather info about licenses; RPC specifically... and I don't want to delegate such through domain admins group since that would be way too much. 

Any ideas, hints? 

Browsing to any site from any of my domain controllers results in NET::ERR_CERT_AUTHORITY_INVALID 

Expanding the Certificate Information in Chrome yields: "Windows does not have enough information to verify this certificate."

Running "certutil -f -verifyCTL AuthRootWU"

Dumps all the certificates until:

All the workstations can browse without issue. Where do I go from here?

Alan

Hello.

I have a WS2016 server where I cannot start the defender service. I found out about the issue when Windows Update couldn't install Defender updates/signatures (but other WU work fine).

When i attempt to start the WinDefend service manually, it returns "Error 0x80070003: The system cannot find the path specified".

In the event log (Microsoft-Windows-Windows Defender/WHC) there are two events signalling the attempted service start:

"Windows Defender state updated to 10." and "Windows Defender state updated to 2." (in the same second).

Microsoft-Windows-Windows Defender/Operational has this error logged (in the same second of the attempted service start):

I have tried:

 - installing latest WU

 - sfc /scannow - no problems/corruptions found

 - dism /online /cleanup-image /restorehealth - no problems found

 - removing the Defender feature, rebooting, (deleting C:\ProgramData\Microsoft\Windows Defender folder), reinstalling (Install-WindowsFeature -Name Windows-Defender-Features -IncludeAllSubFeature

None of the above helped.

Any ideas (other than reinstall/refresh/reset Windows) are welcome.

I need to be able to identify the certificate template used to create a certificate in the Personal Space of LocalMachine. I can get all of the properties from the issued certificates by using:

get-childitem cert:\localmachine\my |fl * and do not see the template used property. If I look at the certificate itself by opening it I can see the "Certificate Template Information" under details tab. This is the property I would like to get.

I have a SHA256 ADCS infrastructure.  Chrome is saying "“The server signature uses SHA-1, which is obsolete. Enable a SHA-2 signature algorithm instead. (Note this is different from the signature in the certificate.)”

Is this a cipher suite issue?  

How do I resolve this?

TIA,

Steve

Hi,

From what I've read the biometric authentication data is stored on a locally on a machine. 

1. This would mean that if John (fictional scenario) logs onto 4 different machines every day he would have to setup his fingerprint on each machine, despite the 4 machines being linked to the same domain controller. correct ?

2. Is it possible to store biometric data on a domain controller, so John can set up a fingerprint only once and then his profile is loaded onto any machine that he signs onto ?

Thanks,

Greg.

Hi All,

Can you please tell me how to publish delta crl using certutil to AD

Regards,

Kamal

Attempting autoenrollment of server certificates in my domain seeing EVENT ID's 6 and 13 RPC server is unavailable 0x800706ba.  Same for domain controller autoenrollment.  I checked the security on the cert template it is set for autoenroll and enroll and read for domain computers.  Everything is Server 2016

On the AD group Certificate Service DCOM Access I added domain computers/users/controllers and authenticated users. My issuing CA computer account is listed in Cert Publishers AD group as well. 

I tried turning off the local FW that didn't help. and of course RPC service is actually running. 

The certs are not sitting in Pending requests in the CA.  And there is no old CA floating around my environment this is the first and only one. In the Event ID you can see it calling out the correct CA in the request.

I looked at registry and rsop and confirmed it is getting the Autoenrollment policy but even if you manually request a new Cert via the cert console on the server you get the same error about RPC not available. 

My issuing CA is not a domain controller but a domain joined server

I don't know where else to look

CraigB