Certificate for RWW and OWA

For self signed certificates from your own Domain CA, it will be trusted automatically by any PC that is joined to the domain and would just work 'inside'.  But your CA won't be in the trusted roots on any PC so you have to import it there.  The webserver has a site called Certsrv.  On any external machine that needs to access Exchange for anything that requires SSL authentication, go to https://yourexternalURL.com/Certsrv and put in a valid username and password at the prompt.  Your browser will complain that the certificate isn't trusted, click on whatever the "connect anyway" button is.  Then on the first page you get click on "Download CA certificate, Certificate Chain, or CRL" then on the next page click on "install this CA certificate chain"  You will get prompted to run the ActiveX control, click yes on it, then you might have to click on the "install" link again.  Then it will prompt you to say that, yes, you trust the CA certificate and you do want it put into your trusted roots.  Once that's done exit your browser and voila! the certificate will work.  You also need to make sure that you've set the internalURL and externalURL for all your Exchange bits.  Check this in the Exchange Shell with "Get-OWAVirtualDirectory | fl name,internalurl,externalurl"  Go check out this: http://exchange-genie.blogspot.com/2007/07/autodiscover-ad-attribute.html as this guy has a great explanation of how to test, diagnose and fix the Exchange web services.  -Steve

My answer above should apply to Exchange 2003 as well as 2007, but the "how to check your URLs" is specific to 2007.  Sorry if that wasn't clear.  -Steve

When you run the Configure Email and Internet Connection wizard, SBS creates its own self-signed certificate.
That is why it is trusted internally and not be external clients.
You will need to trust the certificate on the client machines in order to utilize some features like OWA and Outlook RPC/HTTPS.
Philip

Another annoyance with those automatically created certificates, if your Microsoft domain name is a .local instead of your real .com external Internet domain name, that certificate might read "www.mydomain.local or "internalservername.mydomain.local" instead of what you need it to read, which is your FQDN for the mail server.  You would then just need to manually request/create a new certificate specifying the right server name.  And still also import the CA Certificate from certsrv as I outlined above.  -Steve

SfoSmire ... we have been setting up SBS boxes for years, and not once have we ever run across the wizard making any mistakes on the certificate.
If one does not understand the questions being asked of them via the CEICW, then I can see where things can go sideways.
Philip

Here is a good run down of the CEICW steps and what they do:
http://www.sbs-rocks.com/sbs2k3/sbs2k3-n2.htm
Philip

Well I didn't say that it makes a mistake, it just might be a certificate that won't work externally.  Microsoft's old recommendation for Windows domain naming schemes was to use .local instead of your real .com domain name.  There may have been a valid reason, but it isn't recommended anymore.  So, if one installs SBS using that outdated advice, the server will dutifully create a perfect certificate for servername.domain.local that will only work internally.  That's my point.  -Steve

Allright you do have a point, I see what you mean with that CEICW step-by-step.  It does explicitly tell you that the FQDN may be different from your servername.  Regardless, the CA Certificate needs to be installed to the trusted roots on all PCs or devices (PDA's, Cell phones, Windows Mobile) that aren't joined to the domain.  -Steve

Yes, the certificate needs to be trusted by importing the cert via IE into the Trusted Root Authorities.
Philip

One other thing... if you access RWW or OWA remotely from the same machine on a regular basis, you can view the certificate and then install it so that it will become trusted and you won't see the error message anymore.

Jeff
TechSoEasy

>>Domain naming with .local is NOT outdated advice.

Actually, it is.  MS are now recommending that you NOT use .local, but rather .internal - when that article is updated, I don't know.  Whether this corporate shift will be backed through old KB articles, I also don't know.  The point is, it is clear as day in all new versions to NOT use .local - most probably for the Mac compatibility problems *shrug*

I will leave the debate of real domains versus these bizarre .fake domains for another forum, lest we have endless linux experts in here touting rubbish :)

Caveat!

I do agree that the current documents recommend not using a real domain, for an SBS environment - I doubt that will ever change, and re-reading the thread, I see that is the point you were trying to make.

sfosmire, "There may have been a valid reason, but it isn't recommended anymore." I wish that was true - but it isn't.  SBS is still recommended to use .local

Ignore the fact that most of MS internal domains, and pretty much all Exchange MVPs I know say specifically to not use .local - the articles are still there.  Personally, I think .local domains are the dumbest thing you can use - but Jeff has a few valid points (much to my disappointment).  We had a long argument/debate about it, and from my position, he was right that for SBS domains, it is better.

Bear in mind that SBS is not the thinking mans solution - it is a turn key, out of the box, install it and click "next, next, next" and it just works.  Is that a bad thing?  I don't think so.

I feel all dirty now :(

Jeff,
There is one exception to the .local: When one has a heterogeneous LAN setup with Apple/Mac computers joined to the SBS domain. With 10.4.x Tiger, this is not an issue, as the networking built into it can work with the .local that SBS normally takes for a domain root, but the previous versions of Mac OS do not. The .local extension on a Mac has an important role to play in OS 9 and early OS X operating systems.
So, we have used .LAN in the case of Mac installations on a SBS network, or, as RST mentions, we are now starting to use .internal.
Philip

Yeah, I'm aware of that but really this was more of a discussion about whether or not to use the same TLD as the public Internet domain.  

I actually use different internal TLD's depending on the company name such as ABCLend.ing  
or sometimes  companyname.inc or partnerfirm.llp

Jeff
TechSoEasy