SSL Certs - It's about Identity, Not encryption

What I've recently learned that is TL:DR for me:
An SSL certificate is designed to provide identification, not [just] encryption. The point of the SSL Certificate is to inform the browser that the encryption being utilized is the one being offered at the server that you think you're visiting.

A CA/Certificate Authority is an entity that offers and digitally signs an SSL certificate. It is a third party that hopefully your browser trusts to confirms the certificate your web browser sees is the one that the CA issued.

Do you need to spend money to get an SSL certificate?
No: StartSSL.com can get you a real third-party verified SSL certificate.

If you can do that, why spend money?
Remember, an SSL certificate minimally provides identification that the SSL certificate that your browser sees is authorized by the CA for the domain name (and for the free certificate, an associated email address) that requested it. That type of information can be generally completed in an automated fashion. The next levels are generally "Verified" and "Extended Validation". Both of those require humans and time and vetting, so they might be more expensive. SSL is for identification, not [just] encryption. Higher levels of certification mean not only is the certificate pointing to the domain, but also that the domain really is the company that you want to connect to. See? Free SSL certificates are cheap. A phisher can create a look-a-like web site that has a real SSL certificate, connected to a almost-the-same domain name, and you could reasonably believe that you've entered your password -- securely -- on the correct domain.

What do you need for SSL?
If the minimum you need is a certificate for verifying that the encryption is valid for the site, maybe for your own email/Exchange Server, Cheap or even self-signed could possibly be adequate. If you're offering a secure service to the general public, you probably want to further ensure that they are connecting to the correct *COMPANY* as well as the correct domain, and therefore you'll want to go for higher levels of verification.

Exchange 2003 Outlook Mobile Access 1801 error

OK, There is absolutely almost no answer on the web for the MSExchangeOMA 1801 error. That’s because stock users of Exchange and IIS won’t have the issue that I had.

The very short answer: WebDav defaults to checking for stuff via IIS http on port 80.

If your IIS has another HTTP (not SSL/HTTPS) port as all it’s listening on, OMA/Outlook Mobile Access will not work. Make sure port 80 is listened to by IIS.

Why I had Internet Information Server on another port:

It was a legacy issue. I had OWA/Outlook Web Access through a firewall on a non-standard port. OWA does NOT like firewall port not matching IIS port. So HTTP port on IIS was chosen to match the firewall port for IIS for NON-SSL traffic. Later, I didn’t need non-SSL traffic for OWA and didn’t bother to change the IIS port. When OMA came up with

Unable to connect to your mailbox on server Servername. Please try again later. If the problem persists contact your administrator.

It was because it was attempting to contact internally via WebDAV on WebDAV’s default connection: http://Servername:80/Exchange/mailbox

the :80 (hidden, but the default port for web) was not accessible because my default http port on IIS wasn’t listening on port 80. This caused the same error from outside my firewall all the way to trying the OMA connection at localhost on my exchange server.

Thanks to
http://www.petri.co.il/configure_oma.htm
http://www.petri.co.il/configure_ssl_on_oma.htm
http://www.petri.co.il/test_oma_in_exchange_2003.htm

for knocking me in the head about things I didn’t realize I hadn’t done.