posted
08/03/10
By Fredrik "DXter" Jonsson
A funny thought that I have had since I connected my girlfriends Wii to my wireless guest network, was that the Wii described my guest WLAN as a “Secure access point” (which is protected by WPA-PSK). How can the Wii present the networks security status by looking on what encryption that is enabled? Regardless of what encryption or authentication requirements you have for your WLAN, they won’t help you from ARP-spoofs for example (when you are connected) which is within the boundary of the networks security. 
Furthermore, for me, it is impossible to make a access point secure using preshared keys. A “secure WLAN” requires PKI, at least for server verifications using PEAP-TLS, but preferably with client authentication using certificates by EAP-TLS (just like my “production” WLAN 
).
Of course, I understand that a Wii console is made for home environments. But the main question is still very interesting and remains unanswered;
What is a secure access point? 
// Fredrik “DXter” Jonsson
posted
07/03/10
By Fredrik "DXter" Jonsson
How many people out there knew that the command line tool signtool.exe in the .NET SDK actually had a built in GUI wizard? (yes, geeks/developers enjoys wizards sometimes too) 
If you have the .NET Framework SDK 2.0 installed, you can launch the wizard by running: “%programfiles%\Microsoft.NET\SDK\v2.0 64bit\Bin\signtool.exe signwizard” (on a 64-bit installation)
I just had to try this one, so I started by creating a self signed code signing certificate in my certificate store with the command “makecert.exe -ss My -r -a sha1 -n "E=dxter@ghostzone.net,CN=Fredrik DXter Jonsson" -eku 1.3.6.1.5.5.7.3.3”. And after that, I added the certificate that was created to my trusted roots store. Now, lets go through the wizard!
The wizard starts.
I select a binary I have made.
I select a typical signing.
I choose to select a certificate from my certificate store.
I select my self signed code signing certificate. The wizard only display’s code signing certificates (with the EKU 1.3.6.1.5.5.7.3.3). For example, my personal S/MIME certificate is not displayed here.
I click next after I have selected my certificate.
I choose to add some descriptions to my cool application.
I prefer to timestamp my signature as well, so I let VeriSign take care of that.
And now we are done!
Yeah!
If we take a look at the properties of our signed file, we now see that we have a digital signature…
… that is valid and that has a countersignature from VeriSign!
I guess nobody can blame signing difficulties anymore as a reason not to sign. However, since I DON’T recommend to use self signed certificates in production, I believe that the price for a commercial code signing certificate is still a show stopper for small projects.
// Fredrik “DXter” Jonsson
posted
03/03/10
By Fredrik "DXter" Jonsson
If you are running a Windows Server 2008 web server for CRL publishing purposes, you should be aware of the fact that Windows Server 2008 (or IIS 7.0 to be more specific) does not allow URL’s with plus signs by default. Delta CRL’s are using a plus sign in the filename to indicate that they are a Delta CRL of the Base CRL with the same name but without a plus sign in the filename.
If you are hosting your CRL’s in the default website on a IIS 7.0 on Windows Server 2008, you should run the following command in an elevated cmd prompt to be able to allow IIS to make your Delta CRL’s accessible. If you are publishing them in another IIS site, customize the site name in the command to your site.
%windir%\system32\inetsrv\appcmd set config "Default Web Site" -section:system.webServer/security/requestFiltering -allowDoubleEscaping:true
UPDATE: Shay Levy was kind enough to provide the PS equivalent below. Thanks a lot!
Set-WebConfiguration -Filter system.webServer/security/requestFiltering -PSPath ‘IIS:\sites\Default Web Site’ -Value @{allowDoubleEscaping=$true}
// Fredrik “DXter” Jonsson
posted
25/01/10
By Fredrik "DXter" Jonsson
Today I had to troubleshoot certutil. Not a big deal, it was about a removal of a certificate from a smartcard. Usually this takes about 5-15 seconds depending on the method you are using, but today when I helped my boss Mats with his smartcard, certutil didn’t work as expected, and I had to troubleshoot for several minutes.
The funny thing was that the command I have been using MANY times, didn’t work. The command to remove a certificate from a smartcard that is using the Base CSP is certutil -delkey -csp "Microsoft Base Smart Card Crypto Provider" "id" (replace “id” with your key container).
However, depending on if this command was copied from a chat/e-mail or not, the output of the command differed. Kind of funny actually.
certutil -delkey -csp "Microsoft Base Smart Card Crypto Provider" "id" working (but canceled by me).
certutil -delkey -csp "Microsoft Base Smart Card Crypto Provider" "id" not working (and says that it has too many arguments).
I copied both text strings to notepad and couldn’t see any difference.
My dear friend, the developer Mattias Åslund, mentioned to me later that Microsoft Word could do these things sometimes and do formatting changes that are “hidden” for the cmd console, so I decided to try to copy the text strings into Word.
Just as expected! Word revealed the hidden formatting of the lower line!
After a replacement of the – manually in the cmd console, everything worked fine and my boss could remove his certificate again.
Perhaps I should do like my dear friend Chrisse says and use certutil /delkey /csp "Microsoft Base Smart Card Crypto Provider" "id" instead, to be able to avoid these issues in the future?
// Fredrik “DXter” Jonsson
posted
23/01/10
By Fredrik "DXter" Jonsson
In my post Smooth root certificate deployment for mobile devices I explained how to distribute your root certificates as .cab files for mobile devices. This post will go through how we distribute root certificates as .exe files for external users and computers.
We start by creating a folder. We call it cer_as_exe and here we put our root certificate that we want to distribute and a small installation script.
Our installation script is not that big.
@echo off
certutil -addstore -f -enterprise -user root %tmp%\root_ca.cer > NUL
del /F %tmp%\root_ca.cer > NUL
del /F %tmp%\install.bat > NUL
This is a very small script that installs a root certificate from a file to the root certificate container in the certificate store for the computer and the user. Then it does a quick cleanup by removing the original root certificate file and installation script that is unpacked in to the %tmp% folder by our installer. Now we need to pack everything as an .exe file that will install our root certificate automatically.
We choose to add our files to archive (using WinRAR).
We select to create a self extracting archive.
We put the following options for the installer under the comment tab.
Path=%tmp%
SavePath
Setup=%tmp%\install.bat
Silent=1
Overwrite=1
We basically tell the installer to extract the files to the users temp path (and overwrite existing files if necessary) and then execute our installation script that does the import as silent as possible. If we want to do modifications such as using a custom icon, etc, we can specify this in “SFX options” under the Advanced tab.
Press OK and now we have a small .exe file that will do the import completely unattended.
Please remember that since the script does not only add the root certificate to our user, but also to our computers certificate store (a system wide change), administrative privileges are required to be able to run this file. You don’t want to add the certificate to the computer store? Then just remove the –enterprise switch from the installation script and it will import the root certificate only the the users certificate store without the need for any elevation at all.
// Fredrik “DXter” Jonsson
posted
19/01/10
By Fredrik "DXter" Jonsson
Not something that you see everyday.
// Fredrik “DXter” Josson
posted
18/01/10
By Fredrik "DXter" Jonsson
Since last year, I have been using a VeriSign S/MIME certificate to be able to digitally sign all my outgoing e-mail messages to be able to prove my identity to other people and make it possible for others to easily e-mail me sensitive data by encrypting the e-mail messages (and attachments).
If you are using an internal ADCS PKI for S/MIME certificates in your Active Directory environment, your public key for your certificate is automatically populated as an attribute for your user object in the global address list, which is very sweet since everything is done automatically! If you use external S/MIME certificates, these can be imported to the users published certificates by using certificate mappings on a per user level. It’ works just fine, but it needs more administration. The cool thing is that as soon as Outlook recognize that a specified recipient that your are mailing with has a S/MIME certificate, the certificate of that recipient is automatically copied into a container in your users certificate store called “Other People” in certmgr.msc. (The container is called AddressBook if you are browsing the certificate store with PowerShell.)
If we take a look at my “Other People” container, I see two other certificates that are used by my dear friend Jonas and my boss Mats. However, I have NOT imported them into that container! Outlook has done that for me automatically!
If we query our container in our certificate store with PowerShell, using “Get-ChildItem cert:\CurrentUser\AddressBook”, we get the same output in our PowerShell prompt.
Now what is the point of this? Well, since the S/MIME certificates are stored in our certificate store, Outlook will always be able to send encrypted messages to those recipients by encrypting the message with the public key in their S/MIME certificate (which is decoded by themselves later using their associated private key). The cool thing is that if you choose to change your e-mail client, the S/MIME certificate store will be available to that client as well. The only thing that e-mail client needs to do is to query the “Other People” container in your certificate store to get a list of all S/MIME enabled recipients.
// Fredrik “DXter” Jonsson
posted
16/01/10
By Fredrik "DXter" Jonsson
Today, me and Dalle have had an entire day of coding, here at my place in Västerås. Dalle arrived this morning and we have been working all day with some new stuff in PKI ToolBox. Two new tools that are soon done:
A graphical, complete and user friendly ADCS Backup & Restore Tool
Since the integrated graphical backup and restore wizard in Active Directory Certificate Services can NOT backup the CA configuration or the CA Policy, we have decided to create our own, easy to use, backup and restore tool that can do a complete backup and restore of a Active Directory Certificate Services. Of course, you can select exactly what you want to backup or not if you don’t want everything. The cool thing with this tool is that even it is by definition "a “third party tool”, it is still using certutil behind the scenes, so it is still doing backup and restore according to Microsoft’s best practices.
A Smart Card Import Tool
We are working on a graphical user interface for imports of PFX/P12 files to smart cards. The tool has a built in ability to do necessary CSP configuration to enable or disable imports to smartcards and the tool also automatically checks if CSP configurations are necessary and if you have privileges to do the import. We are primary coding against the Base CSP so imports to any mini driver based smartcard should work out of the box without any reconfiguration. You want to use another CSP? Hey man, its a PowerShell file (in other words, a text file), just edit it! Since all the tools in the PKI ToolBox are licensed under GPL v2, we even encourage modifications and redistribution of our PowerShell code.
Stay tuned!
// Fredrik “DXter” Jonsson
posted
15/01/10
By Fredrik "DXter" Jonsson
Many people, may think that the topic for this post sound pretty easy. People seems to think that the only thing that needs to be done to distribute the Base CSP for Windows XP/Windows Server 2003, is to search for it and approve it, just like any other update. (Operating systems after XP/2003 has already the Base CSP built in). An administrators dream would be just to approve it, but right now, we don’t live in a perfect world.
If we search for KB909520 in WSUS, which is the Base CSP’s KB number, we actually get nothing in return when we search for it! 
(And yes, this WSUS server is fully synchronized and is synchronizing all updates in all categories.)
So what should we do? Well, since the Base CSP doesn’t exist in our WSUS server, but it does on Microsoft Catalog, we need to import it to our WSUS server from Microsoft Catalog. This is done by right clicking on the WSUS server in the WSUS Console and choose “Import Updates…”
This opens up Microsoft Catalog in a browser. You can search for “KB909520”, add the CSP for all architectures to your basket and then view your basket. Here is the cools stuff: You can actually import the Base CSP from Microsoft Catalog straight to WSUS with a single click!
Just click on the import button and after a few seconds, the updates will have been imported into WSUS.
Now, lets try to search for KB909520 again in WSUS.
We select all architectures, right click on them and choose approve.
We approve the update for all computers and let all the child groups inherit the approvals.
And now we are done.
Now our WSUS server will download the Base CSP for the x86, x64 and ia64 architecture from Microsoft, which is about a total of 3 MB together for all three architectures. It will be installed on our machines that doesn’t have it installed at the next scheduled patching.
// Fredrik “DXter” Jonsson
posted
11/01/10
By Fredrik "DXter" Jonsson
Since I am very active user and moderator for the Certificate and PKI section on ITProffs.se (Sweden’s largest community for professionals in the IT industry), I see a lot of things regarding what people usually don’t know regarding PKI and ADCS. A quite common question is backup and restore of ADCS, which not the least comes to peoples attention in migration or upgrade scenarios.
Many people seems to think that if they backup the CA’s certificate (with private key) they are all right and don’t need to worry any more. However, that is not true! The certificate and it’s associated private key are indeed the CA’s identity and we backup the identity of our CA by backing up our certificate. But we need to backup more things than just that!
1. As mentioned, we need to backup the CA’s certificate and associated private key. To keep it simple, use “certutil –backupupKey”. However, if you use a HSM or store your CA’s keys on a Smart Card, the “certutil –backupupKey” command will fail since the private key can not be extracted. In those scenarios, please consult your HSM specific software/CSP/documentation. Regarding CA’s with their keys on Smart Cards, I recommend people to generate the keys outside of the smartcard, archive the keys and then import them on the smartcard. (A guide to enable this for the Base CSP can be found here) If you generate your CA’s key pairs straight on the smartcard you will never be able to restore your CA’s keys if you get a card failure!
2. Another very important thing to do is to backup the database and log files for ADCS. Since I like to use certutil, “certutil -backupDB KeepLog” will help us with that task. People usually don’t understand the value of having a fresh copy of the ADCS database, but if I explain it simple: If the CA doesn’t keep any track of which certificates that are issued, then they can not be revoked since they “have not been issued”!
3. Backup the ADCS configurations that can be found in the following registry settings: KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration. If you are migrating your CA to another machine and want to change something (like CSP), make all configuration in the registry file before you import it to your target CA.
4. Backup your CA’s policy file. Can be found by default under %WINDIR%\CAPolicy.inf.
5. CRL’s doesn’t need to be backed up. The CA certificates private key + the ADCS database = can generate new CRL’s and Delta CRL’s.
6. Certificate Templates does not need to be backed up since they are stored in Active Directory, not in the CA itself! The only thing you need to do after a migration is to import them again as available templates for that specific CA.
7. If you are doing a ADCS migration, please keep the old CA’s computer account and make sure the new CA is using it. In other words, don’t change the computer name for your CA! If you don’t do this, you will loose all references to your CA in your ACL’s. Another thing you will experience is CRL errors for your previously issued certificates since the old CDP is not available anymore.
Another thing to think about is that the backup itself can be used to compromise the CA, or in worst case, the entire PKI structure! Please handle your ADCS backups with great care! Not only for the CA’s certificate, but also for the database, since it may contain private keys for issued certificates if key archival is enabled!
// Fredrik “DXter” Jonsson
