Comodo reseller sells SSL Certificates without proper verficication – I’ll link to the discussion on Google Groups – http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/9c0cc829204487bf?pli=1.  The repercussions of this would allow an attacker to perform an MITM attack, while appearing to look like a trusted owner of a CA approved site.  In order for this to be successfully the attacker would need to hi-jack DNS, or host a caching nameserver/public Wireless service….such as https://bugzilla.mozilla.org/show_bug.cgi?id=460374….yayy

It remains to be seen as to whether Comodo should have their status as a Root CA revoked until correctly validate certs have been issued to everyone who has purchased from then or their resellers….One to watch as this has huge implications – who knows how many certs have been issued, or for that matter if anyone has exploited this already.  On a more cheerful note, I’ve just been trying to explain to someone in the office, that this has nothing to do with lizards or japanese dresses compromising security…..:)

On a slightly less cheery note….found this on the Nat Geographic site….http://news.nationalgeographic.com/news/pf/27959626.html

Interesting reading – who knows – maybe the light’s will go out in 2012 anyway!!

EDIT: If anyone is actually reading this, I would suggest that they manually revoke the signing permissions of Comodo in their browser until this mess is sorted.  At least this way you know that you are sending information to a Comodo SSL signed site and stop.

I first noticed this when building a test environment to trial a few different web-based CRM systems, and I’ve got to say that there are some big pluses to this.

SSL certificates are cheap now and really for any commercial site out there, there should be no excuses for not using a real certificate.  Windows Vista has proved that if you present users with a dialogue box enough times they will just habitually click through without second consideration, thus making them vulnerable to a plethora of security woes.  This is a big security step forward and will hopefully encourage businesses out there to pull their socks up when it comes to using valid certificates (the biggie is likely to be the ability to use self signed SSL certs in Exchange/OWA!)

There is a method of bypassing this (if needed for testing purposes).  For example, I am wanting to test a site in a lab environment, therefore my vulnerability to man-in-the-middle attacks is absolutely zero….

You can go to Preferences->Advanced Preferences->Encryption->View Certificates->Add Exception and then get and approve the certificate for your server…

Commentary with the Firefox developers is available here: https://bugzilla.mozilla.org/show_bug.cgi?id=431827

….and a good explaination of the reasoning behind the fix here:

http://blog.johnath.com/index.php/2007/10/11/todo-break-internet/

The problem lay within Debian and the OpenSSL project.  It seems that the package maintainers for Debian fixed a bug in OpenSSL without passing the fix upstream to the OpenSSL maintainers to check.  This fix has resulted in a major insecurity in a vast number of packages that depend on OpenSSL for any distribution that sits downstream of Debian.

http://www.technologyreview.com/Infotech/20801/

While there is now an official resolution for this problem, it’s shaken my confidence in the way the Debian package maintainers apply bugfixes in their haste to get new releases out the door.

For those interested, the official resolution page on the Debian site is here.

Bear in mind that I run 5 Ubuntu machines (desktops and servers, work and home) each running some of the affected programs…..it’s a phenomenal headache for me.  Now picture those with hundreds (even thousands) of servers and workstations.   I can’t begin to imagine the trauma they are going through….

It’s because of this break of confidence that I have decided to cease using Ubuntu.  If the Debian package maintainers have disregarded policy in order to add value to their distribution in this case, where else have they fixed issues that may or may not have significant consequences…

I’ve played with Fedora previously – quite liked it as a distro, but preferred the user friendliness of Ubuntu – easy to use, but with all the benefits associated with most other Linux distributions.  I could do a Ubuntu install in 15 minutes that would be suitable for most people, with full hardware support – but for more intensive server applications, all the boxes were ticked too.

So, I’m now in the process of my Fedora migration….starting with this laptop.

This can be resolved using a front-end, back-end scenario, but what if you are stuck with a single Exchange server (ie. SBS) in your environment?

