Manually create certificate signing requests

It's been quite a while since my last post due to different reasons. :-)
Today I would like to show you how to manually create a certificate signing request (CSR).

The Internet Information Server (IIS) and many other applications which make use of or require certificates provide wizzards in the administration user interface to request and install certificates.

I would like to explain two different ways how to request a certificate manually. The manual steps are required if web enrollment is not available, the current logged on user or computer has no enroll permissions on a certificate template or the certification authority (CA) is not available (e.g. no Active Directory integrated Enterprise CA or not in the same forest as the leveraging computer)

Method 1 – Use certreq to create a CSR and certreq to issue the certificate

1. Creating an INF file to set the certificate properties

Use Notepad or any other text editor to create the following sample INF file according to your needs. Safe the file as myCSR.inf for example

[Version]
Signature="$Windows NT$"

[NewRequest]
Subject = "CN=MyServer.christianlechner.blogspot.de" ;For a wildcard use "CN=*.christianlechner.blogspot.de" for example

; For an empty subject use the following line instead or remove the Subject line entierely
; Subject =

Exportable = FALSE                  ; Private key is not exportable KeyLength = 2048                    ; Common key sizes: 512, 1024, 2048, 4096, 8192, 16384
KeySpec = 1                         ; AT_KEYEXCHANGE
KeyUsage = 0xA0                     ; Digital Signature, Key Encipherment
MachineKeySet = True                ; The key belongs to the local computer account
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
SMIME = FALSE
RequestType = CMC

; At least certreq.exe shipping with Windows Vista/Server 2008 is required to interpret the [Strings] and [Extensions] sections below

[Strings]
szOID_SUBJECT_ALT_NAME2 = "2.5.29.17"
szOID_ENHANCED_KEY_USAGE = "2.5.29.37"
szOID_PKIX_KP_SERVER_AUTH = "1.3.6.1.5.5.7.3.1"
szOID_PKIX_KP_CLIENT_AUTH = "1.3.6.1.5.5.7.3.2"

[Extensions]
%szOID_SUBJECT_ALT_NAME2% = "{text}dns=computer1. christianlechner.blogspot.de&dns=computer2. christianlechner.blogspot.de"
%szOID_ENHANCED_KEY_USAGE% = "{text}%szOID_PKIX_KP_SERVER_AUTH%,%szOID_PKIX_KP_CLIENT_AUTH%"

[RequestAttributes]
CertificateTemplate= WebServer

Notes:

If you don’t know the template name or want to specifie it when issueing the certificate, remove the RequestAttributes section.

The specification of the enhanced key usage OID is not explicitly required since the EKU is defined in the certificate template. The OID in the INF file above is for explanatory purposes
You can click on “OK” for the template not found UI from certreq if the client has no access to templates.

You can ignore the unreferenced “[Strings]” section dialog when it appears

2. Useing the INF file when creating the REQ file

The following command-line command will generate key material and turn the INF file into a certificate signing request (CSR) which can then be handed over to the CA to issue the certificate.

certreq –new MyCSR.inf CSR.req

Once the certificate request was created you can verify the request with the following command:

certutil –dump CSR.req

3. Submitting the REQ file to the CA

If the CA is reachable via RPC over the network (computer and CA are member oft he same Active Directory domain and computer or user hast he permissions to enroll a certificate), use the following command to submit the certificate request directly to the CA:

certreq –submit CSR.req

You will get a selection dialog to select the CA from. If the CA is configured to issue certificates based on the template settings, the CA may issue the certificate immediately.

If RPC traffic is not allowed or the CA is not member of the same Active Directory or maybe not a Windows based CA, transfer the certificate request to the CA and perform the above command locally at the CA (if it is a Windows CA otherwise you the respective command on the Linux/Unix based CA).

If the certificate template name was not specified in the certificate request above, you can specify it as part of the submission command:

certreq -attrib "CertificateTemplate:webserver" –submit CSR.req

4. Installing the certificate at the IIS or ISA computer

Once the certificate was issued copy it to the target computer. Run the following command to install the certificate.

certreq –accept ssl.cer

The installation actually puts the certificate into the computer’s personal store. The certificate will be linked to the key material created in step #1 and builds the certificate property. The certificate property stores information such as the friendly name which is not part of a certificate itself.

After performing steps 1 to 4 the certificate will show up in the IIS or any other application and can be bound to the application or a website.

Method 2 – Use the MMC to create a CSR

Open the MMC and add the „Certificates“ snap-in. Open the „User“ or „Computer“ store depending on your required certificate.

Under „Advanced Operations“ select „Create Custom Request“.

Confirm the „Before you Begin“ page by clicking „Next“.

Click „Proceed without enrollment policy“ on the „Select Certificate Enrollment Policy“ page and click „Next“.

