Category Archives: PKI

Certificate Request generation for Microsoft Enterprise CA by openssl

Posted on by
2

Long time ago I have written about generating Certificate Signing Requests from non-Windows machines. The main goal was to sign such request by Microsoft Enterprise CA. I have mentioned vSphere infrastructure as an example.
I have been recently asked a similar question. New vSphere versions require Alternative Name Extension to exist in the certificate. The question was how to configure openssl to implement both functionalities.
Reaching the goal was quite simple, but not trivial. We can define several sections containing settings for request extensions, however only one can be used for a specific certificate request generation.
It is a good practice to reorganize an openssl configuration file designed for generating a single server certificate. In this way, we obtain templates for each server instance.
An Example configuration file may look as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
openssl_conf = openssl_init

[ openssl_init ]
oid_section = new_oids

[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ new_oids ]
MsCaCertificateTemplate = 1.3.6.1.4.1.311.20.2

[ v3_req ]
basicContraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:server01, DNS:server01.domena.test
MsCaCertificateTemplate = ASN1:PRINTABLESTRING:VMwareCertificate

[ req_distinguished_name ]
countrName = PL
stateOrProvinceName = Malopolskie
localityName = Krakow
0.organizationName = Firma
organizationalUnitName = Oddzial
commonName = server01.domena.test

Most important parts of the config file are:

  • Line 1. Identifies the global configuration section.
  • Line 4. Identifies the OIDs definitione section. This line is singleton in this section.
  • Line 13. Identifies the Extension definition section. Those extensions will be added to certificate request body.
  • Line 15. Defines OIDs section.
  • Line 16. Defines OID registered and used by Microsoft for marking certificate template extension.
  • Line 22. Defines alternative names of the server. Of course, we can use other than DNS prefixes.
  • Line 23. Defines the name of certificate Template, what is designed to use during signing the certificate. It is important to remember that we need to specify “Certificate Template Name”, as oposite to “Certificate Template Display Name”.

Rest of the file is standard body similar to every single config file designed for generation of requests.

Export/Import ADCS Certificate Templates in Windows 2012

Posted on by
4

Hello,

