Windows server 2012 Sub CA fails because the revocation was offline when using root CA certificate from Linux/OpenSSL root CA

▲
3
▼

I've been working on a lab setting up a two-tier PKI using a Linux (Debian 9 with OpenSSL) root certificate authority and a Windows server 2012 R2 subordinate certificate authority.

When I attempt to install the the signed subordinate certificate on the Windows server I first get a warning stating that the root ca can not be verified. I click OK to ignore the warning after which the ADCS does not start. When I manually start the ADCS I get the Error message;

"The revocation function was unable to check revocation because the revocation server was offline"

I believe the issue is with how I am pointing to the CRL distribution point and AIA on the Linux root CA or how I am setting up IIS on the Windows server (possibly both).

Setup

  • rootca: Linux Debain 9 as root certificate authority
  • testpki: Windows Server 2012 R2 as subordinate certificate authority/IIS
  • dc0: Windows Server 2012 R2 as domain controller

Linux

I set up a custom OpenSSL config file on rootca adding the lines;

authorityInfoAccess = caIssuer;URI:http://testpki.example.com/crld/root.cer
crlDistributionPoints = URI:http://testpki.example.com/crld/root.crl

to the v3_ca and v3_intermediate_ca sections of the config file.

Windows

I set up a DNS record for "testpki.example.com" for name resolution on dc0.

The root certificate from the Linux box is imported to the Trusted Root Certificate Authority directory in the Certificate Authority snap-in on testpki.

After installing IIS on testpki, I set up a virtual directory with the alias crld and copy the root certificate and CRL to this directory.

I am able to connect to IIS when entering the URL "testpki.example.com/crld", but if I enter the URL "testpki.example.com/crld/root.cer" I get a 404 error even though "root.cer" is shown in the "../crld" page index.

the rest of the setup was done following this guide: Using openssl as a root ca for windows

Any insight would be appreciated.

-thanks

certutil -verify -urlfetch ..\subca.cer Output

 Issuer:
    CN=example-TESTPKI-CA
  Name Hash(sha1): e6c59398cbed5b994ff33c6e6380312fe2ad9a4a
  Name Hash(md5): b0f8c7beb298a3ba230f71fbc927b386
Subject:
    CN=example-TESTPKI-CA-Xchg
  Name Hash(sha1): 86f6ae3e12a21350005b9d70b1229ecb1b78dd0b
  Name Hash(md5): dd1324e864c4233d2f87e9c0c342dfcd
Cert Serial Number: 4b0000000478b909e350cb7280000000000004

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.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
ChainContext.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)

SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)

CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
  Issuer: CN=example-TESTPKI-CA
  NotBefore: 2/7/2018 3:37 PM
  NotAfter: 2/14/2018 3:47 PM
  Subject: CN=example-TESTPKI-CA-Xchg
  Serial: 4b0000000478b909e350cb7280000000000004
  Template: CAExchange
  a13e6c1703f95408910d21dc380818b23c76e79f
  Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
  ----------------  Certificate AIA  ----------------
  Wrong Issuer "Certificate (0)" Time: 0
    [0.0] ldap:///CN=example-TESTPKI-CA,CN=AIA,CN=Public%20Key%20Services,
Services,CN=Configuration,DC=example,DC=com?cACertificate?base?objectCla
certificationAuthority

  Revocation Check Failed "Certificate (1)" Time: 0
    [0.1] ldap:///CN=example-TESTPKI-CA,CN=AIA,CN=Public%20Key%20Services,
Services,CN=Configuration,DC=example,DC=com?cACertificate?base?objectCla
certificationAuthority

  ----------------  Certificate CDP  ----------------
  Verified "Base CRL (02)" Time: 0
    [0.0] ldap:///CN=example,CN=com,CN=CDP,CN=Public%20Key%
ervices,CN=Services,CN=Configuration,DC=example,DC=com?certificateRevoca
nList?base?objectClass=cRLDistributionPoint

  Verified "Delta CRL (02)" Time: 0
    [0.0.0] ldap:///CN=example-TESTPKI-CA,CN=testpki,CN=CDP,CN=Public%20Ke
0Services,CN=Services,CN=Configuration,DC=example,DC=com?deltaRevocation
t?base?objectClass=cRLDistributionPoint

  ----------------  Base CRL CDP  ----------------
  OK "Delta CRL (02)" Time: 0
    [0.0] ldap:///CN=example-TESTPKI-CA,CN=testpki,CN=CDP,CN=Public%20Key%