Depending on the use case select „CNG key“ or „Legacy key“ on the „Custom request“ page and click „Next“.

Open the „Properties“ window from the „Certificate Information“ page to enter all required certificate properties to the request.

After you’ve entered all required properties (e.g. SubjectName, Organization, Key length, …) finally click „Next“ and save the CSR somewhere.

You can now submitt the CSR according to method 1 or directly via MMC on the CA itself.

Have fun

Chris

Active Directory Property Sets and Default Security Descriptors

Every object class definition in the Active Directory schema has the option to define a “defaultSecurityDescriptor” value which holds the initial ACL that will apply to any new instances of that object when they are created. This rule doesn’t hold true if you specify a security descriptor explicitly when creating an object, however, as in this case the defaultSecurityDescriptor will be ignored.
The default value for the defaultSecurityDescriptor for the user class has a couple of entries in it which most administrators don’t know about, and fortunately neither do many end users. Out of the box, the user which an object in AD represents has the permissions to modify quite a few attributes on their own account. Anyone who can figure out how to make an LDAP call against their object in the directory or can use the Active Directory Users and Computers snap-in can take advantage of this. The easiest way to edit or view the value for this attribute is using the Active Directory Schema MMC.
By default the Active Directory Schema MMC snap-in is not available on a domain controller or any member server or client computer with the RSAT tools installed. To use it you must first register the COM DLL it depends on by running “regsvr32 schmmgmt.dll” from an elevated command prompt. Once you have done this, you will be able to open a new MMC and go to File->Add/Remove Snap-ins and add the Active Directory Schema snap-in to your console.
Browse to the Classes folder and then open the properties of the user class. Switch to the Default Security tab and click Advanced.
If you sort the list on the Name column and scroll down to SELF, you’ll see three entries (highlighted in red below) which are interesting for this article:

These three ACEs grant the user permissions to write to the attributes in those three property sets for their account. (personal information, phone and mail options and web information) If you’re not familiar with Property Sets, they’re a construct that allows you to group attributes and apply security for all the attributes in a single ACE which applies to the property set. An easy way to get a nice list of the attributes in these property sets is with the tool adfind. You can download adfind on the following webpage http://www.joeware.net/freetools/tools/adfind/index.htm. Now that we’ve got adfind we need to convert the friendly display name (e.g. Personal Information) into the GUID of the property set. We need to do this with the other two permissions as well.

adfind -sc findpropsetrg:"Personal Information"

You should get a result similar to this:

AdFind V01.37.00cpp Joe Richards (joe@joeware.net) June 2007

Using server: DC01.intern.lechner-online.net:389
Directory: Windows Server 2003
Base DN: cn=extended-rights,CN=Configuration,DC=inter,DC=lechner-online,DC=net

dn:CN=Personal-Information,CN=Extended-Rights,CN=Configuration,DC=inter,DC=lechner-online,DC=net
>rightsGuid: 77B5B886-944A-11d1-AEBD-0000F80367C1

You can paste the found GUID into a second adfind command to list all of the attributes in the property set that are writeable by the user itself:

adfind -sc propsetmembersl:"77b5b886-944a-11d1-aebd-0000f80367c1"

Depending on your Active Directory schema and maybe preceded changes, your results might vary a bit:

assistant
c
facsimileTelephoneNumber
homePhone
homePostalAddress
info
internationalISDNNumber
ipPhone
l
mobile
mSMQDigests
mSMQSignCertificates
otherFacsimileTelephoneNumber
otherHomePhone
otherIpPhone
otherMobile
otherPager
otherTelephone
pager
personalTitle
physicalDeliveryOfficeName
postalAddress
postalCode
postOfficeBox
preferredDeliveryMethod
primaryInternationalISDNNumber
primaryTelexNumber
publicDelegates
registeredAddress
st
street
streetAddress
telephoneNumber
teletexTerminalIdentifier
telexNumber
thumbnailPhoto
userCert
userCertificate
userSharedFolder
userSharedFolderOther
userSMIMECertificate
x121Address

If you’ve got an automated system that populates any of these attributes (e.g. an identity management system like Microsoft FIM2010 or SAP Netweaver Identity Manager), hypothetically an end user could put other data in them and start breaking processes. I’ve only ever heard once or twice of this happening, and I’m not fully aware of all the implications of removing these ACEs if you wanted to prevent the possibility. Keep in mind that this is applied as an individual ACE to each user as it’s created, so, in order to clean this up in an existing forest you’d need a script to go through and remove the ACEs from each user individually. New users would get the updated defaults based on modifying the defaultSecurityDescriptor of the user class, though.

Have fun
Chris

Userfull Powershell Scripts

Hi there,
you can download some helpfull Exchange Powershell Scripts on my Google Page.
http://sites.google.com/site/chrislechn/powershell