Todays a few words about importing and exporting certificate template data with Active Directory.
This data is stored within Configuration partition of Active Directory and therefore it is common for whole Active Directory Forest.
But there are also situation, when you would like to move them between forest, for example from pre-production environment to your production one.
It can be done on two different ways. First is obvious, but dirty, and sometime can lead to serious problems with moved Items.
But after Windows 2008 R2 was released, there was introduced new feature – Windows AD CS Web Enrollment Services.
It can be used for cross forest CA publication with only External Forest AD Trust enabled.
More details about those protocols can be found here.
On the mentioned site, there are two great scripts written in powershell, what would export and import Certificate Template data to and from xml files in MS-XCEP format.
However, Those scripts have two bugs and one issue within when running on Windows 2012:

  1. There is some kind of error during using them as normal cmd-lets on Windows 2012. Instead, you should comment out first function declaration and cmd-let binding declaration. After this modification, you can use scripts as normal with additional input, as required.
  2. Export function in one place tries to figure out, if there is one of attributes. The line:
    1
    $superseded = if ($temp.Settings.SupersededTemplates -eq 0) {

    should look as follow:

    1
    $superseded = if ($temp.Settings.SupersededTemplates.Length -eq 0) {

    Just replace it, and scripts will run very well on W2k12.

  3. Last thing is those scripts are depending on external powershell module. As far, as I know, it is possible to remove this dependecy, but it will subject of next post.

Mentioned earlier dirty method is old ldifde command with required flags for export:

1
ldifde -m -v -d cn=%Template1%,%LDAP% -f %Template1%.ldf

Most important part of this command is -m switch, which will result in “forest free” ldf output.
For import you should use the similar command:

1
 ldifde -i -k -f %Template1%.ldf

And this should work from the begining, starting from Windows 2000 Version.

“The AD RMS installation could not determine the certificate hierarchy.” error during AD RMS Reinstall

Posted on by
Reply

There are rare situations, when you have to reinstall the RMS Cluster node. Most common case causing such need is unsuccessfull provisioning process. It usual fails because of really obvious things, such as already binded SSL certificate to Web Site in IIS. After unsuccessfull provisioning task, you have to uninstall whole AD RMS role and after the server restart you can try again with installation. Unfortunatelly sometimes there are the errors during uninstall too. This hidden errors causes subsequent issues during next attempt.
The error cited in post title has several different potential resons and solutions. Most of them is improper registry settings, which stayed after previous install. One thing, what you have to always remember, is that you have to check twice need of every registry change. Inproper registry edition can causes whole server operating system damage.
Namely described error can be caused by one of the following reasons:

  1. Wrong Service Connectin Point – it happens because of improper value in Active Directory container under following path CN=SCP, CN=RightManagementService, CN=Services, CN=Configuration, DC=domain, DC=lab, what point to nonexiting RMS Cluster service URL. More information about this cause you can obtain here. This reason is explicite mentioned in error message shown at the end of role installation wizard.
  2. Second possible issue is described in Application log entry with Log ID 204. This is because of lack of one value in the registry. The mentioned article provides procedure for recreation of missing registry values.
  3. If no of previous solutions helps, I found third one. You need to verify content of following registry hive HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DRMS. If there is any value or key this can cause an error. You have to examine it and remove any value, which is pointing to non existing service URL. After this hive clean up, there should be only one value. This is the (default) one.

If your situation doesn’t follow any of described cases, please fell free to put me message in a comment.

Microsoft Enterprise CA doesn’t allow to publish templates V2 and V3

Posted on by
1

Under some circumstances after installation Windows Enterprise Operating System and configuration of AD Certification Services as Enterprise CA, the CA Services still doesn’t allow publication of certificate templates in versions higher than V1. This is because of misconfiguration of registry entries, which determines type of CA installation as Standard.
Okno Publikacji szablonu
The solution for this problem is proper setup of bit flag in the CA configuration. It can be done with following command:

1
certutil -setreg ca\setupstatus +512

After registry update, there is necessity of restart CA service.
More over, there is possibility of manual edition of the templates list, which is used by CA for certificates enrollment. It is possible by edition of attribute

1
certificateTemplates

in object

1
pKIEntrollmentService

. These objects are available under following path

1
CN=Internal Issuing CA,CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=contonso,DC=lab

Certification Authority Service installation on Windows 2008 R2 Core

Posted on by
Reply

Today I’ll write about something completely new. Certification Authority Services, called AD CS (Certification Services) was added to the Windows Core distribution only in the R2 release. Windows Core themself was introduced as an installation option in the Windows 2008 release.
There is a lot of materials covering the Core installation, so I won’t describe it wider. For example, I suggest to read this Nataniel Zieliński’s article. For the moment, it is enough to know, that there is almost no graphical user interface. The system is managed from command promt. There is also very good Getting Started Guide what can help start up with Core installation, but most of new features introduced in R2 relase are still poorly documented.
The CA server installation requires using Add Role Creator on regular Windows 2008 R2, which is unavailable under Core version. So the first step is installation of service’s binaries. It can be done with following command:

1
start /w ocsetup.exe CertificateServices /norestart /quiet

Next really usefull step is to check corectness of installation. We can do that typing the following in the command prompt:

1
oclist find /i "CertificateServices"

After getting sure, that we have whole service’s package, we need to configure it. It can be done with VBScript program, which performs the automatic installation. It is available under following link. This script can help us avoid our headaches through simple and quick installation of our CA Service. But we still need to provide set of parameters which regulates its work. Full set of possible switches is provided on the script’s web page. Here, we need to pay attention that parameters:

1
/interactive

and

1
/iw

are not supported under Core installation.
Moreover, before performing CA Service installation process in Core as well as Regular distribution we need to prepare the CApolicy.inf file, what must be placed under %SYSTEMROOT% directory. There is example code of such file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
[Version]
Signature="$Windows NT$

[PolicyStatementExtension]
Policies=LegalPolicy

[LegalPolicy]
OID=1.1.1.1.1.1.1.121

NOTICE=Certificate issued under Test CA Policy
URL="http://pki.test.domain.lab/repozitory/cps.html"

[certsrv_server]
renewalkeylength=2048
RenewalValidityPeriodUnits=5
RenewalValidityPeriod=years
CRLPeriod=days
CRLPeriodUnits=14
CRLOverlapPeriod=days
CRlOverlapUnits=7
CRLDeltaPeriod=hours
CRLDeltaPeriodUnits=0

After the installation it is worthy to set up CDP (CRL Distribution Point) parameters with following commands:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
certutil -setreg CA\DSConfigDN CN=Configuration,DC=DOMAIN,DC=LAB
certutil -setreg CA\CRLPeriodUnits 14
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLOverlapPeriod "Days"
certutil -setreg CA\CRLOverlapUnits 7
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod "Hours"
certutil -setreg CA\CRLPublicationURLs "65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n79:http://pki.test.domain.lab/repozitory/%%3%%8%%9.crl\n65:file://\\%%1\CertEnroll/%%3%%8%%9.crl"
certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n3:http://pki.test.domain.lab/repozitory/%%1_%%3%%4.crt\n1:file://\\%%1\CertEnroll/%%1_%%3%%4.crt"
certutil -setreg CA\AuditFilter 127
certutil -setreg CA\ValidityPeriodUnits 2
certutil -setreg CA\ValidityPeriod "Years"
net stop certsvc & net start certsvc
certutil -crl

Creation of such, or simillar script will help us ommit of “clicking off” Certificate’s parameters under remotely connected Management Console. At the end I would add, that the first article what helped me with start working with CA Services on Windows Core was this Eyalestrin’s article.