Every now and then I find that it is necessary to apply self signed SSL certificates when implementing Exchange servers. Self Signed Subject Alternative Name (SAN) Certificates that is, because Exchange uses that kind of certificates since Exchange 2007.
Background
The need for self signed SSL certificates can have different reasons. One of these reasons can be that a company has an internal Windows Active Directory™ DNS domain name, that this company does not own on the internet. As a result, no public Certificate Authority will enroll certificates with this DNS name for you. Another reason could be that you use a TMG/ISA system (or some other reverse proxy) to publish the Exchange environment, in which case it is not necessary to add all Client Acces (CAS) servers to the SAN certificate. On the TMG/ISA server we only need a SAN certificate with the public DNS names in the Exchange organization. Internally we distribute the Self Signed Certificate by means of an Active Directory™ policy, so the Exchange servers are 'trusted' internally.
By default a self signed SSL certificate is created on the Exchange server at install time. The problem with this certificate is that this certificate is not very configurable. You cannot change the 'valid period' for example. It is also possible to use an internal Certificate Authority, if one is available. The disadvantage to this is that the valid period of certificates enrolled by these CA's is limited and can or may not be changed easily.
If you decide to use self signed Certificates for the internal Exchange environment, you probably want a very long valid period, or at least as long as the expected life span of your Exchange environment. An unexpectedly expired self signed SSL certificate can lead to big problems for a company that cannot respond to this quickly. (You can still create a new certificate every year if you want to though, but you don't have to).
SelfSSL
At the time when IIS6 was the latest IIS version, it was simple to create self signed SSL certificates by using selfssl.exe from the Microsoft IIS6 Resource Kit. You could not create SAN certificates with this and selfssl.exe is not supported with IIS7 and higher.
SelfSSL7
In 2010 SelfSSL7 has become available. This is a tool, created by Thomas Deml with which you can create self signed certificates in a way similar to selfssl for IIS6. But SelfSSL7 has more functionality, among which adding multiple DNS names to the SSL certificate. SelfSSL7 can be downloaded from here. SelfSSL7 is not the only tool available to create self signed SAN certificates, but I think it is the most intuitive one.
SelfSSL7 in practice
Imagine, you need a SAN certificate with the following DNS names:
autodiscover.mydomain.local
autodiscover.mydomain.nl
webmail. mydomain.nl
casserver1.mydomain.local
casserver2.mydomain.local
casarray.mydomain.local
With the below command we can create the SSL Certificate and assign it in IIS.
/N - DNS names in the certificate
(Also the name with which i twill be added to the certificates store)
/K - Key Length
/V - Valid time (18250 creates a certificate with a 50 year valid time!)
/I - Configures IIS bindings
/S - Site to configure
/P - Port number
/A - IP Adress
/T - Trust Certificate (Add certificate to local Certificate store)
/Q - Overwrite the present binding in IIS
The resulting SSL certificate looks like the one below.
(Mind the 'Valid to' value of april 28th 2061)
A very handy feature is the possibility to write the certificate to a .PFX file. This can even be performed on a system without IIS installed. The command below generates the certificate above and saves it to disk, without adding it to IIS. Subsequently the certificate can be imported at the webservers.
A dutch version of this post can be found here.
Following the TMG installation wizard, you are advised to run Windows Update and install all updates, before installing TMG. As a good citizen, I therefore installed all updates and Internet Explorer 9.
At the end of the installation of the TMG software I tried to start the TMG management console. The following two errors were displayed and the management console did not function.
Error messages
The easiest way to solve this, is by removing Internet Explorer 9. There is a workaround available. To implement this, open the following file:
%ProgramFiles%\Microsoft Forefront Threat Management
Gateway\UI_HTMLs\TabsHandler\TabsHandler.htc
In the file, make the following changes for the console to work again.
Original content
Modified content
More information about this issue is available in this thread.
As I noted before in this blog item, I have come across a problem with Windows 7 and Windows 2008 R2 in regards to the processing of permissions in move operations with Windows Explorer. Seeing there's some additional information on this that was brought to my attention, I decided to share it in this article.
If you move an item between two folders on the same NTFS volume, the permissions of the moved item would not change. Since Windows Vista and 2008 this is no longer the case. Windows Explorer changes the permissions of the moved item, so the permissions will be inherited from the target location (a move operation by something else than Windows Explorer, still retains the original permissions). A special situation arises with Windows 7 and Windows 2008 R2. In these cases, the permissions are sometimes inherited from the target location, and sometimes aren't. Not really consistent and this could pose a big risk when using these Operating Systems in move operations on your fileserver. It is completely random what will happen to the NTFS permissions of moved files…. Or is it not…,?
It seems there is a relationship between the number of items in the 'Access Control list' (ACL) of folders, and the resulting permissions of the moved item. Basically this means that if the number of items in the ACL of the source location and target location are equal, the permissions of the moved item are retained. If the number of items in the ACL is not equal, the permissions are inherited from the target location.
The image below illustrates this. You can clearly see that when the source folder and target folder both contain 2 or 3 items, the permissions are retained. If there is a difference in the number of items in the ACL, the permissions are inherited from the target location.
At the moment Microsoft is investigating this issue, but for now it does seem like a really serious 'Bug'. Tests also show that this behavior is no different in Windows 2008 R2 SP1 and Windows 7 SP1.
This article is also available in Dutch.
In my previous blogpost I informed you about the issues with Windows Explorer in Windows 7 and Windows 2008 R2, concerning NTFS handling. To get some more insight in the problem I tried to find the source of the behavior by using Sysinternals Process Monitor (My favorite tool). With this tool you can see the issue happening, but unfortunately it does not bring us the solution of the problem.
I have been using the various versions of the Microsoft Windows product line since NT4 and I really thought I knew the ins and outs about the NTFS filesystem by now. There were always a few rules of thumb to understand what happens if you move data around. These rules were: "If you copy data, the copied data will inherit the permissions of the location it is being copied to. The same goes for moving data between disk partitions. Only when you move data within the same partition, the permissions