ervices,CN=Services,CN=Configuration,DC=example,DC=com?deltaRevocationLi
base?objectClass=cRLDistributionPoint

  ----------------  Certificate OCSP  ----------------
  No URLs "None" Time: 0
  --------------------------------
    CRL 02:
    Issuer: CN=example-TESTPKI-CA
    ThisUpdate: 2/7/2018 3:52 PM
    NextUpdate: 2/15/2018 4:12 AM
    7f6e7f6f4d13cd98164e53d35ce406e2dde3dd3a
    Delta CRL 02:
    Issuer: CN=example-TESTPKI-CA
    ThisUpdate: 2/7/2018 3:52 PM
    NextUpdate: 2/9/2018 4:12 AM
    07de3204292fbc0ab4a42cfef02b6b4837a78529
  Application[0] = 1.3.6.1.4.1.311.21.5 Private Key Archival

CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=1000040
  Issuer: CN=rootca
  NotBefore: 2/7/2018 1:17 PM
  NotAfter: 2/6/2023 1:17 PM
  Subject: CN=example-TESTPKI-CA
  Serial: 1000
  d74fdf7e86c80171e91dd72a16a1f8f72c9666a3
  Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
  Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
  Element.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
  ----------------  Certificate AIA  ----------------
  Failed "AIA" Time: 0
    Error retrieving URL: The request is not supported. 0x80070032 (WIN32: 50
ROR_NOT_SUPPORTED)
    testpki.example.com/crld/root.cer

  ----------------  Certificate CDP  ----------------
  Failed "CDP" Time: 0
    Error retrieving URL: Not found (404). 0x80190194 (-2145844844 HTTP_E_STA
_NOT_FOUND)
    http://testpki.example.com/crld/rootca.crl

  ----------------  Certificate OCSP  ----------------
  No URLs "None" Time: 0
  --------------------------------

CertContext[0][2]: dwInfoStatus=10a dwErrorStatus=0
  Issuer: CN=rootca
  NotBefore: 2/7/2018 12:54 PM
  NotAfter: 2/6/2023 12:54 PM
  Subject: CN=rootca
  Serial: 94cb4df27b1cb5a3
  99a30cec9d5dbc21afe5e4b679e5db844f7a9dd0
  Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
  Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
  Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
  ----------------  Certificate AIA  ----------------
  Failed "AIA" Time: 0
    Error retrieving URL: The request is not supported. 0x80070032 (WIN32: 50
ROR_NOT_SUPPORTED)
    testpki.example.com/crld/root.cer

  ----------------  Certificate CDP  ----------------
  Failed "CDP" Time: 0
    Error retrieving URL: Not found (404). 0x80190194 (-2145844844 HTTP_E_STA
_NOT_FOUND)
    http://testpki.example/crld/rootca.crl

  ----------------  Certificate OCSP  ----------------
  No URLs "None" Time: 0
  --------------------------------

Exclude leaf cert:
  a7b797168cbc0ff36636479d8cd2de6f2b184355
Full chain:
  7e1caac607a7a5b087b491accf72df2f8d4cf06e
  Issuer: CN=example-TESTPKI-CA
  NotBefore: 2/7/2018 3:37 PM
  NotAfter: 2/14/2018 3:47 PM
  Subject: CN=example-TESTPKI-CA-Xchg
  Serial: 4b0000000478b909e350cb7280000000000004
  Template: CAExchange
  a13e6c1703f95408910d21dc380818b23c76e79f
The revocation function was unable to check revocation because the revocation
rver was offline. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE)
------------------------------------
Revocation check skipped -- server offline
Leaf certificate revocation check passed
CertUtil: -verify command completed successfully.
linux
active-directory
windows-server-2012-r2
openssl
certificate-authority
asked on Server Fault Feb 7, 2018 by 0B51D14N • edited Feb 7, 2018 by 0B51D14N

3 Answers

▲
4
▼

Ok, that's better now. You have a number of issues here:

  Wrong Issuer "Certificate (0)" Time: 0
    [0.0] ldap:///CN=example-TESTPKI-CA,CN=AIA,CN=Public%20Key%20Services,
Services,CN=Configuration,DC=example,DC=com?cACertificate?base?objectCla
certificationAuthority

This error indicates that wrong subCA certificate is published in Active Directory. You will have to republish subCA certificate to Active Directory by running the following command:

certutil -dspublish -f SubCA.cer SubCA

Now your root CA:

  Failed "AIA" Time: 0
    Error retrieving URL: The request is not supported. 0x80070032 (WIN32: 50
ROR_NOT_SUPPORTED)
    testpki.example.com/crld/root.cer

you mistyped the URL in OpenSSL config. Protocol prefix is missing. You need to add http:// prefix and reissue SubCA certificate.

  Failed "CDP" Time: 0
    Error retrieving URL: Not found (404). 0x80190194 (-2145844844 HTTP_E_STA
_NOT_FOUND)
    http://testpki.example.com/crld/rootca.crl

