none
New-SelfSignedCertificate add CRL distribution endpoint

    Question

  • Is it possible to add a CRL distribution endpoint using New-SelfSignedCertificate? 

    I have attempted to do this using the -TextExtension parameter guessing at the syntax, but it always comes back with invalid extension specified.

    -TextExtension @("2.5.29.31={text}=1.3.6.1.5.5.7.3.4")

    -TextExtension @("2.5.29.31={text}url=1.3.6.1.5.5.7.3.4")

    -TextExtension @("2.5.29.31={text}uri=1.3.6.1.5.5.7.3.4")

    Thursday, February 16, 2017 5:53 PM

Answers

  • Hi thehundt,

    Thanks for clarifying the miscommunication, the use of the cmdlet New-SelfSignedCertificate in your original question did indeed put me off track a bit. Also, thanks for clarifying your situation.

    In a normal CA situation, the CDP and AIA attributes are determined by their respective registry settings. On signing of a certificate request by a CA, it automatically adds the attributes. I doubt it's possible in the setup you've hacked together, what you managed to do is already pushing it.

    In your situation, the template permissions may be of great help. You can make them as granular as you like, limiting access to certain templates only for your third parties and (if all else fails) even denying permissions for templates you don't want them to have access to). All they need on the CA would be the "Request Template" permissions.

    You may also want to consider either giving them no access at all and issuing the certificates yourself, setting CA approval to the development templates so no certificates get past you without your approval, setting up a separate 'Development' CA with its own permissions and registry settings, or any combination of the above to keep control. But I would definitely go for some form of CA for the purpose you need. As you mentioned, hacking things together quickly becomes more trouble than it's worth.

    I hope that helps you on your way.

    • Marked as answer by thehundt Thursday, February 23, 2017 4:49 PM
    Tuesday, February 21, 2017 7:28 AM

