Friday, September 3, 2010

How to generate a self-signed SSL certificate

Secure Sockets Layer (SSL) is great for protecting your users from snoopers, but there are many cases where you want the protection, but you don't want or need the trouble or expense of getting a certificate from one of the big authorities.  For example, you might have an intranet application or an application designed for users inside your company, or you might simply be in the development phase and want to test it with security.  In these scenarios, you can generate your own SSL certificate and get all the security without the cost (though there are some caveats, see below).

How to do it:
  1. Get SelfSSL.exe from the IIS 6 Resource Kit Tools (works with IIS7) or download it from here.
  2. At a command prompt, run: selfssl /T /N:"cn=site name" /K:1024 /S:1 /V:3650

"site name" is the host name you're responding to, e.g. www.mycompany.com or mycomputer.mydomain.com and this must be specific, including the sub-domain, if any.  If you want to use the certificate for multiple sub-domains, you can do so by adding more cn (short for "common name") entries, e.g. /N:"cn=mycomputer.mydomain.com,cn=www.mycomputer.mydomain.com".  Note you might have to set up a DNS entry for the sub-domain.

The /K parameter specifies the byte length of the key. In the example above, you'd get a key that's 1,024 bytes long.

The /S parameter specifies the site to install it for.  E.g. the default IIS website is typically site 1, the second is site 2, etc.

/V specifies the number of days the certificate will be valid for.  In the example above, the certificate will be valid for 10 years.

Now the downside: Because you're generating the certificate yourself, when your users try to access the content they'll get a warning message saying that the certificate is not from a trusted authority and they might be a victim of a phishing attempt.  To combat this, you can export the certificate and install it on the client computers.  This is why you only use these certificates for internal applications or testing.

To Export the certificate:

  1. Go to Start -> Run, enter "mmc" and press the enter key.
  2. Open the File menu and choose "Add/Remove snap in..."
  3. Add the Certificates snap in to the list of selected snap-ins and when prompted, choose to manage certificates for the Computer account.
  4. Click OK to close the Add or Remove Snap-ins dialog.
  5. Expand the Certificates node, then expand Personal and choose Certificates. The certificate you just created should be listed to the right.
  6. Right-click the certificate and choose All Tasks -> Export...
  7. In the certificate export wizard, click Next to skip the welcome screen.
  8. If you simply wish to install the certificate on client machines to avoid the warning, choose "No, do not export the private key".  If you're exporting to back-up the certificate, choose "Yes, export the private key".  Then click Next.
  9. Select the "DER encoded binary X. 509 (.CER)" option (should be the default.  The option will be different if you export the private key and you'll have to enter a password) and click Next.
  10. Enter or browse to choose the path and name of the resulting file then click Next.
  11. View the summary and click Finish.  You should get a dialog saying "the export was successful".  Click OK.
  12. You now have your certificate.  You can email or otherwise distribute this file to your user's machines (If you chose to export the I recommend not emailing pfx files if you exported the private key since emailing is not usually secure).

To install the certificate on the client machine, simply double-click the file and click the Install Certificate button.  It should work if you choose the "Automatically select the certificate store based on the type of certificate" option, but if that doesn't work, try placing the certificate in the "Trusted Root Certification Authorities" store.

Note: If you get an error message saying "Failed to generate the cryptographic key", please check the security settings of your MachineKeys folder and make sure you have write permissions. For Windows Vista, Windows 7, and newer versions of Windows Server, this folder is located at C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys. You might also try running the command prompt as an administrator.

Note: If you get an error message saying "Failed to build the subject name blob", make sure you specified "cn=" for every common name specified in the /N parameter.

Further reading:

Monday, August 30, 2010

Granting permissions to the ApplicationPoolIdentity

Windows 7 and Windows 2008 RC 2 introduced the concept of managed service accounts and by default, application pools are set to use a managed service account in order to isolate the web application pool without adding additional management of passwords and such.  The downside is that the implementation is half-baked when it comes to giving these accounts permission to other things such as accessing files or directories.

The trick is, when setting the security for the file or folder, select your computer as the location then enter IIS APPPOOL\ApplicationPoolName as the user where ApplicationPoolName is the name of the application pool you want to give permission to.  Microsoft really should make these accounts show up in the GUI, but at least this little trick works.

Friday, August 20, 2010

Why Does Video Cost so Much?

After reading this article about YouTube starting to charge around $5 for certain independent films, I started wondering why it's so expensive to purchase video content instead of music. Don't get me wrong, I think most music is overpriced (most songs went to $1.29 as soon as iTunes allowed them to raise the price from $.99), but from a value proposition, I don't see why video is worth 5 times as much as a song. Sure, bandwidth costs and file sizes are larger due to the inclusion of video and it costs more to produce a video in the first place, but on the other hand, I and most consumers will watch a video once in my lifetime whereas I'll listen to a song multiple times and continue to listen to it throughout my life (assuming it's a good song of course). Is a half-hour show I'll watch once really worth $3.99 (especially when it was originally broadcast over-the-air for free)?

Tuesday, March 23, 2010

How to copy from the GAC

If you're not a .NET developer, you probably don't care.  If you are a .NET developer, you've likely had some case where you've got an assembly installed on your development machine, but when you deploy via XCOPY or some other means, the target server doesn't have that DLL and you get an error.  Today I found the trick to copying out of the GAC.

The trick is, you can't use Windows Explorer.  Open an administrative command prompt (Right-click, run as Administrator) and CD to C:\Windows\Assembly.  This directory is not how it appears when viewed from Windows Explorer.  It actually contains a number of directories organized by the type of DLLs it contains.

Most .NET DDLs are MSIL compiled and thus are contained in the GAC_MSIL directory.  The DLLs aren't in there either, instead they're in a sub-sub-directory, the first being the name of the DLL without the ".dll" extension and the second being what looks like a version number/public key token (e.g. Microsoft.SqlServer.SqlClrProvider.dll is contained in C:\Windows\assembly\GAC_MSIL\Microsoft.SqlServer.SqlClrProvider\10.0.0.0__89845dcd8080cc91).

The easiest way to find your particular DLL is to use the DIR command repeatedly.  You then want to use the COPY or XCOPY commands to copy the DLL somewhere else.

Happy Coding!