Using PowerShell to create a selfsigned cert

As an alternative to using certutil to create selfsigned certificates, the following PowerShell command can be used.  This command is part of the PKI PowerShell module which when using newer versions of PowerShell will be loaded automatically when you call the command.

New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname myaddress.com

This is very handy if using PowerShell to script the deployment of AD FS for testing and you are happy to run the server with a selfsigned certificate.

 

Advertisements

Using CertUtil to display certificates which will expire in a given date range

There are a number of articles online which give the syntax for filtering certutil’s output however they never seem to work for me with 2008 and 2008 R2 certificate servers.  The following command works for 2008 and 2008 R2 servers and filters on a date range as well as a certificate template.  I find that filtering on the certificate template as well as dates is really handy when different teams are responsible for different templates.

certutil -view -restrict "NotAfter>=01/10/2012 1:00 a.m.,NotAfter<=01/07/2013 1:00 a.m.,certificatetemplate=1.3.6.1.4.1.311.21.8.10618822.7602061.4000098.14529975.1041655.1.7250419.9462924" -out "RequestID,NotBefore,NotAfter,CertificateTemplate,CommonName" | more 

Note this command uses the certificate template OID rather than the display name, in the certsrv MMC you can get the OID by navigating to the certificate templates node.

Using Certificate Extensions rather than Request Attributes for Certificate Requests containing SAN’s

Using request attributes has for a long time been the only easy way of adding SAN’s to certificate requests prior to submitting them to a CA. Windows 2003 and above by default omit SAN extensions included as request attributes from issued certificates. That is unless EDITF_ATTRIBUTESUBJECTALTNAME2 has been set.

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc 

While its Ok to set this for standalone CA’s it’s a really bad idea to enable this on an enterprise CA. Enabling attribute subject alternate name 2 (EDITF_ATTRIBUTESUBJECTALTNAME2) on an enterprise CA is a global setting which is enabled for all certificates that the CA issues.

If the enterprise CA issues user certificates, other user names can be added to the certificate enrollment via the SAN attribute request and the certificate potentially used to impersonate those users on the network.



Adding SAN’s without setting EDITF_ATTRIBUTESUBJECTALTNAME2

Windows 2008 / Windows Vista onwards support creating certificate requests containing a SAN using clear text certificate extensions. Clear text certificate extensions are supported by 2008 CA’s and above and are included in issued certificates.

To create a certificate request which includes SAN extensions, a request policy file must to be created and the certificate request generated using the ‘certreq’ tool.

The following is an example request policy for a web server certificate.

RequestPolicy.inf

[Version]
Signature="$Windows NT$"
[NewRequest]
Subject = "CN=SAMPLE.BLUE.BLACK.net.nz"  ; put your server name here
Exportable = FALSE   ; TRUE = Private key is exportable
KeyLength = 2048     ; Valid key sizes: 1024, 2048, 4096, 8192, 16384
KeySpec = 1          ; Key Exchange ñ Required for encryption
KeyUsage = 0xA0      ; Digital Signature, Key Encipherment
MachineKeySet = True
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"

RequestType = PKCS10 ; or CMC.

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=SAMPLE&" ; put your subject alternate names here
_continue_ = "dns=SAMPLE.BLUE.BLACK.net.nz&"
_continue_ = "dns=SAMPLE2&"
_continue_ = "dns=SAMPLE2.BLUE.BLACK.net.nz&"
[RequestAttributes]
CertificateTemplate = BLUEWebServer  ; This is optional 

Update the subject line of the above file with your servers FQDN, set the key length to at least 1024 and update the extensions with the additional SAN’s you want to add to the request. if your CA is an enterprise CA you should include the name of the certificate template under request attributes.

 

The command used to create the request is as follows

certreq -new RequestPolicy.inf certificate_request.csr

 

If you want to confirm the contents of the request prior to submitting it use the following command

certutil -dump certificate_request.csr

 

Once you get the signed certificate back you can accept it using the following command

certreq -accept certificate.cer

 

If you have rights to submit your request directly to the CA you can use the following commands to submit, then retrieve the certificate once the request has been approved.

certreq -submit certificate_request.csr
certreq -retrieve  #ID_from_above certificate.cer

 

For further reading check out the following link

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