On following a few blogs and sites, the solution seems to be to remove SSL requirement for that particular folder in the IIS Manager.  This didn’t work for me though – and I found a lot of people out there with unresoved issues on Experts Exchange etc.

The end solution was to use the ADSIEdit utility to manually stop the Exchange System Manager from using SSL.

The steps are as follows:

1) Install the ADSIEdit Utility (one of the Windows Server 2003 Support tools) from your SBS2003 CD (CD2) using suptools.msi

2) Run a Microsoft Management console (Start->Run->MMC)

3) Open the ADSIedit.msc (browse to the Support Tools folder)

4) Browse through to

Configuration > Services >  Microsoft Exchange > Domain Name > Administrative Groups >     First Administrative Group > Servers > Servername > Protocols > HTTP > 1 > Exadmin

5) Right click msExchSecureBindings, and click Properties

6) Highlight :443: and click Remove

7) Click OK

Restart the Exchange System Attendant and the IIS Admin service

Exchange system manager will now no longer try to use SSL when connecting to the service.

Tue Apr 08 17:31:45 2008 ROUTE: route addition failed using CreateIpForwardEntry
: Access is denied.   [status=5 if_index=25]
Tue Apr 08 17:31:45 2008 Route addition via IPAPI failed [adaptive]
Tue Apr 08 17:31:45 2008 Route addition fallback to route.exe
The requested operation requires elevation.
Tue Apr 08 17:31:45 2008 ERROR: Windows route add command failed [adaptive]: sys
tem() returned error code 1

Looking at the error, it obviously points to a permissions excalation issue in Vista – the workaround:

Edit the config file of the SSL vpn (the .ovpn file) in C:\Program Files\OpenVpn\config and add the following lines:

#Force the use of route.exe
route-method exe

This will force OpenVPN to add the route using Route.exe

Then create a batch file to run the OpenVPN executable with the confif file specified::

“C:\program files\OpenVPN\bin\openVPN.exe” “C:\program files\openvpn\config\yourconfigname.ovpn”

Right click the batch file and run as administrator, and it should work!

I’d struggled getting RPC/HTTPS working for ages using a self -signed certificate, and while it’s still recommended using a purchased certificate, I needed to get a particular user working extremely quickly – within about 4 hours.  Waiting for appropriate DNS to propogate to get the cert approved wasn’t an option so the existing self signed cert I used for OWA was the only option…

NOTE:  THIS SOLUTION INVOLVES EDITING THE REGISTRY ON YOUR SBS SERVER – USE AT YOUR OWN RISK!

First things first, the certificate needed to be installed in the Root Certification Authorities store on the client machine.  Note that adding the cert to the default store WILL NOT work.

Then create split DNS by adding the corresponding external DNS zone to your internal DNS server, and a host record for the SBS server.  Remember, if your external web site is hosted externally you need to ensure that there is an A record that points to the web servers IP address.

Next, a couple of Registry keys needed to be added (I would have never have sussed this if it wasn’t for the resources on Amset!). A reg key needs to be created on the SBS server as follows:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
“NSPI Interface protocol sequences”=hex(7):6e,00,63,00,61,00,63,00,6e,00,5f,00,\ 68,00,74,00,74,00,70,00,3a,00,36,00,30,00,30,00,34,00,00,00,00,00

Copy and paste the above into notepad and save with a .reg extension, then run.  This will create a key that looks like:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters Type REG_MULTI_SZ Name: NSPI Interface protocol sequences Value: ncacn_http:6004

Next on the Exchange server (this will be the same machine if using SBS) a different registry key needs to be created:

NOTE: THIS NEEDS TO BE ON A SINGLE LINE AND EDITED TO SHOW SERVER SETTINGS FOR YOUR SERVER

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy]
“ValidPorts”=”server:100-5000; server:6001-6002; server:6004;server.domain.local:6001-6002; server.domain.local:6004; mail.external.com:6001-6002; mail.external.com:6004;”

Save as a .reg file and run.