This URL seems correct (at least, it includes protocol prefix), CA server can access web server, but web server responds with 404, indicating that there is nothing at requested path.

TBH, your setup is not good at all. Too many issues you have, because (as it seems), the design wasn't planned or plan wasn't verified.

Apart from explicit issues, your root CA itself includes CRL Distribution Points (CDP) and Authority Information Access (AIA) extensions, which are redundant. You should remove them from root certificate. AIA is not used in order to avoid cycles during path building. CDP in root certificates is not used, because you can't revoke root (self-signed) certificate, because of chicken-egg issue. But they (CDP and AIA extensions) must be included in issued certificate (i.e. subordinate CA).

I would recommend to roll back all you have done here and start from scratch.

First of all, you need to design your solution, plan all aspects.

  1. Identify applications which will use certificates.
  2. Describe certificate requirements and plan the scope of certificates.
  3. Based on [2] identify certificate templates and their configuration you will use.
  4. Design CA placement diagram and create certificate flow diagram (certificate enrollment, validation by client applications).
  5. Design disaster recovery plan, which will include backup and restore plan.

Otherwise, your solution will worth nothing. Even if this is test deployment, you still have to pass all these steps.

Properly plan CRT/CRL publishing and download URLs. You will need to check it twice, because these issues can't be fixed easily without having to re-deploy all certificates. General suggestions on this subject:

  1. do not use LDAP URLs in CDP/AIA. Consider to use HTTP only.
  2. use dedicated web server to serve CRT/CRL files (do not combine SubCA with web server roles).
  3. do not use CDP/AIA extensions in root certificate
  4. make sure that CRT/CRL files are accessible by all clients (which will use your certificates)

On CDP/AIA extension planning I would suggest to check my blog post: Designing CRL Distribution Points and Authority Information Access locations. Although, the article was written against Microsoft CA, the same principles apply to any other CA implementation, because these are best practices.

answered on Server Fault Feb 7, 2018 by Crypt32
▲
0
▼

You may want to try disabling the CRL check per the following:

https://social.technet.microsoft.com/wiki/contents/articles/964.certificate-revocation-list-crl-verification-an-application-choice.aspx 

certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE
answered on Server Fault Feb 7, 2018 by Greg Askew
▲
0
▼

I managed to get my test intermediate CA up and running. The issue was more than likely in my OpenSSL config file, specifically the CDP and AIA bits. But, for any one else who might be trying to accomplish something similar I'll describe what I did that ended up working.


You should have a look at the link provided by Crypt32 before starting, it can be found here.


First off, for DNS name resolution, set up A records on a server running the DNS service that is joined to the domain, you'll need records both for the sub CA and the IIS server. Also ensure that the Windows server that is to be used as the intermediate CA is configured to use this DNS server for resolving addresses.



    On the Linux root CA
  • Create a directory to hold your CA 
    mkdir -p ./ca/{certs,private}  

chmod 700 ./ca/private  

touch index.txt  

echo 0001 > serial  

echo 0001 > crlnumber
  • copy this config file modifying were needed to the ca directory on the Linux root CA 
      
#
# OpenSSL configuration file.
#

# Establish working directory.

ROOT_CA_FILENAME                        = rootca           #example ca filename
HTTP_HOST                               = pki.example.local #example URL for CDP

dir                                     = .

default_ca                              = CA_Default

[ CA_Default ]
serial                                  = $dir/serial
database                                = $dir/index.txt
new_certs_dir                           = $dir/certs
crlnumber                               = $dir/crlnumber
default_crl_days                        = 213
default_md                              = sha256
preserve                                = no
email_in_dn                             = no
nameopt                                 = default_ca
certopt                                 = default_ca
policy                                  = policy_any
private_key                             = $dir/private/$ROOT_CA_FILENAME.key.pem
certificate                             = $dir/certs/$ROOT_CA_FILENAME.cert.pem

# SET in script: default_days                            = 7305 


[ policy_any ]
countryName                             = optional
stateOrProvinceName                     = optional
localityName                            = optional
organizationName                        = optional
organizationalUnitName                  = optional
commonName                              = supplied
emailAddress                            = optional

[ req ]
# Options for the `req` tool (`man req`).
default_bits        = 4096
distinguished_name  = req_distinguished_name
string_mask         = utf8only

# SHA-1 is deprecated, so use SHA-2 instead.
default_md          = sha256

# Extension to add when the -x509 option is used.
x509_extensions     = v3_ca

[ req_distinguished_name ]
# See .
countryName                     = Country Name (2 letter code)
stateOrProvinceName             = State or Province Name
localityName                    = Locality Name
0.organizationName              = Organization Name
organizationalUnitName          = Organizational Unit Name
commonName                      = Common Name
emailAddress                    = Email Address

