Windows PKI blog : Configuration

Automated CA installs using VB script on Windows Server 2008 and 2008R2 [UPDATED]

shawncor — Fri, 18 Sep 2009 16:23:00 GMT

Starting with Windows Server 2008 the CA product team introduced a set of COM objects that can be used to control the installation of CAs. Using VBScript you can quickly automate the setup and installation of a CA.Below is a script that is being used by the product team in our testing of Certificate Services. SetupCA.vbs was designed to have the functionality present in the setup UI but in an easy command line that can be used in automation. Most of the functionality of the script is fairly straight forward in just setting properties on the setup object. A couple of features, like the key/cert re-use, take a bit of code to get the setting right.

All of the ICertSrvSetup COM object properties and methods are documented in the MSDN at http://msdn.microsoft.com/en-us/library/bb736371%28VS.85%29.aspx.

The setup script is attached to this post, simply click the link for setupca.vbs and save the file to your local system.

Some example usages of the script:

Install Enterprise Root CA
Cscript setupca.vbs /ie /sn MyRootCA /sk 4096 /sp "RSA#Microsoft Software Key Storage Provider" /sa SHA256

Install Standalone Sub CA
Cscript setupca.vbs /it /sn MySubCA /sr MyParentCAMachine\MyRootCA /sk 384 /sp "ECDSA_P384#Microsoft Software Key Storage Provider" /sa SHA1

Uninstall CA:
Cscript setupca.vbs /uc

Install Web Pages:
Cscript setupca.vbs /iw /sr MyParentCAMachine\MyRootCA

There is also a usage that lists all the parameters if you run the script without any arguments.

UPDATE: Script has been updated to include option for offline requests using new /OR switch. Example:

Install Enterprise Sub CA saving request to a file:

Cscript setupca.vbs /if /sn "My Sub CA" /sp "RSA#Microsoft Software Key Storage Provider" /sk 4096 /or "c:\temp\ca.req"

How to configure the Windows Server 2008 CA Web Enrollment Proxy

MS2065 — Thu, 23 Apr 2009 08:57:46 GMT

A co-worker posted an interesting blog about configuring the Windows Server 2008 CA Web Enrollment proxy at

http://blogs.technet.com/askds/archive/2009/04/22/how-to-configure-the-windows-server-2008-ca-web-enrollment-proxy.aspx.

Certificate distribution and the Microsoft Terminal Services Client

MS2065 — Mon, 09 Feb 2009 19:30:18 GMT

A few days ago I worked in a test environment that also consists of a PKI. I used the Microsoft Terminal Services Client (mstsc.msc) for a while to connect to various machines in the test environment. One day, I helped a coworker troubleshooting a certificate problem in the test environment. From his machine, I connected via Microsoft Terminal Services Client to one of the test servers. While connected to the test server, I opened the Certificates MMC snap-in (certmgr.msc) and looked to the current user’s personal certificate store. Besides test certificates I also saw certificates with my personal name in the subject attribute. What was going on here, I thought? Where do these certificates come from? Time to investigate!

Investigation

I opened one of the certificates with my name in it to find out more details. The certificate definitely belonged to me. Even worse, the General tab of the certificate details told me that I have a private key for this certificate (“You have a private key that corresponds to this certificate.”). I copied the serial number of that certificate from the Details tab and opened a command prompt. What certificate service provider was used to issue that certificate?

The following command told me the answer:

certutil -v -silent -user -store My "05 05 1c 00 22 7f 3c dd fa 98" | find "Provider ="
Provider = Microsoft Base Smart Card Crypto Provider

I looked down to the notebook and noticed that no smartcard was sitting in the reader. That made me even wonder more. What has finally happened here?

Analysis

When I connected to the test environment from my personal notebook, my smartcard was in the reader while I was using a Terminal Services session.
I didn’t use a custom RDP file when I started the Microsoft Terminal Services Client (mstsc.msc), so the settings from %USERPROFILE%\documents\Default.rdp configuration file have been applied.
Under the Options >>> button on the Local Resources tab under the More … button, Smart cards was check-marked. That setting caused the Microsoft Terminal Services Client to map my smartcard into the remote desktop session.
On the remote test server, the Certificate Propagation service (CertPropSvc) was running.

