posted
12/08/10
By Fredrik "DXter" Jonsson
Today, I discovered something that kind of bothered me.
I enrolled a number certificates in my test environment and the BitLocker Drive Encryption EKU (1.3.6.1.4.1.311.67.1.1) was one of the EKU’s present in the certificates. I looked at one of the certificates one of my Windows 7 machines and it looked just fine.
No problems here. A regular certificate with the EKU’s presented to respective application.
However! When I looked at the exact same certificate on a 2008 R2 machine, it didn’t say the same thing:
The Windows Server 2008 R2 machine was not able to translate the EKU to the correct application.
EKU’s are normally just numbers in a certificate that are being presented by the UI as their intended purpose. Because of this, the certificate itself is language independent since it is the UI that is translating the content in the certificate (such as EKU’s) to the current users display language.
However, to be able to solve this, I tried to install Desktop Experience on the server, I tried to unlock the drive manually by the cscript manage-bde.wsf, etc, but nothing worked. Whenever I tried to open the BitLocker flash drive that was encrypted with my certificate on my smartcard, it just prompted me for the recovery key for the device, it never asked me about my smartcard.
Eventually, I remembered a “quite important” thing to do on Windows Server 2008 R2. 
I installed the BitLocker Drive Encryption feature in Windows, and then it happened. The “Unknown Key Usage” became known and I could finally unlock my drive with my certificate on my smartcard. 
Sometimes you feel very stupid when the most strangest problems have very simple solutions (especially when you have done it before). Even though I agree with the concept that BitLocker should be installed as a feature on a server, I still think that the EKU for BitLocker should be registered as an application OID in Windows by default, regardless of if BitLocker is installed/used or not, for display purposes. This is the case for other applications that are using certificates. For instance, I can see the “Secure Email” EKU of a S/MIME certificate regardless if I have a e-mail client installed or not. 
// Fredrik “DXter” Jonsson
P.S I want to give many thanks to my dear friends who helped me with many clever troubleshooting ideas. But I want to give special thanks to my dear friend Mattias Åslund at GraFu who borrowed me the physical server to use for this test this evening, and for even driving it to my place for me! You are a real pal man! Thanks a lot! 
D.S
posted
10/07/10
By Fredrik "DXter" Jonsson
Yesterday I created this little script and I wanted to share it with you guys.
Now that PKI View is removed from KB889250, some people has asked me how to remove all references to old PKI structures in Active Directory in a easier way than just LDAP. Even though AD cleanup is a standard procedure regarding CA decommission, many people are not aware of that and some people seems to just remove the ADCS role and think “that’s it!”. 
So yesterday I created a little script to do this AD cleanup automatically. It is using the Active Directory PS-Drive and the Remove-ADObject cmd-let that is provided by the Active Directory PowerShell Module that comes with Windows Server 2008 R2. Since the Active Directory PowerShell Module is using the Active Directory Management Gateway Service, make sure that at least one of your DC’s have it installed or is running on Windows Server 2008 R2. The idea of the script is to use it after a decommission of a single Enterprise Root or if you want to make sure that no old PKI stuff exists in Active Directory before you install a new PKI structure. This script removes ALL existing references to internal PKI’s and CA’s, so use it very carefully! I think that people should use it only after you have decommissioned your last CA or before you install your first.
The first screen is presenting what the script will do.
A final warning before continuing to delete stuff. 
The script is prompting for credentials using the Get-Credential cmd-let.
The script is searching the Public Key Services container in the Configuration partition (for the current domain) for specific PKI related objects that has object classes such as “certificationAuthority”, “pKIEnrollmentService”, “msPKI-PrivateKeyRecoveryAgent”, etc…
All objects that are found are presented and the person that is executing the script has a option to remove the objects that are being presented. The Remove-ADObject cmd-let is doing the deletion of the objects with the credentials that was provided earlier to the credential prompt in the beginning of the script. 
A simple way to verify that everything is deleted correctly is simply to run the script again. If all PKI related objects are gone, the script will say so.
If you think this sounds cool and want to test this in your test environment, the script is available from the download section on http://poweradmin.se/blog/download/?did=4
// Fredrik “DXter” Jonsson
posted
23/06/10
By Fredrik "DXter" Jonsson
One of my favorite Microsoft documents is “Demonstrate NAP 802.1X Enforcement in a Test Lab”. Many people usually ask me how NAP works and it is always nice to be able to give a document as a reference when you are done with spreading the propaganda. 
http://www.microsoft.com/downloads/details.aspx?FamilyID=8a0925ee-ee06-4dfb-bba2-07605eff0608&displaylang=en
The guide has even been updated for Windows 7 and Windows Server 2008 R2. It is a very nice step by step guide (for test environments) so if you haven’t already checked it out, do it!
// Fredrik “DXter” Jonsson
posted
02/06/10
By Fredrik "DXter" Jonsson
Thanks to my post http://poweradmin.se/blog/2010/05/08/pkiview-msc-doesnt-say-the-entire-truth and the great, open and quick communication between myself and Microsoft, PKI View is no longer a part of KB889250, which is the step by step guide for CA decommission. I really salute Microsoft for listening to the communities (such as blogs ) and removes references in KB’s that have unexpected behaviors and may cause confusion for people! Kudos to you guys!
I guess it is back to hardcore, old school stuff again with ldifde.exe, dssite.msc and adsiedit.msc when it comes to CA decommissions, which is just fine with me! 
Who knows? Maybe two guys will make a very nice PowerShell based GUI for managing the Public Key Services container using the Cmd-Lets for Active Directory in Windows Server 2008 R2? Time will tell…
// Fredrik “DXter” Jonsson
posted
08/05/10
By Fredrik "DXter" Jonsson
I guess I am not the only one that usually removes old PKI stuff from the Public Key Container in Active Directory with pkiview.msc.
However, recently I discovered something that kind of bothered me. I was working with a customer of mine, and I was removing some stuff in sites and services regarding a decommissioned DC and I by curiosity open the Public Key Services container to take a look at it. I found three objects in the KRA Container and I decided to take a look at them with pkiview.msc since it presents PKI related objects in Active Directory in a much nice way than Sites and Services. But you can imagine my face expression when pkiview.msc reported the container as empty! 
As you guys must understand, I just had to reproduce this “bug”. 
So this morning, I installed a virtual Windows Server 2008 R2 Standard Edition in a isolated environment and made it a DC for the domain wtf.poweradmin.se.
I also made it an Enterprise Root CA for the same domain. After that, I started by confirming that the KRA object was located in that container. There are multiple ways to look at the PKI information in Active Directory but I decided to use five of them for this test.
I started with adsiedit.msc:
ADSI Edit clearly shows that we have a object in the KRA container.
Then I decided to try dssite.msc:
Sites and Services also displays our object in the KRA container (if we show services nodes).
A third option is to use a LDAP using ldifde:
It writes out entries to a text file, and if we look at that text file…
… we can actually see the same info that both ADSI Edit and Sites And Services has provided us earlier.
Our fourth option is to query Active Directory with the Active Directory Module for PowerShell:
PowerShell also shows us our object in the KRA container.
Now, what does the fifth option, pkiview.msc, say about the KRA container? Well…
… according to Manage AD Containers in PKI View, the KRA Container is empty.
I recommend you guys that have removed objects of decommissioned CA’s with the “Manage AD containers” in PKI View: Look again in the KRA Container with ADSI Edit, Sites And Services, LDAP or PowerShell. You might find something interesting left behind.
Update: http://poweradmin.se/blog/2010/06/02/pki-view-is-no-longer-a-supported-way-for-ca-decommission/
// Fredrik “DXter” Jonsson
posted
28/04/10
By Fredrik "DXter" Jonsson
This morning when I created a web listener, I discovered that TMG did not appreciate my certificate that was issued according to my V3 template with support for CNG and all. (The workaround is to use a V1 or V2 template instead).
A few seconds on the web confirmed this issue, and I found a web site on Microsoft.com with a list of “unsupported configurations”. 
http://technet.microsoft.com/en-us/library/ee796231.aspx
I thought it needed some extra attention, even though I understand that a list of “unsupported configurations” doesn’t really have an end!
// Fredrik “DXter” Jonsson
posted
22/04/10
By Fredrik "DXter" Jonsson
I just found SSLScan-Win which is a Windows port of the open source (GPL v3) project SSLScan.
I try SSLScan.exe against www.fairssl.dk since they already have a SSL test site at https://www.fairssl.dk/ssltest/.
We see all public properties for the certificate such as validity period, thumbprint, CN, CDP, OSCP, etc… Even the EV attributes are clearly shown.
I think this tool will come in handy for everyone that is using SSL certificates for server authentication. Please remember that it is only presenting the public information in the certificate, so it is NOT a hacking tool. It is just presenting public information in a nicer format.
The Windows port of SSLScan can be found on http://code.google.com/p/sslscan-win/
Enjoy!
// Fredrik “DXter” Jonsson
posted
07/04/10
By Fredrik Wall
#PowerShell and #PKI #Blogging
This blog have been active for one year now.
The stats goes back to 27/03/2009.
Over 22 000 unique visitors in one year!
That’s great, thank you all readers and thank you
DXter, my fellow blogger for your great posts!
It seams like PowerShell and PKI is what people likes
Technorati Tags:
Blog,
PowerShell,
PKI
posted
03/04/10
By Fredrik "DXter" Jonsson
I was chatting with my friend Tom Aafloen when he asked me if there was any way to see if a certificate is on a smartcard or not when you are browsing the certificate store. Well, even if you can’t see it in certmgr.msc, the resolution is actually closer than you think my friend.
A quick view of my certificate store doesn’t reveal any information about where my certificates are located.
However, we can actually get that information if we browse our certificate store graphically using my best friend certutil: certutil -viewstore -user My
Now we can see where our certificates are located, thanks to the icon to the left of them.
Certutil.exe is sometimes really my best friend!
// Fredrik “DXter” Jonsson
posted
31/03/10
By Fredrik "DXter" Jonsson
… that is what my girlfriend said to me when she checked our mail at home. Two months ago, Eyal Webber-Zvik, a Project Manager at SCsquare (SC²) contacted me and gave me the offer (and pleasure) to send me a couple of smartcards from his company for evaluation and testing. He mainly just wanted to get some feedback regarding their smartcards from the field and real life from a PKI geek just like myself.
I got a bunch of these Apollo OS Smart Cards which are very cool even at the first sight! An impressive amount of “certified for…” logos. They are actually the first cards in the world to be compliant with version 7 of the Microsoft minidriver specification for the Base CSP and they are also certified for FIPS 140-2 Level 3!
Yes, they are being installed from Windows Update through the smart card plug and play feature in Windows 7, just like the Gemalto .NET cards! That is so cool! We like that a lot!
If I should be honest, it didn’t cross my mind one single time that I hade changed smart cards to these Apollo OS cards during all my tests! They are completely transparent and just as fast and cool just like Gemalto .NET. However, I really like the administrative website that Gemalto provides for free to their .NET card customers. Hopefully SC² will provide something similar to their customers that doesn’t have ILM 2007 (or Forefront Identity Manager 2010 as it is now called).
Another cool feature of these cards is that you can have different PIN’s for Digital Signature, Encryption, Authentication, etc, based on key container, which is awesome!
More info can be found on: http://www.scsquare.com/products/windows-7-and-windows-server-2008-r2-smart-card-minidriver/
Right now, I only see one problem with the Apollo OS cards: I don’t know where to buy them…
// Fredrik “DXter” Jonsson
