locked
Cross Certification for Code Signing – CRL Lookup Issue? RRS feed

  • Question

  • Hi,

    I have setup cross certification (with Qualified Subordination) to enable signed code developed in our test environment to be trusted by our production environment. In each environment’s forest we have a root CA and 2 level 1 policy/issuing CAs.

    From the issuing CA in production I have issued a Cross Certification certificate to the Root CA in test (using qualified subordination to limit it to code signing only).

    The code signing certificate was issued from an issuing CA in test.

    The production environment now trusts all certificates issued by the test Root CA downwards (as there are a couple of level 1 CAs for different assurance levels) for code signing purposes.

    I am also distributing the code signing certificate as a trusted publisher certificate using software restriction policies and distributed the Test CA subordinate certificate to Intermediate CA stores. If I click on the code signing certificate it validates ok and the test root appears as a subordinate to the production CA as expected.

    When signing code the full certificate chain is also being included in the signature.

    The problem I have is that when I execute signed code such as a simple VBscript I get a 10 second delay before the script will run. There is also the same delay if I click properties on the file and look up certificate from the Digital Certificates tab. The certificate always appears as valid in the end though.

    When running a network monitor capture I can see it is trying to connect to the test CA (which it cannot do). I presume this may to lookup the CRL or possibly doing something else to validate the chain?

    Can anyone suggest what I would need to do to avoid this from happening?

    Thanks for any advice!

    Pete

    Thursday, November 5, 2009 3:29 PM

Answers

  • Do not use LDAP as the first URL in the CDP extension (that was easy).
    The URL indicates a forest that is not accessible from production, hence the delay to download the base and delta CRLs.
    In fact, with 10 seconds, my guess is that it is really 7.5 + 3.75 or 11.25 seconds (and the 2nd URL is also not accessible).

    If I were doing your design, I would have done things in the opposite direction.
    I would have cross certified so that the test network trusted the production network only for Code Signing certificates
    That way the production and test certificate are signed with a production certificate, not a test certificate.
    Brian
    • Marked as answer by ___pete Friday, November 6, 2009 9:22 AM
    Thursday, November 5, 2009 10:16 PM

All replies

  • Do not use LDAP as the first URL in the CDP extension (that was easy).
    The URL indicates a forest that is not accessible from production, hence the delay to download the base and delta CRLs.
    In fact, with 10 seconds, my guess is that it is really 7.5 + 3.75 or 11.25 seconds (and the 2nd URL is also not accessible).

    If I were doing your design, I would have done things in the opposite direction.
    I would have cross certified so that the test network trusted the production network only for Code Signing certificates
    That way the production and test certificate are signed with a production certificate, not a test certificate.
    Brian
    • Marked as answer by ___pete Friday, November 6, 2009 9:22 AM
    Thursday, November 5, 2009 10:16 PM
  • Brian,
            you did not address the CRL issue, because I have similar question:  Will the TestCA 's CRL need to be imported regularly to Prod-CA and viceversa for crossed certificates to be validated and verified (since there may be no network connection to common CDP)?
    Monday, January 25, 2010 7:27 PM
  • When cross-certifying (or participating in a bridge CA), the first/primary CDP and AIA points must be internally and externally accessible (typically using HTTP).
    I would rework your CDP and AIA extensions rather than trying to setup manually imports of CRLs between forests. Doing manual copying is doomed for failure
    Brian
    Monday, January 25, 2010 9:32 PM