The combination of those 4 conditions caused my personal certificates to appear in the user profile of the remote desktop session. The Microsoft Terminal Services Client maps the smart card reader as a device into the remote desktop session. If a smartcard is available in the reader, the certificates become accessible within the remote desktop session. The Certificate Propagation Service (CertPropSvc) reads certificates (not the private keys!) from a smartcard and puts them into the current user’s certificate store. This is exactly what has happened here.

The reason why the Certificate Propagation Service is doing so, is related to certificate autoenrollment. When autoenrollment is triggered as part of the regular group policy interval (default is every 8 hours with a timescew of +/-90 minutes) it examines certificates in the personal store and determines if certificate enrollment, renewal or archival is required. To enable autoenrollment for certificates on smartcards, it is required that these certificates are registered in the personal store. Otherwise, autoenrollment would have to know on which devices (smartcards, tokens, …) certificates have ever been stored. For every certificate that is associated with a private key on the local system, an entry for the certificate service provider (CSP) exists in the key properties. Once autoenrollment has access to a certificate and the CSP, it is able to manage a certificate that is stored on a device.

A question remains, regarding the statement “You have a private key that corresponds to this certificate.” on the General page of the certificate details dialog. Why is that? How could the system tell me that there is a private key while my smart card is not inserted into the reader? Here is the answer: When the Certificate Propagation Service reads a certificate from the card, it is a true statement that you have a private key for the certificate. The private key is available on the smartcard and therefore, in the certificate’s key property (which is stored in the certificate store) it is noted that a private key is there. However, the key property which links a certificate with a key is only written once when a certificate is copied into the certificate store. There is no later update mechanism that continuously verifies the key property. So in my case, the key property was created when the Certificate Propagation Service read the certificate from my mapped smart card and at that time, the private key was available to the system. However, if the smart card with the key on it is removed from the system, the key property is not updated.

To summarize, the Certificate Propagation Service just copied my certificates into the certificate store while the private key was available on the smart card. The security of my private keys was not at risk at any time. Only the certificates – which can bee treated as public information anyways - have been disclosed.

Prevention and cleanup

What have I done to avoid distribution of my certificates when working with remote desktop sessions? The simplest thing is to manually uncheck the Smart card mapping in the Microsoft Terminal Services Client. This can also be done with group policies. Since all four conditions from above have to be true, disabling the Smart card mapping is effective. Additionally I stopped the Certificate Propagation Service with a group policy on all servers in the test environment. This optional configuration step avoids unintended certificate distribution in case a unmanaged workstation still has enabled Smart card mapping.

Finally, I used the following command to manually remove the certificates from a user profile:

certutil –user –delstore My "Firstname Lastname"

In my case, manual cleanup was doable because the number of remote profiles was low. An automated solution would be required if a broader certificate store cleanup is required. But that’s another story …

Certificate Services setup failed with the following error: Element not found. 0x80070490

MS2065 — Mon, 26 Jan 2009 09:41:22 GMT

Until Windows Server 2008 shipped, every Domain Controller had a readable and writable copy of the Active Directory schema, domain naming context and configuration naming context. This statement changed when we introduced the Read Only Domain Controller (RODC) role with Windows Server 2008. The RODC creates several new configuration scenarios for Active Directory integrated applications.

With this blog post I want to explain a situation where a Windows Server 2003 Enterprise CA setup fails with error Element not found. 0x80070490. The setup error occurs when the intended Windows Server 2003 CA computer maintains a secure channel with a Windows Server 2008 RODC. In this case, the CA setup code cannot write new objects into the Active Directory configuration naming context. In Windows Server 2008 the CA setup code was updated to always make a connection to a writable Domain Controller in the beginning and then stick with that Domain Controller for all the operations done during setup.

