Multiple SSL Certificates on services

SSL certificates are not paired to IP addresses, only host names. AS long as you are using split horizon DNS then the host name will match regardless if the user is access from LAN or WAN. For example, if your server is named jacob.talbot.com and is on your LAN at address 172.16.0.10, then you can act as SOA for the talbot.com domain on your own LAN. Thus, all devices connecting to your LAN will route to 172.16.0.10 when requesting services from jacob.talbot.com. However (assuming your firewall rules are in place), the same user can leave your LAN and be on another network and again request access to jacob.talbot.com. A public address will be returned, something like 17.0.17.34. This will hit your firewall and a NAT/PAT forward will occur. To the end user it is seamless.

And since the host name is the same when on the LAN and off, your SSL protected services simply work. The only reason you will get errors is if you are accessing the server using different host names. This happens on Windows .local domains all the time. The LAN is setup using a private domain name TLD (.local) yet the WAN access using proper dns, host.domain.tld. In this case, someone loses.

Use split horizon DNS. Unify your host names. Then you only need one certificate. Unless you want to protect individual services with unique host names.

Reid

Apple Consultants Network

Author "Yosemite Server – Foundation Services" :: Exclusively available in Apple's iBooks Store

Author "Mavericks Server – Foundation Services" :: Exclusively available in Apple's iBooks Store

Author "Mavericks Server – Control and Collaboration" :: Exclusively available in Apple's iBooks Store

Reid nailed it on the split horizon DNS and everything else.

I do like to hop in and take the SSL question further.

I bought a $5 Comodo SLL that only covers www.example.com and example.com, not server.example.com or xyz.example.com . It covers Web, not Open Directory intermediate root nor code signing if I understand correctly now. I can see that in the certificate pane.

Somewhere, it might not sufficient as some services wants to use the xyz.example.com

So my question is:

If, like Jacob, I'd like to have users be in and out of the OD/ internal network and be guaranteed to reach mail, messages, calendars, adress book, profile manager and what not, which SSL certificate and variant of sub-domain, multi-domain, multi protocol covers it all on an Internet exposed but behind a bridge modem and Airport Extreme?

A wildcard certificate will cover all subdomains of a domain, such as www.exanple.com, mail.example.com, WebDAV.example.com

A UCC certificate will cover multiple domains - www.example.com, www.example2.com, www.example3.com

Hope that helps

It helps as basic information.

Can you take us down the yellow brick road of OS X Yosemite Server as to what Jacob or I need in terms of Certificate for inside nad external access. I.e. Web, OD, Profile Manager, Xcode /Swift or whaterver certificate type I did not think of Please?

francois

It depends what you want to do.

If you have one domain, a wildcard certificate for example.com will cover mail.example.com, www.example.com, xyz.example.com and so on. So you get a wildcard certificate, install it in Server (the certificate provider will have instructions, usually, or ask here if you have a problem), and set Server to use that certificate for services.

If you have multiple domains, you get a UCC certificate which covers 5 domains or so (there may be variations). But that only gives you the named domains and subdomains (i.e. no wildcard). For example: mail.example.com, mail.example1.com, www.example1.com, if I specified those three. Again install the certificate and set is the one Server uses.

Does that help?

Hello Again,

For an SSL 101 course yes, it helps.

I want to transform my $5 we certificate to a wildcard because covering example.com and www.example.com doesn't cut it inside and outside my server's network, specially with Profile Manager, since it's OD signing of either self signed, self root, code signing or wathever comes from xyz.example.com.

I'm barely getting to master the split horizon DNS, mailing through My ISP, having my registrar or ISP being front mailing server. Companies just pass each other the buck. Feels like having a Samsung Phone, using Google Android, surfing with Firefox, searching on Bing for a Yahoo Apps.

But then again, there's a trizillion options out there, Identity, enterprise, code signing, MX, and it looks just as endless to me as the sheer number of PCs, Cards and Microsoft Windows combinations. Maybe not that bad but still.

Since i'm deploying Yosemite Server from home, with my dot com, on a DSL with static IP for the sole purpose of trying alsmost everything in OS X Server to put in practice all the theoretical of ACTC, I went through Apple Pro Training Server and Support, Integration and Management for 10.7,10.8,and 10.9, three of Reid Bundondis' three books, Terry Walsh's 2 of 3 home server books, Charles Edge Krypted dot com and watched Todd Olthoff's videos for 10.7,10.8,and 10.9.