Then simply configure Outlook to use RPC over HTTPS and specify the FQDN of the server.  You can test the connection by holding CTRL and right-clicking the Outlook icon, then looking at the Connection Status in the taskbar.  If it is trying to resolve the external FQDN of the server then Outlook is configured correctly. Then just ensure that port 443 on your firewall is forwarded to the SBS server….

….sorted

(Calendar, Tasks, Contacts and Email!!!) with a self signed SSL certificate (you can’t just install

the 64bit .cer file as it won’t allow the file type).

Anyway, thought I’d publish the solution here….
Note: this only works on Windows Mobile 5 and above – not WM 2003
I’ll assume here that people know how to create the SSL certificate (if not theres a good guide

at http://www.petri.co.il/install_windows_server_2003_ca.htm)
Next download the SSLChainsaver tool to the root of your C: drive

http://blogs.msdn.com/windowsmobile/archive/2006/08/11/sslchainsaver.aspx

Follow the instructions on the page to pull a copy of the root and leaf certificates, then

export the ROOT certificate in Base-64 encoded format.
Open the certificate from a command prompt using the line:
C:\Type rootcert.cer
Which will output the hash of the certificate, which will look like:
C:\>type rootcert.cer
—–BEGIN CERTIFICATE—–
MIIEYzCCA0ugAwIBAgIQG4HnhkoEsahFnmBPR65JWjANBgkqhkiG9w0BAQUFADA9

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

A1UEAxMHYmhzcnYwMjAeFw0wNTEwMDMxNzA3NTRaFw0xMDEwMDMxNzE1MjFaMD0x

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

VQQDEwdiaHNydjAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2GTQ

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

N2RtoT4HcNUHYyDTlLrydD4tCOq21o4cNHRk67UsRGRHjZz/BI1YsdOXl1rakOva

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

COsC4ULQDytkuw9gCifqiCyxnT0k7+zkIgNxF4ncFdbnESLm3Bw2wCBz1G/MtUwY

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

2AiOz+jgGeYKv9jD8wIDAQABo4IBXTCCAVkwEwYJKwYBBAGCNxQCBAYeBABDAEEw

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

5a5dW4PRqcsXEAMtMIHyBgNVHR8EgeowgecwgeSggeGggd6GgatsZGFwOi8vL0NO

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

dmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1iaCxEQz1sb2Nh

bD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JM

RGlzdHJpYnV0aW9uUG9pbnSGLmh0dHA6Ly9iaHNydjAyLmJoLmxvY2FsL0NlcnRF

bnJvbGwvYmhzcnYwMi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwDQYJKoZIhvcNAQEF

BQADggEBAEGdXuUfA7kvCxLLOI+W3+Nbz7lENOZF59cNVaQJ5HwjIGtLhw2tv2c0

SibjlB68ecuyuD6K4gYLVlhZrLelDKqGYsV3uF+Q4293+t2S+D3cMXW/gPAYeBU2

Ld+P6dm4tjmzcSC/Xpi3mQpw8kQF93rEEkApbP4LOXh/X5LpyZ2iS15RTMMomxvL

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

ILk4wkjERNGgRRl5eOF3QZ/hMWRu1UMb1C6mrcxs4pBW1qyOJQNJB+Y3eHuWCzfw

oZMi16R2/MCkY6xCqvDRj302UKLHUbU=
—–END CERTIFICATE—–
Create a new file in notepad using the following template and call it _setup.xml, then paste the cert above into the section as below.

Then open your root certificate, look at the thumbprint of the certificate and copy that into the characteristic type section (highlighted in red above, without the spaces). My Thumbprint looked like 963688b77d91307e0164661f9550e2a2

Finally, all you need to do is make the .xml file into a cab file for installation into the Windows Mobile Device using the command line makecab (which ships is %systemroot%\system32 with windows

Makecab _setup.xml rootcert.cab

Copy this to your Windows Mobile device with Activesync, then run.

You should now have an appropriate certificate to allow you to use Direct Push Email

through Exchange Activesync…..

Hoorah!!