To work around the Windows Server 2003 CA setup limitation, you could use the nltest.exe command from the Windows Support tools. To do so, make sure that a writable domain controller exists in the site that the Windows Server 2003 CA computer belongs to. If no writable domain controller is configured for the site, you must work with your Active Directory Enterprise administrator to change the site configuration so that a writable domain controller becomes available in the CA’s site.

To fix the problem, open a command prompt on the intended Windows Server 2003 CA to execute the following commands with local administrator permissions.

As a first step, query the DNS for a list of writable domain controllers in the domain. In this sample I use contoso.com as domain name.

nltest /dnsgetdc:contoso.com /WRITABLE

Next, reset the secure channel that is currently used between the Windows Server 2003 and the RODC.

nltest /sc_reset

Finally, verify if the secure channel is now set up with a writable domain controller.

nltest /sc_query:contoso.com

If the intended CA computer is now connected to a writable domain controller, restart the CA setup.

How to decommission a Windows enterprise certification authority and how to remove all related objects from Windows Server 2003

MS2065 — Sun, 18 Jan 2009 23:03:32 GMT

Today I want to comment on the quite popular Microsoft Knowledgebase article How to decommission a Windows enterprise certification authority and how to remove all related objects from Windows Server 2003 and from Windows 2000 Server. I am referring to version 6.0 of the article with a review date of November 18th, 2008. You should be aware that the article has documentation bugs that need to be fixed. Until we are publishing a corrected version, you should consider the following information when applying the steps from the article.

In Step 6 L, the article asks you to delete all certificate templates. This is misleading information because it is only appropriate when you have already deleted ALL CAs in the Active Directory Forest. If there are still enterprise CAs in operation, certificate templates must not be deleted.
The article does not point out to identify all of the CA objects in Active Directory (under the KRA container, for example), so some may be left around. To clean up after a CA that left objects around in Active Directory, run the following commands to see what AD objects remain:

certutil –ds {CACommonName}
certutil –ds {CAMachineNetBiosName}

For example, if the common name of the CACommonName is called CorpCA01 and the CAMachineNetBiosName is CACorpServer you would perform the following commands:

certutil –ds CorpCA01
certutil –ds CACorpServer

Once you look over the list of DNs displayed, and are satisfied they are all related to the abandoned CA, you can change -ds to -dsDel and repeat the commands to delete the CA's objects with enterprise administrator permissions.
In Step 6 M, the article says to delete the NTAuthCertificates object. This is wrong information because this object should never be deleted - only CA certificates should be deleted from its cACertificate attribute. Use the following command to see the full ldap path to your NtAuthCertificates object in your Active Directory.

certutil -ds -v NtAuthCertificates

With enterprise administrator permissions you can use the following command to delete certificates from within the NTAuthCertificates store:

certutil –viewdelstore "ldap:///CN=NtAuthCertificates,CN=Public Key Services,...,DC=...,DC=com?base?cACertificate"

The -viewdelstore verb invokes the certificate selection U/I on the set of certificates in the specified attribute. You can view cert details, and cancel out of the selection dialog to make no change. If you select a certificate, it will be deleted when the U/I closes and the command completes execution.

To clean up the NTAuthCertificates you can also use the PKIview MMC snap-in. It is part of the Windows Server 2003 Resource Kit Tools and the Microsoft Remote Server Administration Tools in Windows Server 2008 and Windows Vista.

Suppressing certificate attributes in a CA certificate request

MS2065 — Sun, 05 Oct 2008 13:10:18 GMT

When a PKCS#10 request for a CA certificate is generated, a pre-defined set of certificate attributes is included. This blog entry explains how to eliminate attributes that would go into the CA certificate request by default.

Imagine that you are setting up a new subordinate CA where the parent CA is a non Windows CA. The parent CA may not support or accept certificate attributes like the certificate template name. To exclude an attribute from the CA certificate request you must create a capolicy.inf file in the %WINDIR% directory before creating or renewing a CA certificate. The capolicy.inf file lists the OIDs of the certificate extensions to be excluded in the Extensions section. See the Microsoft Knowledgebase for a list of Object IDs associated with Microsoft cryptography.