I'll upload more scripts later on.

Enjoy the scripts and please leave a comment if you like them.

Chris

Change Exchange NDR message language

When Exchange needs to send a NDR message it will by default try to detect the language of the received message and send the NDR back in the same language. In my case it should be send in Spanish because the customer is Spanish and the Exchange is hosted Germany and installed with English language.

Sometimes it will not be able to detect the language of the received message and therefore sends the NDR in the language that is default for the configuration.

To set the default NDR language you have to run a PowerShell command.

Use the following command to set the default language to English for NDRs

Exchange 2007

NDRs for mails received from external domains:

Set-TransportServer <HubTransportServerName> -ExternalDsnDefaultLanguage en-us

And for NDRs for mails received from internal domains

Set-TransportServer < HubTransportServerName > -InternalDsnDefaultLanguage en-us

The setting has to be set for every transport server in your exchange organization.

Exchange 2010

In exchange 2010 it only has to be set once for the whole Exchange 2010 organization. This is why I love Exchange 2010.

NDRs for mails received from external domains:

Set-TransportConfig -ExternalDsnDefaultLanguage en-us

And for NDRs for mails received from internal domains

Set-TransportConfig -InternalDsnDefaultLanguage en-us

If possible you should always user automatic language detection.

The automatic detection of language for NDR can be enabled by running the following commands:

Exchange 2007

Set-TransportServer < HubTransportServerName > -ExternalDsnLanguageDetectionEnabled $true

and

Set-TransportServer < HubTransportServerName > -InternalDsnLanguageDetectionEnabled $true

Exchange 2010

Set-TransportConfig <OrganizationIdParameter> -ExternalDsnLanguageDetectionEnabled $true

and

Set-TransportConfig <OrganizationIdParameter> -InternalDsnLanguageDetectionEnabled $true

This is the regarding article from Microsoft

http://technet.microsoft.com/en-us/library/bb124151.aspx

Have a nice day…. I hope this will help somebody.

Chris

Powershell script to change Exchange mailbox alias

Hi all...

during a migration project I got Exchange mailbox aliases like this Lechner?Christian.
This was caused by the fact that a mailbox alias can not contain any spaces or a comma. The alias was generated by our migration tool, based on the user displayname.

I wrote a small script to change the mailbox alias to the samAccountName of the user.

foreach ($mbx in (Get-Mailbox -filter {Alias -Like '*'})) {Set-Mailbox $mbx -Alias $mbx.samaccountname}

You can save the script as changeAlias.ps1 and run it directly from the Exchange Powershell.

This is nothing special but I hope it can helps...
Chris

How to enable SAN certificate issuing on a Windows CA

The following post is more for me than for public. :-)

Exchange Server 2007 and Exchange Server 2010 heavily rely on certificates for the secure communications between servers and clients.

When you decide to go with a third party CA for certificate requirements you need to pay them depending upon their pricing and almost every year or depending upon your subscription.

To avoid paying money for a third party CAs yet to keep your communications secure most of the companies prefer to deploy their own internal CAs. After you have deployed your internal CA one of the problems you normally face is with issual of a certificates that contains multiple subject names (Subject Alternative Name). Both Windows Server 2003 and Windows 2008/R2 are NOT configured to issue SAN certificates by default. The default policy module that is configured during the installation of the CA keeps it disabled by default.

To allow our Windows CA issual of certificates to the requests that contain Subject Alternate Name extension you must enable it using the CERTUTIL.EXE tool on the CA.

To enable SAN certificate issual on the CA you can follow below steps:

1. Open command prompt with elevated privilleges or an user credentials that have permissions to manage CAs.

2. Run the command certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

3. This command changes the values of EditFlags and adds SubjectAltName in registry located at SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<Server Name>\PolicyModules\C

ertificateAuthority_MicrosoftDefault.Policy

and the output looks like below: (Please note that the values on your CA may be different than what they look like in following example)

C:\>certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<Server Name>\PolicyModules\C

ertificateAuthority_MicrosoftDefault.Policy\EditFlags:

Old Value:

EditFlags REG_DWORD = 11014e (1114446)

EDITF_REQUESTEXTENSIONLIST — 2

EDITF_DISABLEEXTENSIONLIST — 4

EDITF_ADDOLDKEYUSAGE — 8

EDITF_BASICCONSTRAINTSCRITICAL — 40 (64)

EDITF_ENABLEAKIKEYID — 100 (256)

EDITF_ENABLEDEFAULTSMIME — 10000 (65536)

EDITF_ENABLECHASECLIENTDC — 100000 (1048576)

New Value:

EditFlags REG_DWORD = 15014e (1376590)

EDITF_REQUESTEXTENSIONLIST — 2

EDITF_DISABLEEXTENSIONLIST — 4

EDITF_ADDOLDKEYUSAGE — 8