# Optionally, specify some defaults.
countryName_default             = 
stateOrProvinceName_default     = 
localityName_default            =
0.organizationName_default      = 
organizationalUnitName_default  =
emailAddress_default            =

[ v3_ca ]
# Extensions for a typical CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ v3_intermediate_ca ]
# Extensions for a typical intermediate CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
crlDistributionPoints = URI:http://$HTTP_HOST/crldist/$ROOT_CA_FILENAME.crl
authorityInfoAccess = caIssuers;URI:http://$HTTP_HOST/crldist/$ROOT_CA_FILENAME.crt

[ usr_cert ]
# Extensions for client certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, emailProtection

[ server_cert ]
# Extensions for server certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

[ crl_ext ]
# Extension for CRLs (`man x509v3_config`).
authorityKeyIdentifier=keyid:always

[ ocsp ]
# Extension for OCSP signing certificates (`man ocsp`).
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning
  • Generate a key pair 
     
openssl genrsa -aes256 -out private/rootca.key.pem 4096  
chmod 400 private/rootca.key.pem  
openssl req -config /path/to/config \  
-key private/rootca.key.pem \  
-new -x509 -days 1825 -sha256 -extensions v3_ca \  
-out certs/rootca.cert.pem  

Enter pass phrase for ca.key.pem: secretpassword
You are about to be asked to enter information that will be incorporated
into your certificate request.
-----
Country Name (2 letter code) [XX]:.
State or Province Name []:.
Locality Name []:.
Organization Name []:.
Organizational Unit Name []:.
Common Name []:Test Root CA
Email Address []:.

chmod 444 certs/rootca.cert.pem
    • On a Windows server running IIS
  • Open the IIS manager
  • Expand the directory in the left hand pane, and right click "Default Site". Select add virtual directory
  • In the add virtual directory dialog under "Alias", enter what ever you used for your CDP and AIA URLs in the OpenSSL config file above
  • Under "Physical Path", enter the path to the directory you are going to use for certificate enrollment, press enter and click ok
  • Back in IIS manager, while your new virtual directory is selected in the left pane, in the middle pane select directory browsing . In the details pane to the right select enable
  • With the virtual directory still selected in the left pane, select configuration editor
  • In the configuration editor, in the drop down menu navigate to system.webServer\security\requestFiltering and set "Double Escaping" to True
  • Apply changes
  • You may need to mess with the permissions of the virtual directory. Also, you can now import the rootca certificate to the IIS server's local computer Trusted Root Certificate Authority directory in the MMC certificates snap-in on the IIS server

    • On the Windows server to be used as the intermediate CA
  • Install the Active Directory Certificate Services via server manager (note: that this computer must be joined to a domain)
  • Make sure to install the management features, select Enterprise CA for role service, and Subordinate CA for the CA type in the role installation wizard.
  • For the private key setup select new private key, leave the MS-RSA selected in the drop down menu, for the hash algorithm select sha256, and set the key length to 4096. This will generate a CSR that will be copied to the Linux root CA
  • You can now import the rootca certificate to the mmc certificates snap-in

    • Back on the Linux CA
  • After copying your CSR to the directory on the root CA you created earlier run: 
    openssl ca -config /path/to/config -extensions v3_intermediate_ca -days 1825 -notext -md sha256  -in ca/"CSR File" -out ca/certs/subca.cer
  • You now have a signed intermediate CA certificate in the ca/certs directory that can be copied to the Windows sub CA
  • Before installing the subca certificate to ADCS generate a CRL with the following command:
    openssl ca -gencrl -out rootca.crl.pem -config /path/to/config
    and copy the generated crl and root certifiate to the virtual directory that was created on the IIS server earlier

    • Back on the Windows Intermediate server
  • Ensure that the FQDN of the IIS server is resolvable form the intermediate CA, enter the URL used for the CDP in the config file above if you used the CA_FILENAME and HTTP_HOST examples in the config file you would enter "http://pki.example.local/crldist/rootca.crl" in your browser's URL bar and you should be prompted to download or open the crl file. If you get a 404 error check the permissions on the virtual directory used for the CDP and if you get a 401 error check what the authentication settings are for the IIS server
  • Open the "Certificate Authority" application from the server manager and right click the subca in the left pane, select import
  • Browse to the location of the subca.cer file you copied over from the Linux root CA. Click ok

Your Windows intermediate CA should now be up and running.

Sources

  • Using OpenSSL as The Root CA For Windows

  • Create a Certificate Revocation List Distribution Point

  • Create a CRL

    • answered on Server Fault Feb 9, 2018 by 0B51D14N • edited Jun 14, 2018 by 0B51D14N

    User contributions licensed under CC BY-SA 3.0