Assigning SSL certs across multiple servers

We’re venturing down the path of migrating to Office 365 from an on premise Exchange 2010 DAG environment.  We’re a small non-profit without much hardware and we’re not looking to maintain on  premise Exchange servers; once the accounts have been migrated, we’ll remove the Exchange servers.  We’ll be doing a phased conversion thus we’ll be using DirSync and ADFS with a hybrid installation.  We presently have an internally signed cert which has served us well but obviously this won’t work for Office 365.  We use OWA for external email users.  

Reading the installation docs, it appears that we’ll need a cert for ADFS.  If I get a SAN cert, generated from the ADFS installation, can I share that between ADFS and Exchange, and if so, how?  And how does this affect communication between the DAG servers? I suppose it would be a best-practice to do this off-hours but is there a way of “backing up” my existing cert to restore that if things go bad? Finally, since we are a non-profit, anyone know of good, cheap cert providers?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Free SSL certs are available from StartCOM. If you want to pay, GoDaddy are the cheapest, but they're also absolutely horrible in every other way - just use StartSSL and have done with it.
ADFS can share a certificate with Exchange and Outlook Web Access; generate the request using IIS as per normal, install the certificate in IIS and also install it anywhere else you need the certificate. I'd probably not bother using a SAN certificate; just get 2 issues for the names you'll actually be using. IIS keeps old certificates when you add new ones, so there's no specific requirement to back the certificates up manually,

Generating the request:
Installing the signed certificate in IIS:
Installing the cert as an ADFS Communications certificate:
Setting certs in Exchange Shell:
firstly, self cert SSLs are not ideal for exchange and some issues simply cannot be fixed without purchasing a proper SSL.
Once you have a suitable SSL you can use it for many purposes, including ADFS.

many cheap options exist, but the basic certs from Godaddy are a good bet.

you can install a purchased cert alongside your existing self cert, and you can easily swap between them as required. So you can always go back to the original if you feel there's an issue.

Warning: it is increasingly difficult to purchase a cert for 'internal' domains (eg domain.local, domain.private) so you may have to assess the FQDNs you need the cert on before going ahead.
btanExec ConsultantCommented:
You probably has sen this for Plan for third-party SSL certificates for Office 365. Certificates are required for the following Office 365 components:
Exchange on-premises
Single sign-on (SSO) (for both the Active Directory Federation Services (AD FS) federation servers and AD FS federation server proxies)
Exchange Online services, such as Autodiscover, Outlook Anywhere, and Exchange Web Services
Exchange hybrid server

Probably you should see this for Certificate Planning in Exchange 2013 and this for Exchange Hybrid Deployment and Migration with Office 365

But specifically, MS recommends this for
We recommend that you use a dedicated third-party certificate for the AD FS server, another certificate for the Exchange services on your hybrid server, and if needed, a certificate on your Exchange server. Federated delegation on the hybrid server uses a self-signed certificate by default. Unless you have specific requirements, there's no need to use a third-party certificate with federated delegation.
The services that are installed on a single server may require that you configure multiple fully qualified domain names (FQDNs) for the server. Purchase a certificate that allows for the required number of FQDNs. Certificates consistent of the subject, or principal, name, and one or more subject alternative names (SAN). The subject name is the FQDN that the certificate is issued to. SANs are additional FQDNs that can be added to a certificate in addition to the subject name. If you need a certificate to support five FQDNs, purchase a certificate that allows for five domains to be added to the certificate: one subject name and four SANs.

Another note for SSO purposes
-Single sign-on with AD FS requires Active Directory on-premises.
-Single sign-on requires that you install and run the Microsoft Online Services Directory Synchronization tool.
-If you plan to migrate all mailboxes to the cloud and set up single sign-on, you can’t deploy AD FS or directory synchronization before you run a cutover Exchange migration in the Exchange Control Panel. You can, however, run a staged Exchange migration after you deploy AD FS and directory synchronization.

Earlier mentioned, for the case of hybrid, ADFS and ADFS proxy are needed and the guided step in importing a Server Cert is necessary to import a server authentication certificate on each ADFS server. The key is  a single name SSL (or SAN) certificate is sufficient (as compared to using wildcard cert) and if you use a single name certificate, the FQDN included should match the FQDN that you configured for the ADFS server.

It will be good to look through from the steps shared as good overview. Minimally understand the flow for co-existence and identity checks is validated with AD remains at your site (instead of cloud).

Note: The WAAD Sync tool was formerly known as the Directory Synchronization tool (DirSync tool).

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
btanExec ConsultantCommented:
Also if using the same public certificate for Office 365 Hybrid internally and externally, depending on your internal environment complexity, a more complex type and/or you do not have split brain DNS (this means you cannot use the same URL for your services internally and externally) then you will need to use multiple certificates. If you are in this circumstance I recommend that you plan for your internal certificate requirements first and then add on your Office 365 Hybrid requirements. Once you have a combined list of names it is much easier to plan your certificate locations and generate the requests accordingly.

Some best practices also mentioned by MS here for the choice of certificate. Note wildcard and SAN is different though both will work, preferably be specific and secure using SAN cert instead. Also not all CAs support SAN certificates, and other CAs don't support as many host names as you might need.

You can actually make a certificate request from the IIS and submit to the 3rd party CA for signing as shared here. Make sure that the common name matches what you plan to call the AD FS server farm.  Microsoft best practices recommends that you use the host name STS (secure token service).

E.g. of 3rd party CA include GoDaddy
ejefferson213Author Commented:
Thank you all for your support and comments; it is greatly appreciated!!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.