Sign in
 
HomeWindows Server 2012Windows Server 2008 R2Windows Server 2003LibraryForums
Windows Server TechCenter >
> 
> 
Enterprise PKI - all http locations Unable To Download

Answered Enterprise PKI - all http locations Unable To Download

  • Friday, January 04, 2013 11:40 PM
     
     
    Sign In to Vote
    0

    First off all servers are 2008R2 (latest updates installed) w/Forest-Domain 2008R2, all CAs (RCA, SCA) are installed on DCs that are VMs (HyperV 2008R2).  I utilize SCM 2.5 for GPO settings on the DCs (don't know if potential issues due to security settings?).

    Initially set up w/out issue and ran fine.  Poking around my server yesterday and noticed that I have errors showing up on Enterprise PKI. 

    SCA has the following Unable To Download errors showing:

    AIA Location #2  http://wwwca/CertEnroll/serverName.domain.local_serverName-SCA.crt

    DeltaCRL Location #2  http://wwwca/CertEnroll/serverName-SCA.crl

    CDP Location #2  http://wwwca/CertEnroll/serverName-SCA.crl

    RCA has the following Unable To Download errors showing:

    AIA Location #1  http://wwwca/CertEnroll/serverName-RCA.crt

    CDP Location #1  http://wwwca/CertEnroll/serverName-RCA.crl

    All other locations in SCA register as OK, no other locations are set up in the RCA.  When I try to access http locations via IE/FF, I get Error 500 - Internal Server Error.  Checked the authentication on the CertEnroll folder in IIS and everything is disabled except for Anonymous Authentication which is Enabled.

    RCA has Certification Authority and Certification Authority Web Enrollment installed, where my SCA has Certificate Authority, Certification Authority Web Enrollment, and Certificate Enrollment Policy Web Service installed.

    Certificates are being issued successfully and the servers both have the green checks on them, it's just the Enterprise PKI node that shows with the redX.  I don't know if this is posing a major issue/risk?  I'd rather not let it sit obviously.  Any thoughts on how to resolve this issue?  I've read some of the other posts and none really apply to my situation it seems. 

    Any help at all would be greatly appreciated.

     

All Replies

  • Saturday, January 05, 2013 12:40 AM
     
     Proposed Answer
    Sign In to Vote
    1

    Hi Lavee45,

    first of all I do not recommend installing Certification Authority services onto domain controllers. Because

    - Root-CA should be kept offline for security reasons and domain controllers need to be online ^^

    - CA's typically run longer then DCs and migrating a certification authority from a DC to another server or DC is not too easy

    - DCs should provide as less open ports as possible

    Back to your question: Based on the path "CertEnroll/serverName-RCA.crt" I assume you use an IIS server on you domain controllers to publish the CRLs. Therefore I can imagine that any of you SCM setting prevents the anonymous logon to IIS on your DC. This is in fact a possible major problem because at the moment only clients which can access your CRLs and AIA Information via LDAP-Path can get revocation and AIA information. Any other client such as a non domain joined computer or maybe a smartphone cannot get this information.

    If your PKI is not yet in full production I recommend uninstalling your current one and starting from scratch with a new one. If it is already fully in production you can work around your problem by periodically copying the CRL files to a different webserver and pointing the DNS-Record "wwwca.yourdomain.tld" to this one. Anyway I recommend migrating your PKI to separate, dedicated CA servers afterwards.

    Best regards,

    Steven



     
  • Monday, January 07, 2013 4:37 PM
     
     
    Sign In to Vote
    0

    Hey StevenD, thanks for the reply.

    I understand about the need for RCAs to be off DCs, but I found a lot of other people were installing CA's on their DCs so I thought it wouldn't be that problematic.  I'm also limited on the number of physical servers/VM licenses I have, so I set it up on my DCs since they are always up.  I've been in full production for some time now.

    As far as non-domain or smartphones connecting, that is of no concern as I do not allow any smartphone or non-company PC on our network.  We handle too much HIPAA/HITECH/PCI information for me to allow devices I do not directly administer to get on to our network.

    So, in essence, this PKI http problem is of no concern then correct?  Since only domain PCs would obtain certificates and they can connect to the LDAP portion of the CA as it is.

    If no issue for my domain setup, for future reference, is there a Best Practice for RCA/SCA migration instruction set laying around?

    Thanks again for the quick reply!

     
  • Monday, January 07, 2013 10:40 PM
     
     
    Sign In to Vote
    1

    Hey Lavee,

    well in this case your HTTP CDPs are not necessary, right. Just make sure that your LDAP CDP is the first one in the list of CDPs and therefore listed before the (broken) HTTP CDP. If your HTTP CDP comes before the LDAP CDP it may cause clients to wait for timeouts which could cause problems.The same stands for AIA entries. You can easily change the order of the CDP and AIA entries via modifying the registry keys

    CACertPublicationURLs

    CRLPublicationURLs

    under

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\CertSvc\Configuration\<CA Name>

    I recommend reading those guides for migrating your CAs:

    http://technet.microsoft.com/en-us/library/cc755153%28v=ws.10%29.aspx

    http://technet.microsoft.com/en-us/library/ee126140%28WS.10%29.aspx

    Best regards,

    Steven

     
  • Tuesday, January 08, 2013 5:11 PM
     
     
    Sign In to Vote
    0
    Thanks again StevenD.

    the LDAP is 2nd in the CDP and first in the AIA on the SCA.  on the RCA there is no LDAP, just the file location and http for both the CRL and AIA.  

    Below is what I have in their order:

    SCA CRL:
    C:\windows\system32\CertSrv\CertEnroll\<CaName><CRLNameSuffix>....
    ldap:///CN=<CATruncatedName><......
    http://wwwca/CertEnroll/ServerName-SCA.crl

    SCA AIA:
    ldap:///CN=<CATruncatedName><....
    http://wwwca/CertEnroll/ServerName-SCA.domain.local_ServerName-SCA.crt
    C:\Windows\System32\CertSrv\CertEnroll\<ServerDNSName>_<....

    RCA CRL:
    C:\Windows\system32\CertSrv\CertEnroll\<CaName>....
    http://wwwca/CertEnroll/ServerName-RCA.crl

    RCA AIA:
    C:\Windows\System32\CertSrv\CertEnroll\<ServerDNSName>_<....
    http://wwwca/CertEnroll/ServerName-RCA.crt
     
  • Tuesday, January 08, 2013 8:42 PM
     
     
    Sign In to Vote
    1
    Hi Lavee,

    because your RCA's issued certificates do not have any LDAP CDP configured it is essential to get the HTTP CDP online again. If you can't your clients will throw out errors the next time they check the revocation status of your IssuingCA's certificate. See my hints above regarding the HTTP CDP

    Best regards,
    Steven
    • Edited by StevenD_2011 Tuesday, January 08, 2013 8:43 PM
    •  
     
  • Thursday, January 10, 2013 3:57 PM
     
     
    Sign In to Vote
    0

    Steven,

    Would it not be better (or is it not possible) to add the LDAP back in on the RCA?  Its been a while since I set this up and so can't remember the article/KB that had me remove the LDAP from the RCA.  But for my situation, I would think it would be far better to add the LDAP back in...if possible.

    Thoughts?

     
  • Friday, January 11, 2013 11:04 PM
     
     
    Sign In to Vote
    0
    ...you can work around your problem by periodically copying the CRL files to a different webserver and pointing the DNS-Record "wwwca.yourdomain.tld" to this one.

    Also, if it is not possible to simply add the LDAP back in on the RCA, then I'm a little confused as to what the process would be in order to do what you are suggesting^^

    How would I copy the CRL files to a different webserver and point the DNS to it?  What I mean is, would I not need to install something in IIS that would mimic the RCA?  I'm sorry, but I'm not following unless it is as simple as copying the CRL in the same folder structure and then pointing the DNS...?

     
  • Sunday, January 13, 2013 4:17 PM
     
     
    Sign In to Vote
    1

    Hi Lavee,

     

    in fact your CRL files must be reachable on those locations that are entered in your issued certificates. If you had an LDAP Path entered as a CDP when you issued the certificate of the IssuingCA you need to enter this one back in your CDP List on the Root CA. If you had only the HTTP-Path entered when you issued the certificate of the IssuingCA you can follow my suggestion as workaround as follows:

    Create a (robo)copy script to copy your CRL files to partition C: on a webserver, e.g. to C:\inetpub\mycafiles\CertEnroll

    Install IIS Role on that Webserver (let's say its computer name is “Web01”)

    Create a virtual directory that points to c:\inetpub\mycertfiles and set it as the root directory of your IIS Website

    Create a DNS Record in your internal DNS to point the name "wwwca.yourdomain.tld" to that webserver

    From now on your clients should be able to download the CRL-files from the new Webserver "Web01" because it offers your CRL-files under the name "wwwca.yourdomain.tld"

    To support downloading delta-CRLs from an IIS Webserver you need to modify the request filtering settings on that IIS Server, see here:

    http://technet.microsoft.com/de-de/library/dd379478%28v=ws.10%29.aspx

    Best regards,

    Steven

     
  • Sunday, January 13, 2013 5:31 PM
     
     Answered
    Sign In to Vote
    0

    Let me chime in here.

    1) Do not use LDAP URLs, this is not a best practice. Cannot download to non-Windows and non-domain-joined systems. Also replication issues (see http://technet.microsoft.com/en-us/library/ee619730(WS.10).aspx a whitepaper I co-wrote)

    2) Looking at your URLs from a previous post:

    SCA CRL:
    C:\windows\system32\CertSrv\CertEnroll\<CaName><CRLNameSuffix>....  OK to keep.

    ldap:///CN=<CATruncatedName><......   Eliminate. Bad practice
    http://wwwca/CertEnroll/ServerName-SCA.crl   Replace wwwca with a DNS Cname that posts to either a Web server or Web cluster. Do not use NetBIOS names. 

    SCA AIA:
    ldap:///CN=<CATruncatedName><....  Eliminate. Bad practice
    http://wwwca/CertEnroll/ServerName-SCA.domain.local_ServerName-SCA.crt  Replace wwwca with a DNS Cname that posts to either a Web server or Web cluster. Do not use NetBIOS names. 
    C:\Windows\System32\CertSrv\CertEnroll\<ServerDNSName>_<....OK to keep. Should be a value of 1 if you look at the registry values.

    RCA CRL:
    C:\Windows\system32\CertSrv\CertEnroll\<CaName>....OK to keep.
    http://wwwca/CertEnroll/ServerName-RCA.crl  Replace wwwca with a DNS Cname that posts to either a Web server or Web cluster. Do not use NetBIOS names. 


    RCA AIA:
    C:\Windows\System32\CertSrv\CertEnroll\<ServerDNSName>_<....OK to keep.
    http://wwwca/CertEnroll/ServerName-RCA.crt   Replace wwwca with a DNS Cname that posts to either a Web server or Web cluster. Do not use NetBIOS names. 


    As for unable to download. You may be using a proxy. When the PKIView.msc console performs the download, it is in the security context of the computer account. You must be sure that *ALL* computers/users can reach the Web server without having to provide credential information (anonymous access). Also, for the delta CRLs, as referenced by Steven, you need to enable Double Escaping on the Web server.

    Brian