tl;dr

Get a wildcard SSL certificate for your domain, reserve some names for internal CRM (e.g. internalcrm.contoso.com) and use internal DNS to resolve those addresses internally-only. If blah.foobar.local is required, domain CA should be used to issue an internal only certificate with trust implied.

The Stop

Our own Joel “Standing on the shoulders of other MVPs” Lindstrom recklessly caused another mini truckstop by not being able to find an answer on his own.

Question

According to DigiCert, no public CA will provide certificate after Nov 1, 2015 that covers an internal resource. I read that as server or server.domain.local. Apparently this is for any address not “verifiable” from the internet. It also will not cover any resource on RFC 1918 (10.x.x.x or 172.16.x.x-172.31.x.x, as well as 192.168.x.x)

For CRM IFD which ALWAYS uses an internal and external address that are not the same address, this might mean publishing the internal address, externally (at least for the cert) which isn’t recommended by Microsoft. Normally the internal address isn’t published externally, but we could do that. My concern is if an internal user hits one of the 4 URLs (Internal, External, Discovery, or Auth) on an INTERNAL RFC 1918 IP, will there be an issue.

Is there any CRM off specific guidance on this?

Answer 1

Feridun “Best Twitter Handle for CRM MVP” Kadir patiently explains the mechanics:

For all the IFD implementations that I have done, I’ve used a wildcard certificate for the company’s domain name. eg. *.contoso.com. No internal resource is published.

Then for internal CRM access I use a name like internalcrm.contoso.com but arrange for the name to only resolve on the internal DNS server. (highlight mine – t.j)

Answer 2

There must be something going on with SSL certificates in U.K., because David “British Scientist” Jennaway chimed in as well:

In most cases I’d do as Feridun’s example. However, if there is a need to use an internal name like server.domain.local, then you can use an internally issued certificate. This would require ensuring the trust path of the certificates, but that’s just something to weigh against the reasons for using an internal name.

I don’t see that IP addresses are relevant here. It may be you can register a certificate for an IP address, rather than a domain name, which would explain the reference to RFC 1918, but that’s not applicable to IFD.