The following sample caplicy.inf file would exclude the CA version and the certificate template name from the CA certificate request.

[Version]
Signature= "$Windows NT$"
[Extensions]
1.3.6.1.4.1.311.21.1 =
1.3.6.1.4.1.311.21.7 =

Note: Certificate attributes should only be removed from a certificate request if there is real demand for it. Never do it just for cosmetics!

When working with a capolicy.inf file you should be aware of the behavior described in the Microsoft Knowledgebase article Custom extensions in the CAPolicy.inf file do not take effect after you renew the root CA certificate by using a new key. The article applies for Root and Subordinate CAs running on Windows Server 2003 SP1 or Windows Server 2003 SP2.

You cannot add V2 or V3 templates after an inplace upgrade was performed on a Windows Server 2008 enterprise CA

MS2065 — Thu, 31 Jul 2008 18:41:44 GMT

Technically, it is possible to install an enterprise CA on a Windows Server Standard edition. With this configuration, enterprise features of the certification authority are intentionally not available.

To enable the CA enterprise features, it is required to upgrade a Windows Server from Standard to Enterprise edition. To keep the existing enterprise CA configuration, it is recommended to just perform a Windows inplace upgrade. If you do this on a Windows Server 2008 you will recognize that only V1 certificate templates are available for assigning after the upgrade was performed.

To fix the problem, close the Certificate Services MMC snap-in and run the following commands with administrator permissions at a command-line on the CA computer:

certutil -setreg ca\setupstatus +512

net stop certsvc

net start certsvc

When you re-open the Certificate Services MMC snap-in, you are able to assign V1, V2 and V3 certificate templates to the certification authority.

[February 3, 2009 update] An official Microsoft Knowledgebase article is published under http://support.microsoft.com/kb/967332.

How EffectiveDate (thisupdate), NextUpdate and NextCRLPublish are calculated

MS2065 — Thu, 05 Jun 2008 06:52:00 GMT

The validity time of a certificate revocation list (CRL) is critical for every public key infrastructure. By default, most applications verify the validity of certificates against a CRL.

Two CRL types exist: base CRLs and delta CRLs. In case where no delta CRL is used, certificates are treated as invalid if the base CRL is not available or expired. If a delta CRL is in use, the delta and base CRL must be available and valid to succeed with certificate verification.

The information provided in this article applies for both, the base CRL and the delta CRL generation.

When you look at a CRL, there is information about the Next update, the Next CRL Publish and the Effective date of the CRL. The term Effective date is used in the Windows certificate dialog while certutil.exe and the RFC name this field thisupdate.

Effective Date (aka thisupdate) - The date that a CRL became effective. The effective time, by default, is set to 10 minutes prior to the current date and time to allow for clock synchronization issues.

Next CLR Publish - This non-critical CRL extension indicates the date and time when a Windows CA will publish a new CRL. When a Windows computer uses a CRL for certificate verification it also examines the Next CRL Publish extension. If the Next CRL Publish date is already in the past, it connects to the CRL distribution points (referenced in the certificate) and attempts a download of a newer CRL. The time after the Next CRL Publish and before the Next Update is a buffer time to allow Windows computers retrieval of a CRL before the CRL has actually expired.

Next Update - The date and time that a Windows client considers as the expiration date of the CRL. From an operational viewpoint, this is the most critical information. If this date passes, Windows computers will invalidate certificates that are checked against this CRL.

Now we know the CRL attributes that control the CRL validity. The question is how these dates are calculated by a Windows CA. Read on to find out!

Under the Certification Services configuration hive in the registry two values control the overlap period for the base CRL and two registry values define the overlap period for delta CRL creation:

HLKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA Name>:

CRLOverlapPeriod=REG_SZ:Hours|Minutes
CRLOverlapUnits=REG_DWORD:0x0
CRLDeltaOverlapPeriod=REG_SZ:Hours|Minutes
CRLDeltaOverlapUnits=REG_DWORD:0x0

