June 14 2017

Create certificate from CSR on a Microsoft Certificate Authority using command line

Do you have a Certificate Signing Request (CSR) from a device with which you need to create a certificate from a Microsoft Windows Certificate Authority?  This is actually pretty straight forward.  On a domain machine, launch a command prompt and save the CSR into a file on that machine (CSR.REQ in the example below).  Then just use the command:

certreq -submit -attrib "CertificateTemplate:WebServer" CSR.req cert.cer

You’ll get a prompt to select the issuing CA you want to use.  Substitute WebServer for whichever template you need to use.  You then have your certificate – cert.cer.

 

 



----------------------------------------------------------------------------
I use a maximum of one Google Ad per post to help offset some of my blog hosting costs.

----------------------------------------------------------------------------

April 22 2015

How to find an internal/local Certificate Authority

Many times when I’m new to an organisation I’ll need to do a discovery within the environment to see what technology exists – including local Microsoft Windows Certificate Authorities. A very quick and easy way to do this is to use the certutil command with the follow syntax:

certutil -config - -ping

If there is a Certificate Authority published in Active Directory then you will get a popup box with a list of them. If not, you’ll see something like this:

certutil
certutil

The command is also useful for testing the responsiveness of a Certificate Authority – if you select an existing Certificate Authority from the popup box, certutil will ping it.

December 9 2011

Microsoft Certificate Expiration Alerting tool

I came across this very useful free tool for alerting when a certificate that has been issued by an internal Microsoft Certificate Authority is going to expire (SCOM can do this too but this is a good alernative). In the words of the developer:

The Certificate Expiration Alerter helps IT departments monitor the expiration status of all their certificates which are issued from an internal Windows Server Certificate Authority (CA). When a certificate is about to expire, the Certificate Expiration Alerter sends a notification email with information about the certificate. This allows IT administrator to be proactive and take action by renewing the certificates before they expire and prevent possible service downtimes.

For more info, see these 2 websites – http://blogs.technet.com/b/nexthop/archive/2011/11/18/certificate-expiration-alerting.aspx and http://sourceforge.net/projects/certexpalerter.
 
 

October 7 2011

Extend the validity period of a Certificate Authority certificate

During a new deployment of a Certificate Services, I needed to increase the validity period of the CA certificate issued from the root (and offline) CA to the issuing CA (online and domain joined). By default this is only valid for 1 year. After unsuccessful hunting around the GUI options, I realised that this is going to be a registry change:

HKEY_LOCAL_MACHINESystemCurrentControlSetServicesCertSvcConfiguration
Find ValidityPeriod. Set the value one of the following – Days, Weeks, Months or Years.
Find ValidityPeriodUnits and set this to the numeric value that you want.
Then restart the Certificate Services NT service.

I made this change on both the root CA and issuing CA because I wanted to increase the validity period of not just the CA certificate that is issued from the root CA, but also any certificates that are issued from the issuing CA also. Be aware that validity period may also be set in the certificate template and templates supported by Windows 2000 and Windows Server 2003 Standard Edition cannot be modified. Templates supported by Windows Server Enterprise Edition (Version 2 templates) do support modification.

There is a bit more detail here if required – http://support.microsoft.com/kb/254632.

 
 

November 4 2009

Office Communicator error – Cannot synchronize address book

We’d rolled out Office Communicator 2007 R2 across the environment, however a handful of machines were getting the ‘Cannot synchronize address book’ error and when expanded the entire error message was ‘Cannot synchronize with the corporate address book. This may be because the proxy server setting in your web browser does not allow access to the address book.’

So after doing some extensive Googling, I did some troubleshooting and found that the situtation was:

– There was no issue with the proxy server. I could manually enter the name of one of the address book files (eg https://ocs.domain.com/Abs/Ext/F-0918.lsabs) and download it manually through the browser.

– There is no GalContacts.db file in the ‘C:Documents and Settings%UserName%Local SettingsApplication DataMicrosoftCommunicator’ folder meaning that there was no locally cached copy of the address book.

– In the registry under ‘HKCUSOFTWAREMICROSOFTWINDOWSCURRENTVERSIONINTERNET SETTINGS’ if I set the CertificateRevocation DWORD and to 0, I can successfully sign in and retrieve the address book (below)

Registry setting
Registry setting

This pointed to an issue with the certificate we were using and specifically the Certificate Revocation List (CRL). From here we need to check the certificate we were using for OCS, look at the details tab and check the CRL Distribution Point (shown below)

Check Certificate
Check Certificate

I then checked this distribution point (a HTTP location in our case) and found out that it was invalid. Right, so next it was off to reconfigure our internal Certificate Authority server with the correct CRL locations.

On the Certificate Authority, we open up the MMC snap-in, right click the server name and select properties. On the extension tab, select ‘CRL Distibution Point’. You then want to configure some valid location underneath here and tick the box to ensure these are being included in the issued certificates. For example in my case, I ensured that there were 3 additional entries (not including the C:Windows one):

LDAP:///CN=<CATruncatedName><CRLNameSuffix>,CN=<ServerShortName>,CN=CDP,CN=Public Key Services,CN=Services,<ConfigurationContainer><CDPObjectClass>
[TICK] Publish CRLs to this location
[UNTICK] Include in all CRLs…….Active Directory…..
[UNTICK] Include in CRLs….Delta CRL Locations…..
[TICK] Include in the CDP extension of issued certificates
[TICK] Publish Delta CRLs to this location

file://\<ServerDNSName>/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
[TICK] Publish CRLs to this location
[GREYED OUT] Include in all CRLs…….Active Directory…..
[UNTICK] Include in CRLs….Delta CRL Locations…..
[TICK] Include in the CDP extension of issued certificates
[UNTICK] Publish Delta CRLs to this location

http://<ServerDNSName>/CertEnroll/<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl
[GREYED OUT] Publish CRLs to this location
[GREYED OUT] Include in all CRLs…….Active Directory…..
[UNTICK] Include in CRLs….Delta CRL Locations…..
[TICK] Include in the CDP extension of issued certificates
[GREYED OUT] Publish Delta CRLs to this location

Selecting OK will then restart the Certificate Services service. Then you need to recreate your OCS certificates via the OCS MMC certificate wizard. Once these have been applied to the OCS server (OCS services do NOT need to be restarted), you clients just need to sign out and back in and all of your address book issues are fixed!

If you look at your new certificate, the newly added CRL Distribution Points should be listed. You can also use the ‘Certutil.exe –v –verify –urlfetch c:exported_certificate.cer’ with above certificate and check that CRL locations can be reached successfully. The ‘pkiview.msc’ tools from the Windows 2003 Resource Kit was also very useful in checking that the CRL locations could be reached.