EDITF_BASICCONSTRAINTSCRITICAL — 40 (64)

EDITF_ENABLEAKIKEYID — 100 (256)

EDITF_ENABLEDEFAULTSMIME — 10000 (65536)

EDITF_ATTRIBUTESUBJECTALTNAME2 — 40000 (262144)

EDITF_ENABLECHASECLIENTDC — 100000 (1048576)

CertUtil: -setreg command completed successfully.

The CertSvc service may need to be restarted for changes to take effect.

4. Restart certification services using services manager snap in or command prompt. net stop certsvc && net start certsvc

5. Once the service is restarted you can request a certificate with SAN extension using web enrollment application.

Warning! You should not enable SAN extension support on your Enterprise Root CA. If you must enable it, it must be on one of the standalone CAs dedicated for issuing SAN certificates.

Office 2010 activation process in a terminal server environment

This week I was working with a customer on his Lotus Notes to Exchange migration project. Almost all of his users are working with Thin Clients on Citrix XenApp 5.0 terminal servers. All Citrix servers where deployed using Citrix Provisioning Services and Xen Server as a hypervisor.

He was going to install Outlook 2010 on his master image. The installation was running fine and he was going to change the product key for the Office 2010 activation. He typed in his product key which wasn't very good. From that point every user was asked to activate Outlook or change the product key. This occurred every time a user logged in after the terminal server was rebooted. We figured out that he has typed in his MAK key. When using a MAK key it is necessary to active Outlook for every user "manually" via internet or telephone.

After that I installed the Office 2010 Key Management Host Service on a Windows Server 2008 R2 machine. The Key Management Host for Office hast nothing to do with the Windows KMS service but can be installed on the same machine. You can download the program directly from the Microsoft website. http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=97b7b710-6831-4ce5-9ff5-fdc21fe8d965

If you do like me and try to install the program on a Windows 2008 Server (the customer want me to use Windows 2008 Server, because he had no virtual template of a Windows Server 2008 R2 machine. :-( ) you'll get the following error message.

Office 2010 Key Management Host Service can only be installed on Windows Server 2003, Windows Server 2008 R2 and Windows 7. Windows KMS isn't that particular.

After you've started the installation of the KeyManagementServiceHost.exe you need to accept the typical Microsoft license agreement and the Office license files are automatically installed. You'll be prompted to enter your Office 2010 KMS Host Key which can be found in the Microsoft Licensing (VL) portal. It depends on your Microsoft contract. The Host Key is automatically activated if your machine has got internet access.

No need to type in something like –ipk and –ato as you need to do with the Windows Host Key and the slmgr.vbs script.

If the installation is done and the key is activated you can check the service status for Office with the following command:

cscript slmgr.vbs /dlv bfe7a195-4f8f-4f0b-a622-cf13c7d16864

If you want to see the status information from Windows and Office you can use:

cscript slmgr.vbs /dlv all

Since the introduction of KMS with Windows Vista and Windows Server 2008 there is a minimum activation threshold. That value is the necessary amount of client to start the activation process.

The minimum activation threshold for Office 2010 clients is 5. If you have less than 5 Office 2010 clients you need to use the MAK key for the activation. You can find more information here: http://technet.microsoft.com/en-gb/library/ff603508(office.14).aspx

The initial grace period for Office 2010 is 25 days. If your Office 2010 is not activated after those 25 days you can still use your Office products without any limitation. All you see is a red bar on top of your product and a message box that tells you to activate your product or change the product key.

The Office KMS client key is integrated in the Office 2010 installation. There is no need to enter a KMS client key. But as I mentioned earlier in this post my customer accidently entered his MAK key on his terminal server master image. It was necessary to change the product key back to the KMS client key to activate Office against out Key Management Service Host. We don't want to install Office again!

How can we do that?

First of all we need the Office 2010 client key which can be found here:

This keys are public and can be found here: http://technet.microsoft.com/en-gb/library/ee624350.aspx

I DON'T POST ANY CUSTOMERS PRODUCT KEYS HERE! :-)

We need to change the product key back to the KMS client key now. This is done using the command below on my terminal server.

cscript ospp.vbs /inpkey:xxxxx-xxxxx-xxxxx-xxxxx-xxxxx

I set the Office Key Management Service Host to the FQDN of my server.

cscript ospp.vbs /sethst:KMShost.domain.int

And last but not least I was trying to activate Office with the following command.

cscript ospp.vbs /act

ospp.vbs can be found in the installation directory of Office. Normally it would be something like %ProgramFiles%\Microsoft Office\Office14

Now you can check the activation request by using cscript slmgr.vbs /dlv bfe7a195-4f8f-4f0b-a622-cf13c7d16864 on the KMS server.

That should be it.

Have a nice weekend.

Chris