You can verify the settings for the above registry keys on your CA computer with the following commands:

certutil -getreg CA\CRLOv*
certutil -getreg CA\CRLDeltaOv*

If the registry values are set and valid, the overlap period for a base or delta CRL is initially calculated by the CA as:

OverlapPeriod = CRLOverlapUnits * CRLPeriod

If an invalid or no value is present under the CRLOverlapUnits registry key, the OverlapPeriod for a base CRL is initially calculated as 10 percent of the CRLPeriod and CRLPeriodUnits registry values:

OverlapPeriod = (CRLPeriodUnits * CRLPeriod) / 10

If the OverlapPeriod for a Delta CRL is calculated, the entire period of time specified as CRLDeltaPeriod and CRLDeltaPeriodUnits of the delta CRL is used.

OverlapPeriod = (CRLDeltaPeriodUnits * CRLDeltaPeriod)

As a next step, the smaller value of either the so far calculated OverlapPeriod or 12 hours is taken.

OverlapPeriod = min(OverlapPeriod, 12 hours)

If no CRLPeriodUnits or CRLDeltaPeriodUnits have been set, the OverlapPeriod is 0 at this point. As a next step, the ClockSkewMinutes parameter from the registry is taken into account. The ClockSkewMinutes are primarily used to mitigate time differences between a client computer and the CA. To further calculate the OverlapPeriod, the ClockSkewMinutes is multiplied by 1.5 and then compared with the calculated OverlapPeriod. The greater of both values wins.

OverlapPeriod = max(OverlapPeriod, 1.5 * ClockSkewMinutes)

In case the Overlap period is calculated for a base CRL, it cannot be longer than CRLPeriodUnits * CRLPeriod. Therefore the smaller value wins.

OverlapPeriod = min(OverlapPeriod, CRLPeriodUnits * CRLPeriod)

Is the Overlap time calculated for a delta delta CRL, the OverlapPeriod can not be longer than CRLDeltaPeriodUnits * CRLDeltaPeriod.

OverlapPeriod = min(OverlapPeriod, CRLDeltaPeriodUnits * CRLDeltaPeriod)

Finally, the ClockSkewMinutes are added to the calculated OverlapPeriod.

OverlapPeriod = OverlapPeriod + ClockSkewMinutes

The calculation of the OverlapPeriod is done so far. The the actual calculation of the CRL values can start a next step:

The Effective Date must not be earlier than the CA certificate became valid. This is because the CRL carries the CA certificate's signature.

Effective Date = max(Current Time - ClockSkewMinutes, NotBefore_date_from_the_CA_certificate)

The Next CRL Publish for a base CRL is calculated as the sum of current time plus CRLPeriod:

Next CRL Publish = Current Time + (CRLPeriodUnits * CRLPeriod)

The Next CRL Publish for a delta CRL is calculated as the sum of current time plus CRLDeltaPeriod:

Next CRL Publish = Current Time + (CRLDeltaPeriodUnits * CRLDeltaPeriod)

The Next Update is for a base CRL is calculated with the following formula:

NextUpdate = min(Current Time + (CRLPeriodUnits * CRLPeriod) + OverlapPeriod + ClockSkewMinutes, NotAfter_date_from_the_CA_certificate)

The Next Update is for a delta CRL is calculated with the following formula:

NextUpdate = min(Current Time + (CRLDeltaPeriodUnits * CRLDeltaPeriod) + OverlapPeriod + ClockSkewMinutes, NotAfter_date_from_the_CA_certificate)

Since you have understood the algorithm now, you may want to examine the CRL on your system and see what the dates are set to. If you open the certificate management MMC snap-in from a command-line, you can see a list of all CRLs that have been generated by the CA so far. At a command-prompt, perform the following command:

certsrv.msc /e

With the /e switch, an additional container is shown in the snap-in that lists all CRLs at a glance.

How to refresh the CRL cache on Windows Vista

MS2065 — Thu, 13 Sep 2007 11:51:00 GMT