All replies

  • Hi,

    >>Is it possible to add a CRL distribution endpoint using New-SelfSignedCertificate? 

    I didn't find out this command could add  a CRL endpoint.

    But you could use this command: Add-CACrlDistributionPoint

    These values means:

    The object identifiers of some common extensions are as follows:

    • Application Policy. 1.3.6.1.4.1.311.21.10
    • Application Policy Mappings. 1.3.6.1.4.1.311.21.11
    • Basic Constraints. 2.5.29.19
    • Certificate Policies. 2.5.29.32
    • Enhanced Key Usage. 2.5.29.37
    • Name Constraints. 2.5.29.30
    • Policy Mappings. 2.5.29.33
    • Subject Alternative Name. 2.5.29.1

    for more detailed info, you could refer to link below:

    https://technet.microsoft.com/itpro/powershell/windows/pki/new-selfsignedcertificate

    Best regards,

    Andy


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

    Friday, February 17, 2017 3:19 AM
    Moderator
  • Hi thehundt,

    That doesn't make sense. New-SelfSignedCertificate does precisely that, create a self-signed certificate (I, thehundt, state that thehundt is trustworthy). You can only revoke the validity of a certificate if you have an authority that stated that validity in the first place (a CA). You can't revoke yourself. So as far as I know, you can't do this.

    Kind Regards,

    Friday, February 17, 2017 8:20 AM
  • I appreciate the responses.  Let me provide a little more clarity.

    First this is for testing within a private network.  This is not for a production environment.

    I have an existing pki infrastructure with a root ca and an intermediate ca that I use to issue certificates with a proper CRL endpoint.  What I am attempting to do is provide a means for 3rd parties to create certificates that are signed by an issuing certificate that I have created that is chained back to my root without giving access to my issuing CA.

    I was able to create an issuing ca chained to my root, and use Add-SelfSignedCertificate to create certificates properly chained back to my root using the -signed parameter (contrary to what J. Couwenburg suggested).  These certificates will work for some of our use cases.  For the others, we will need a valid CRL endpoint on the certs.  As stated, I have a valid endpoint, I just cannot figure out how to add the URI to the certs I am creating or if this is even possible using powershell.

    I can make this work by standing up another CA that is directly accessible to the 3rd parties requiring the test certs, but I am trying to avoid the extra maintenance of doing that.

    Friday, February 17, 2017 2:17 PM
  • Hi thehundt,

    I'm not sure if I'm completely following your method. Could you give the precise commands that you used to create this "issuing CA"? If you managed to use New-SelfSignedCertificate to generate a certificate signed by your Root CA, I'd love to see the precise command. I would also love to see the Authority Key Identifier of the issuing CA certificate and the Subject Key Identifier of the Root CA.

    "What I am attempting to do is provide a means for 3rd parties to create certificates that are signed by an issuing certificate that I have created that is chained back to my root without giving access to my issuing CA."

    This depends on the definition of "access". A CA-signed certificate needs to be signed with the use of the CA's private key. A private key by nature of things being private, the certificate must be offered to the CA for signing at one point or another, so there's some form of access direct or indirect at one point. Access can be limited and/or staggered though.

    "I can make this work by standing up another CA that is directly accessible to the 3rd parties requiring the test certs, but I am trying to avoid the extra maintenance of doing that."

    I think for your third parties a proper CA, with some suitable modifications, is still the way to go forward, and will avoid more maintenance than it creates. You would need some external accessibility options though.

    - You'd want AIA and CDP entries, or OCSP responders, that are accessible from the Internet for verification purposes. These should not be on the CA, of course, but on Webservers in your DMZ, accessible from the CA for posting the CRL (outbound only) from the inside, and from the internet for collecting them (read only). Adding the CDPs to the CA is a one-off, though maintenance of the webservers may cost a small bit.

    - Having the customers issue certificates is somewhat more tricky. There are several options that work technically, but it depends on your personal taste for balancing:

       - You could take the most secure way, have them send in the certificate requests and process them on your site by staff. That way you can control the certificates issued.

       - The Certificate Enrollment Web Pages could be placed in the DMZ, with some kind of access control and optionally (recommended) with Certificate Approval on. This does, however, allow for just about anyone who manages to access the pages to issue certificates, so it's far from ideal security-wise.

       - There may be options using Microsoft NDES. This I am not sure of.

       - There may also be options that utilize third-party products.

    Looking forward to seeing your methods.

    Kind Regards,

    • Edited by J.Couwenberg Friday, February 17, 2017 5:38 PM misclick on submit before completion.
    Friday, February 17, 2017 5:32 PM
  • I appreciate your response and clearly you know your stuff, but I think I may have made a small miscommunication.

    I did not use powershell to create the issuing cert.  I created it via a CSR using a SubCA template and submitted it to my root ca.  I then used the resulting issuing ca with powershell to create a new certificate chained to my root.  3rd parties in this context are 3rd party to my organization, but still within the private network of my company.  I would not be hacking this all together for an external client solution, this is an internal test solution to help adopters external to my organization but within my company access our integration environment in a pseudo production-like manner.  My CRL endpoint is accessible on the corporate intranet, I would like to avoid giving teams outside my organization direct access to the CA to create certs.

    The process I am attempting to replace is other teams sending self-signed certs to us to "trust" so they can access our environment.  The solution I have detailed above accomplishes this, but there was an additional request to add CRL to the certs for specific cases where it is needed.  Initially I thought I should be able to add this extension via the certificate creation process, but it is proving more trouble than it is worth.

    Friday, February 17, 2017 7:11 PM
  • Hi thehundt,

    Thanks for clarifying the miscommunication, the use of the cmdlet New-SelfSignedCertificate in your original question did indeed put me off track a bit. Also, thanks for clarifying your situation.

    In a normal CA situation, the CDP and AIA attributes are determined by their respective registry settings. On signing of a certificate request by a CA, it automatically adds the attributes. I doubt it's possible in the setup you've hacked together, what you managed to do is already pushing it.

    In your situation, the template permissions may be of great help. You can make them as granular as you like, limiting access to certain templates only for your third parties and (if all else fails) even denying permissions for templates you don't want them to have access to). All they need on the CA would be the "Request Template" permissions.

    You may also want to consider either giving them no access at all and issuing the certificates yourself, setting CA approval to the development templates so no certificates get past you without your approval, setting up a separate 'Development' CA with its own permissions and registry settings, or any combination of the above to keep control. But I would definitely go for some form of CA for the purpose you need. As you mentioned, hacking things together quickly becomes more trouble than it's worth.

    I hope that helps you on your way.

    • Marked as answer by thehundt Thursday, February 23, 2017 4:49 PM
    Tuesday, February 21, 2017 7:28 AM
  • This makes sense.  Thanks for the detailed response and suggestions.

    Thursday, February 23, 2017 4:50 PM