I posted a long post of my setup here (even if it changes a bit with time) : Yosemite Home Mail server from Static ISP or registrar?

But as all installation are so personal, I can just still trial and error myself up to it.

So, if I can blow couple hundred bucks on a one year certificate that will do for my example dot com, OD, code signing, Profile Manager, Apple Configurator, Apple TV, Mail, Messages, AddressBook, Calendar, Wiki, Blog and maybe Xcode and Swift..

What do you recommend?

François.

Looking at your setup, it seems you want wildcard rather than UCC (you only have one domain with several subdomains).

For this to work you need:

1. A wildcard certificate - get one wherever you can get a good price - I use Godaddy, but choose yourself.

2. DNS settings. You seem a little uncertain about these, so maybe this will help.

- You need DNS at your ISP (or wherever you have your A record) so the internet knows which IP address is associated with your domain and subdomains. To achieve this, go to the setup where your A record is and either:

-- add A records for each subdomain

or

- add an A record of * (asterisk) - this tells everyone that any address ending example.com should go to your IP

- also, add an MX record for mail.example.com, s mail can find your IP.

That deals with the internet finding you

- You also need internal DNS, which is telling Server where to send traffic on your internal network (addresses beginning 10. in your setup)

- The most important internal DNS record is the MX record so Server knows to route mail to your domain to the mail service (from your other linked post, I assume you have the other DNS records set up)

When you've done this, check that your domain is visible from the internet - Yosemite has a Reachability test to help with this.

Once that's OK, install your wildcard certificate and set Server to use it for services.

That should be it. If you have trouble, it's most likely to be in the DNS area - if that doesn't work, nothing does

nick101 wrote:

Once that's OK, install your wildcard certificate and set Server to use it for services.

That should be it. If you have trouble, it's most likely to be in the DNS area - if that doesn't work, nothing does

Man, I am having the damnest time. You seem pretty knowledgable, perhaps you can help. I'm in a similar boat as Jacob. I bought a wildcard SSL "*.domain.com" from GoDaddy using a CSR I made from Server app.

I imported the CA CRT and the wildcard CRT into Server app. I've selected it to use for all services. Here's the rub, it seems that the Common Name "*.domain.com" is being read quite literally by Safari both inside and outside the network (DNS works fine). I get a certificate error and it states "host name mismatch". URL is "internal.domain.com" and the wildcard is "*.domain.com".

What am I missing???

To Whiskey Juliet,

Did you create the CSR with *.domain.com?

if so, it's Difficult for me to say without seeing server/router/registrar setups.

==

1- I had a Comodo Positive SSL cert that just gave me www.domain.com and domain.com . Safari did not give me a chance to do zip, it didn't trust becase the server and intermediate OD is signed to named xyz.domain.com. There are ways to tell Safari to ignore through keychains I guess. I could overrule with Chrome but things hanged with Profile manager. I also thought my DNS didn't have a xyz.lan forward or reverse or some sort of wizardry.

2- I then got, today, a Comodo SLL Essential wildcard. Every thing just rocks inside and outside the network for now.

--> What I can say is I had to specify *.domain.com when creating the CSR

Then had to put a long string of text at the domain Default root folder, the one that hosts the default server page and the index.html and page stuctures I created, sent by Comodo.

Instead of thaking minutes, it took two hours to get 4 cert files y mail which I added to the *.domain.com CSR i created this morning.

In server app, certificates, chose that certificate which switched all services to it except OpenDirectory which alway require OD Intermediate.

restarted the server, to lazy to copy-paste in terminal the long new command.

Now everything rocks, profile manager accepted comodo trust and enrolment certificates and I can surf from inside the same domain name that I do from outside the Network !

I've tried a few ways by now. I created the CSR with just "domain.com", and "sub.domain.com" and most recently (what I'm currently using) is "*.domain.com". It seems that the certificate IS being used by the services, in this case Profile Manager. Yet, it appears to be taking the cert Common Name quite literally as "*.domain.com" and calling a host name mismatch. I would expect it to replace the "*" with any selected subdomain and host. See screen grab from certificate error.