By default, Windows is caching Certificate Revocation Lists (CRL) and CA certificates to quickly verify certificate chains. The downside of this behavior is that a newer CRL is not picked up by the client until the locally cached CRL has expired.

Windows versions before Windows Vista do not support deletion or a forced update of the CRL cache.

You can view what is in your current CRL cache with the following command:

certutil -URLcache CRL

On Windows Vista, CAPI 2.0 has support to set a expiry date for the CRL and OCSP cache. You can use certutil to set a date and time when all cache entries become invalid. The following commands require administrative permission on the system.

To see when the cache was invalidated the last time, perform this command:

certutil –getreg chain\ChainCacheResyncFiletime

Note: If the ChainCacheResyncFiletime was never set manually before, the registry key does not exist and the following error message is shown:

CertUtil: -getreg command FAILED: 0x80070002 (WIN32: 2)

CertUtil: The system cannot find the file specified.

The error can be ignored because default CRL caching takes place in this case.

If the @now parameter is used, all cached entries are invalidated immediately.

certutil -setreg chain\ChainCacheResyncFiletime @now

To disable temporarily the cache until after now plus 3 days and 6 hours, use this command. Setting the registry value to a future date implies that no cache entries will be used until after the date specified. The value of such a configuration is questionable.

certutil –setreg chain\ChainCacheResyncFiletime @now+3:6

To delete a registry value:

certutil –delreg chain\ChainCacheResyncFiletime

How to re-install the default certificate templates?

MS2065 — Mon, 06 Aug 2007 21:58:00 GMT

When you launch the certificate templates MMC snap-in (certtmpl.msc) for the first time, the certificate templates are installed automatically in the background. Installing the templates is independent of the availability of an enterprise CA. Enterprise Administrator permissions are required to successfully install the templates.

That's nice and convenient but what happens if you accidentally deleted the template objects from Active Directory? The templates can be viewed and also deleted (with appropriate permissions) through the Active Directory Sites and Services MMC snap-in (dssites.msc) or any other LDAP client can be used.

So, what to do if the templates or the OID container have disappeared? With a single command-line, you can get them back. As prerequisite to install the certificate templates you must have create child access to the template container in Active Directory which is the default setting for an enterprise administrator.

If you are running Windows Server 2003, use the following command with enterprise administrator permissions:

regsvr32 /i:i /n certcli.dll

If you have Windows Vista or Windows Server 2008 already in place, certutil.exe understands a new verb to re-install the templates. Certutil is included in all Windows Vista SKUs by default.

certutil -installdefaulttemplates

After performing one of the above commands you must restart the CA service.

The following two knowledgebase articles describe scenarios where re-installation of certificate templates can make sense:

