Vlad Hrybok's Tech Notes

I was looking for someone like http://www.startssl.com/ for a long time: a real, trusted Certificate Authority with very good root cert ubiquity (wich would include iOS) that would issue free server certificates.

AffirmTrust, which is supposed to go online any day now, promises to issue free server certs for three year period. If their root CA certificate is going to be as widely distributed as StartSSL's, then it may be even a better deal than StartSSL, especially given that StartSSL web site and provisioning process are a little corky.

I wanted to have multiple IPs on my server set up for quite some time because I run multiple SSL sites and only one of them could be on a standard port 443. I ran SSL sites on non-443 ports, but unfortunately, many companies block outbound ports, with a funny implication that using one port number is somehow more secure than another. But we have to deal with the reality we have, not the reality we want. So to enable letting multiple port 443 routes, as well as routing port 80 to different boxes inside my LAN I went ahead and got multiple static IPs from U-Verse. Here's what I learned while making it work.

• If 2Wire RG router has invalid entries in the device list - clean the list first. Otherwise clicking Save button on the "IP Address Allocation" page will produce "Invalid Address Assignment" error if you don't change anything. One can clean up the list on the System Restart page. If you have ports NATted/forwarded using Firewall page, cleaning up the list will unlink all "applications" from "devices". So after you have cleaned the device list, you will have to set port forwarding again. The fact that you can't remove one device from the list and have to clear the entire list - a really destructive thing to port forwarding settings - shows that 2WIRE RG management console software is written very poorly.
  
• Routing multiple external IPs to the same machines is possible only if the PC has multiple NICs. 2WIRE RG can't simply map and external IP to a LAN IP. Instead, it maps an external IP to an internal MAC address. Which is why you can't just add multiple IPs to the same NIC and be done with that. Adding an extra virtual NIC to a VM is not an issue, but adding a physical NIC to an up & running production server could mean one has to improvise. There you have it: it's pretty easy to host multiple SSL/443 on the same box this way. It's funny to see that as you add NICs to a box, you'll see multiple instances of the same box in the device list - that's, of course, because RG sees them by MAC but shows them in the list using device names. Like I said, RG web management console is kind of pathetic.
  
• Another "no kidding" feature. In order to use an IP from a range of static addresses, the box needs to get its IP from RG's DHCP - no static IPs allowed. RG then will give your box the IP from static range, making your box essentially a DMZ box sitting unfirewalled exposed to the world of hurt (internet attackers). It appears it may be possible to use firewall on external IPs, but not clear how, especially given that RG's port forwarding feature doesn't support multiple external IPs. It seems to forward ports only with an assumption that router has only one external IP. So if you want your box to be visible inside the LAN, add another NIC and give it your LAN's IP. As you see, you ended up with a server being a poor man's firewall instead of being behind the firewall. Did I mention that RG web console sucks?

Anyway, UVerse's multiple static IP feature would be much easier to use if 2WIRE had better software. RG's mapping internal MACs to external IPs, and its inability to forward and external IP to a LAN IP (eliminating the firewall) are really serious drawbacks to be considered when deciding on whether to do static IPs with such a crude RG.

It's basically a note to self in order to avoid having to research this ever again. I got "Retrieving the COM class factory for remote component with CLSID {XXXX} from machine localhost failed due to the following error: 80070005 localhost" error along with UnauthorizedAccessException in RuntimeTypeHandle.CreateInstance while attempting to call Activator.CreateInstance(Type type) to instantiate serviced component/COM+ object.

To work around, "Enforce access checks for this application" checkbox needs to be unchecked on the Security tab of COM+ application properties. To do it programmatically, the code will look like this:

COMAdminCatalogObject app;
// app = ...
app.set_Value("ApplicationAccessChecksEnabled", 0);

If your ASP.NET 1.1 or 2.0 application throws "This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms" exception, the easiest way to fix is to add 
      <machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="3DES" decryption="3DES"/>
line to the <system.web> section of the web.config file of your application.

FIPS compliance is required for software installed on US government computers. The compliance requirement can be turned on and off.

Source: http://support.microsoft.com/kb/911722

I went through the exercise of setting up Microsoft Team Foundation Server 2008, and needed to do group-level-only rights assignment, so that IT folks could manage security by simply moving people in and out of the Active Directory groups to grant/revoke TFS access rights, instead of setting up individual user rights in TFS, Windows Sharepoint Services and Reporting Services. Initially I created some groups for TFS with the "Domain local" scope, which allowed me to nest other, "Global", groups in them. But I noticed that with WSS and RS, assigning rights to "Domain local" groups does nothing - WSS and RS act as users are not members of the group, while TFS services were working properly. I had to re-create AD groups and make them of "Global" scope to make WSS and RS working properly.

In Windows XP one could just double-click an .MSI (Windows Installer) file to start package installation: MSIEXEC.exe is associated with the .MSI extension and if user had administrator rights installation would go forward. Clicking .MSI file was functionally identical to running Setup.exe bootstrapper, provided Setup.exe didn't have additional functions other than starting the installation.

In Windows Vista things are different. When Vista's User Account Control (UAC) is turned on, launching Setup.exe is not quite the same as running MSIEXEC.EXE /i mypackage.msi. The difference is that when Setup.exe is started, Vista runs it in "elevated" mode, which gives the process more privileges. MSIEXEC.EXE does not seem to run in elevated mode and therefore behavior of the installation may be different.

The issue seems to be manifesting itself most often when an MSI setup package made using Visual Studio executes custom action steps implemented as an Installer class. I am not sure what exactly happens but I noticed that MSI error 2689, which is a common result of failed custom action, will go away if installation initiated using Setup.exe instead of just clicking on .MSI file.

Bottom line: On Vista always start installations by launching Setup.exe instead of double-clicking .MSI file.

Another possibility to consider: if you were not a victim of computer virus attack in the last five years (Windows XP lifetime), then you are may want to simply turn Vista UAC off.

When security experts get together with lawyers we end up with security features that shield software publishers from liabilities and don't do anything to improve security - just think of all the overly complicated, impossible-to-remember passwords forced upon us, with passwords end up written on the post-it note stuck to your monitor. So much for security. The same thing is Vista's User Account Control. UAC pops up so many security warning that after just one day of using Vista I stopped reading them altogether. After one more day of playing whack-a-security-warning, I decided that time is right to turn User Account Control off for good.

To turn UAC off start with launching Control Panel: Start -> Control Panel, and then type "turn user" in the search box and then click the "Turn User Account Control (UAC) on or off" link:

Then UAC screen will appear. Just clear the check box and hit OK button. Vista will probably require rebooting.

Once you have rebooted, your life will be back to normal, except the nagging red shield icon in the icon tray reminding you are truly extreme person living on the edge.