locked
Dynamics IFD - Custom CSR's and required Certificates RRS feed

  • Question

  • Hi guys

     

    I'm looking for some assistance with a Dynamics 365 IFD, specifically the certificate requirements.

    I'll be creating Custom CSR's (using IIS) for the certificate requests from a Public/Internet CA and want to get all of the attributes such as Key Usage and Extended Key Usage correct but TechNet is falling short on the very specific requirements of each certificate (or I just can't find it!).

     

    Some background:

    • Dynamics is installed on Server1.
    • Dynamics databases are on a separate SQL Cluster, Server2.
    • ADFS is on a separate server and will be used for other services in the future, Server3.
    • All devices are behind a NetScaler appliance, there is no DMZ.
    • The client has the same internal/private and external/public DNS domain name.
    • The client will not use a wildcard certificate and wants to specify certificate SAN's.
    • We may as well use the same certificates for internal and external clients.

     

    Sanity check for the required certificates/SANs:

    • Microsoft Dynamics Website Certificate (Server1) - Used to secure the IIS website with SSL.
      • SANs:
        • dyn.domain.com
          • Dynamics 365 Organization Web Service
        • dyndisco.domain.com 
          • Dynamics 365 Discovery Web Service

     

    • Microsoft Dynamics Encryption Certificate (Server1) (Presumably requires the Private Key to be exportable so should be separate from the Website Certificate although I can’t find a definitive answer)
      • SANs:
        • auth.domain.com 
          • Dynamics 365 Authentication Web Service

     

    • ADFS Server Authentication Certificate (Server3)
      • SANs:
        • adfs.domain.com 
          • Active Directory Federation Services Web Service

     

    • ADFS Token-signing Certificate (Server3) (should be a separate certificate as it requires Private Key to be exportable)
      • SAN's:
        • ?

     

    Am I right or am I missing something? Can anyone point me in the right direction for the exact requirements for each certificate when requesting with a Custom CSR?

     

    Many thanks in advance.

     

    James

    Sunday, August 27, 2017 3:10 PM

All replies

  • Hi James.

    Well, basically you need issue 2 certificates for an Dynamics 365 IFD / ADFS deployment.

    One for the Dynamics 365 Server IIS that will also be used on the Reverse Proxy, which in your case this NetScaler appliance will be used/act as.
    The other for ADFS.

    This certificate needs to conatain the following SAN's.

    Dynamics 365 / Rev Proxy:
    1. "<UniqueOrgName>.domain.com"
    You need to have a SAN for each orginisation, hence why a wildcard certificate might be more cost effective if running multiple orginsations on the same installation.

    2. "dyninternal.domain.com"
    Debatable if needed, but certanly most convinient, since you have the internal url for Dynamics CRM which need SSL to even be able to configure claims-based authentication.

    3. "auth.domain.com"
    4. "discovery.domain.com"

    ADFS
    1."adfs.domain.com"
    Basically you only need to issue a certificate with one SAN, which is for ADFS Service Communication.
    However for future planning, you might want stuff like Device Registration wherea's you might want to include enterpriseregistration.domain.com.

    Regarding the ADFS Token-Signing and Decryption certificate, is also something that is discussed on the internet if you should use the self-signed or custom(public).
    But it kinda depends quite alot the the federated partners applications that will be used, and I would suggest you read this article about it and decide: AD FS and self-signed Token-Signing certificates

    But specifically for Dynamics 365 I would say no since it utilizes ADFS metadata information.

    As an important side note when you consider your Dynamics 365 certificate SAN names is that currently there's a bug(at least I would call it so) where single-sign on fails with other passive-federated partner applications using the same ADFS.
    So you might want to consider using a subdomain because of this. (ex. auth.subdomain.domain.com)
    More about this issue here: Passive federation request fails when accessing an application using AD FS and Forms Authentication after previously connecting to Microsoft Dynamics CRM also using AD FS

    This bug is still not fixed in the latest update for Dynamics 365 v8.2.1 and has been there for quite a while now without Microsoft fixing it... Sadly.

    H
    ope this helps and good luck!
    Philip


     
    Thursday, September 7, 2017 2:33 PM