You receive an error message, and event ID 53 is logged when a client computer requests a certificate from a Windows Server 2003 SP1-based CA (http://support.microsoft.com/kb/932457).
Event ID 77 is logged in the Application log when the CertSvc service starts on a CA server that is running Windows Server 2003 with Service Pack 1 (http://support.microsoft.com/kb/931354).

The missing EDIT button in the CA properties extensions tab

MS2065 — Sun, 27 May 2007 15:54:00 GMT

To adjust the CRL and AIA distribution point there are at least three choices to do it. The most familiar way to change the distribution point might be through the CA MMC user interface. The second way is to directly change the registry key CACertPublicationURLs or CRLPublicationURLs with regedit.exe. Alternatively, you can use certutil -setreg to change these keys in the registry.

While having full editing control over the multi-valued registry key, you may miss an edit button in the UI to conveniently change an existing entry without retyping the full URL.

Only very few people are aware that you can use a copy/paste trick to overcome the missing edit button. Here are the steps to copy an existing CRL or AIA entry and create a new one:

Open the Certification Authority MMC snap-in.
Open the CA properties.
Go to the Extensions tab.
Select the entry that you want to copy from the list of available CRL or AIA entries.
Press <CTRL>+<C> to copy the entry into the clip-board.
Click the Add… button and press <CTRL>+<V>. The paste operation is certainly not limited to the Add Location window. Once the URL has been copied into the clipboard it can be pasted everywhere.
Change the distribution point as appropriate.

Manually publishing a CA certificate or CRL into a LDAP store

MS2065 — Fri, 13 Apr 2007 12:27:00 GMT

The CA is automatically publishing its own certificates and related CRLs into Active Directory if a LDAP reference is configured in the CA property “Extensions”.

If you are using a different LDAP server (such as Microsoft ADAM) to make the CA certificate and CRL available, certificates and CRLs must be published manually. The easiest way to do that is with certutil.

Perform the following command to publish the CRL manually into a LDAP-store.

certutil –addstore "LDAP://[server]/[DN]?certificateRevocationList?base?objectclass=cRLDistributionPoint" [CRL-File]

Replace [server] with the name of the LDAP server where you have write permissions.
Replace [DN] with the path that you have used in the CA configuration.
Replace [CRL-File] with the file name of the CRL that you want to publish.

Here is the command to publish a CA certificate manually:

certutil –addstore "LDAP://[server]/[DN]?cACertificate?base?objectClass=certificationAuthority" [cert-file]

To manually publish a CA certificate or CRL into Active Directory you should still use certutil –dspublish instead of certutil –addstore.

How to find out the max size of certificate attributes

MS2065 — Mon, 26 Feb 2007 10:52:00 GMT

The other day I was asked how many subject alternate names will fit into a single certificate. I asked myself what the best way would be to find out. After a short time of thinking I decided to look at the schema defintion of the CA database. The schema will tell for sure how many characters fit into a certain attribute because the database has to store every attribute for a certificate or a request.

So the answer is pretty simple here: There is no limit how many items fit into an attribute but there is a limit regarding the total size.

To determine the max size of a certificate attribut, just run the following command on the CA computer:

certutil -schema

The output shows information about the max. sizes. Once you have this information, just count the number of characters for an attribute in your certificate request an you know if it fits.

Carsten

How to exclude the certificate template name from certificates to be issued

MS2065 — Wed, 03 Jan 2007 15:02:00 GMT

By default, a Windows CA enterprise CA adds information about the used certificate template to issued certificates. These certificate attributes are especially important to perform certificate autoenrollement. However, in heterogeneous environments you may have the requirement not to include the certificate template names in certificates.

To avoid adding the certificate templates information into newly issued certificates, perform the following commands with administrator permissions on your enterprise CA at a command-line:

certutil -setreg policy\DisableExtensionList +1.3.6.1.4.1.311.20.2
certutil -setreg policy\DisableExtensionList +1.3.6.1.4.1.311.21.7
net stop certsvc
net start certsvc

The configuration change applies CA wide and does not affect already issued certificates. Remember that autoenrollment will break if you add the OIDs to the list of disabled extensions. You must not apply this change on a CA where clients enroll certificates automatically from.

To add the template certificate name to issued certificates again, remove the OIDs from the list of disabled extensions. Perform these commands with administrator permissions on your enterprise CA:

certutil -setreg policy\DisableExtensionList -1.3.6.1.4.1.311.20.2
certutil -setreg policy\DisableExtensionList -1.3.6.1.4.1.311.21.7
net stop certsvc
net start certsvc

For a complete List of OIDs used by the Microsoft cryptography, see the following Knowledge base article: http://support.microsoft.com/kb/287547/en-us.

A file distribution point must follow the UNC syntax

MS2065 — Mon, 04 Dec 2006 23:00:00 GMT

Several whitepapers explain the three valid protocols (HTTP, LDAP or FILE) to retrieve a Certificate Revocation List (CRL) or the Authority Information Access (AIA). However, none of these whitepapers is specific about the syntax for the file protocol (file://).

The simple answer is that a CRL or AIA file reference must follow the UNC syntax, for example: \\myserver\myshare\mycrl.crl

Certificates containing an absolute path like C:\myfolder\mycrl.crl will result in an error message when the system is verifying the validity of a certificate.

Carsten