none
Problem with validity code signing certificate RRS feed

  • Question

  • Hello,

    I've made a code signing certificate by duplicating the code signing template on one of our sub (intermediate) CA's, requesting a certificate using this template from one of my clients using MMC, issuing the certificate on the sub CA and moving it to the trusted certificate store on my client (it's a PFX btw).

    In the certification path there is only one record: the name of the certificate, not the name of the Sub CA, or ROOT CA (on the SUB CA > issued certificates, the whole chain is visible tho). Anyone knows why the whole chain is not visible on the client?

    My main problem is that on my client the certificate says it is valid until 2020 (1 year). I want to change it to 5 years (even if it is not best practice). I've read up on this issue and some guides say the validity period is based on the lowest period of following 3 parameters:

    - expire date of the ROOT certificate and the sub CA's certificate: both are 5 years. Because a certificate can not have a higher validity period than it's sub CA.

    - the validity period selected in the certificate template: has been put to 5 years with a renewal period of 12 weeks.
    sidenotes: basic constraints extension is enabled. Subject name is supplied in the request.

    - the validity period in the SUB CA's registry: put to 5 years with the following commands:
         certutil -setreg ca\validityperiod years
         certutil -setreg ca\validityperiod units 5
         reboot of the certsvc service + server reboot

    If these things are all set to 5 years, and i make a new certificate template (5 years) and issue a new certificate request, the certificate keeps saying "valid from 28/2/2019" to 28/2/2020" = 1 year.

    If I issue a certificate from the default templates which is set to 2 years by default, the certificate still says 1 year.

    Does anyone know which parameter has to be changed to give the SUB CA the option to create certificates beyond 1 year?

    Thanks in advance,

    Thursday, February 28, 2019 3:56 PM

All replies

  • For question #1 - You'll need to troubleshoot your steps in acquiring the certificate from the CA - the certification path is expected in the issued certificate from a CA. 

    Question #2 - Your CA cannot issue a certificate with a validity period greater than the CA validity period. This includes the Root CA issuing to a subordinate. 

    It's recommended to set a subordinate CA to half the validity of the Root and the validity to certificates at a little less than half of the Issuing CA. 

    As for the code signing certificates, to have the keys out and available for more than 6 months or even a year entails a lot of risk. However, these decisions need to be planned for as you evaluate your business requirements against acceptable risk. Make sure you know why you are issuing a code signing certificate and how it will be managed in all aspects. For example, recommended is to assign enroll permissions only to a designated group for the purpose of using that codes signing certificate. 


    Regards,

      Bill

    Bill Stites - PKI Consultant

    PKI Solutions, Inc.

    Bill Stites, PKI Consultant at PKI Solutions, Inc, started in PKI at Providence Health & Services
    in the Pacific Northwest in 2006. He has since consulted in the design and implementation of PKIs
    and certificate management systems in retail, government and insurance organizations.
    He joined PKI Solutions in January 2019.

    Thursday, February 28, 2019 6:24 PM
  • Thanks for your feedback, Bill!

    regarding Question#1: I've used this guide: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/create-code-signing-cert-for-windows-defender-application-control
    Using this procedure, only the name of the certificate shows up (but it says "this certificate is OK" and if I sign code with it, it works perfectly fine).
    So I dont really know if this is an issue altogether?

    regarding Question#2: So my ROOT CA has a 5 year certificate. My sub CA made a certificate request to the ROOT CA, which got issued and is also 5 years. The PKI then distributes this SUB CA certificate to all the clients. So when we set up the Sub CA we had to generate a CSR with 2.5 years?

    If I understand you correctly I should be able to create a code signing certificate with a validity period of for example 2 years (because it's lower then the SUB CA), but even that is not possible (turns out to be 1year) ?

    thanks in advance

    Friday, March 1, 2019 8:13 AM
  • Your code signing template is set to hold in Pending on the Issuing CA until it is approved to issue by an administrator. This is default for the v1 Code Signing template. After approval, the Admin then must export the certificate from the CA to the user who then imports into their Personal store (Local User, not Local Computer). Refresh and open the cert and note the validity and the chain. You now have a valid certificate.<o:p></o:p>

    What you have is the Public Key created when you made the request. Note that the Issuer should show the same as the Common Name.<o:p></o:p>

    The default validity period of issued certificates on the Issuing CA can be viewed in its registry.<o:p></o:p>

    1. certutil -getreg CA\ValidityPeriod   (this will return years, months...)<o:p></o:p>

    2. certutil -getreg CA\ValidityPeriodUnits    (this will return the number of....)<o:p></o:p>


    Regards,

      Bill

    Bill Stites - PKI Consultant

    PKI Solutions, Inc.

    Bill Stites, PKI Consultant at PKI Solutions, Inc, started in PKI at Providence Health & Services
    in the Pacific Northwest in 2006. He has since consulted in the design and implementation of PKIs
    and certificate management systems in retail, government and insurance organizations.
    He joined PKI Solutions in January 2019.

    Friday, March 1, 2019 4:35 PM
  • Thanks, that fixed the problem!

    The thing I did wrong was, issuing the cert on my sub CA, and then dragging the certificate on my client from the "certificate enrollment requests"-store to the personal or root store.
    I've exported the certificate to a .cer file right from the sub CA and now the validity period and cert chain is what it should be!

    The only thing I wonder now is whether it is more secure to import the .cer file to all the developer's clients (because a .cer shouldn't have a private key anymore if I understand correctly?), or convert the .cer file to a .pfx (with a private key), put a password on it and import that to the developer's clients?

    Thanks again for your help!



    • Edited by ElPadre66 Friday, March 1, 2019 7:12 PM
    Friday, March 1, 2019 7:12 PM
  • Good. So the certificate is normally securely delivered to the requester - (i.e., Someone in a Developer group assigned Enroll permissions on the template). No one else should have Enroll permissions. The private key is normally exportable since more than one developer may sign code with it, for example.

    So I would suggest working with one of the developers and document how they would enroll for their own code signing cert. Again, the intended users should be the only group given Enroll permissions.


    Regards,

      Bill

    Bill Stites - PKI Consultant

    PKI Solutions, Inc.

    Bill Stites, PKI Consultant at PKI Solutions, Inc, started in PKI at Providence Health & Services
    in the Pacific Northwest in 2006. He has since consulted in the design and implementation of PKIs
    and certificate management systems in retail, government and insurance organizations.
    He joined PKI Solutions in January 2019.

    Friday, March 1, 2019 7:55 PM
  • Hi,

    Was your issue resolved?

    If you resolved it using our solution, please "mark it as answer" to help other community members find the helpful reply quickly.

    If you resolve it using your own solution, please share your experience and solution here. It will be very beneficial for other community members who have similar questions.

    If no, please reply and tell us the current situation in order to provide further help.

    Best Regards,

    Kallen


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, March 11, 2019 6:44 AM
    Moderator