Not much experience with this.  I don't see any way around not having a
public web site.  You need to be able to access the web site to install the
certificate on the client.  I don't believe you can substitute your public
IP address for the FQDN in the certificate setup.

Maybe someone else can jump in here.

Gary:

Chad Gross will be replying here in a while.  I think he may have some good
news.  Stay tuned...

Hi Gary -

You don't have to be hosting a public website (other than OWA).  When you
access a website using SSL, your browser checks the SSL certificate for 3
conditions:  1) the name on the certificate matches the name of the website.
2)  The certificate hasn't expired.  3) You have chosen to trust the
publisher that generated the SSL certificate.  As you know, IE has its
Trusted Root, which lists a predefined group of trusted publishers.  If the
SSL certificate on a site was not issued by a trusted publisher, you will
receive a security warning before the page loads.

When you install and enable Certification Authority in Windows Server / SBS,
you're basically setting yourself up as a certificate publisher, but the
typical small business is not going to be included in IE's list of trusted
publishers.  In order to prevent users from getting a security warning every
time they access an OWA installation using a self-signed certificate, they
need to chose to trust the publisher (you).  They do this by installing your
.crt file mentioned in the article to their trusted root.  Obviously, they
need to be able to access your .crt file from the internet in order to
install it on their machine.  Since publishing Certificate Services to the
internet comes with a slew of security implications (Especially on an SBS),
I recommend uploading your .crt file to your outsourced website if you have
one.  This allows remote users to be able to access the .crt file so they
can add you as a trusted publisher without further exposing your SBS to the
internet unnecessarily.

It is important to note that it is not necessary to upload your .crt file to
a public website, or even for it to be accessible to remote users.  You can
completely skip these steps and your users will still be able to access
OWA - the only thing is that they will be prompted with a security warning
indicating that the SSL cert was generated by a publisher they have chosen
not to trust.  I would recommend purchasing an SSL cert from a trusted
publisher as this completely negates the need to upload a .crt file, and the
users will not be promted with a security warning.  Just make sure that the
name on the SSL cert matches the URL users will be using to access the site.
(E.g. - if they're going to access OWA using mail.yourcompany.com/exchange,
you'll want the name on the SSL cert to be mail.yourcompany.com  - if
they're accessing it using the public IP   12.23.45.67/exchange, then you'll
want the name on the SSL cert to be your public IP)

As for Exchange using the ISP smarthost & using ETRN to dequeue inbound
email, that shouldn't have any affect on OWA.  OWA doesn't care how Exchange
sends & receives email, it just provides access to a mailbox.  The same goes
for if SBS is using the pop connector - OWA works the same as with a pure
SMTP installation.  The only thing with using ETRN or the pop connector,
etc. is that there is a chance that there are emails sitting on the ISP's
mailserver that Exchange has not retrieved yet.  Obviously, these emails
won't be available via OWA until Exchange retrieves them.

HTH!