locked
Quick questions regarding Certificates and AOL RRS feed

  • Question

  • Hi,

    We currently have 2 front end and 2 edge servers set up and are ready to purchase certificates. We have no internal CA, so they will be purchased from a 3rd-party supplier.

    Two questions:

    Do I need EKU with client authentication on all certs, or just the cert on the public interface of the edge server (we're going to enable PIC with AOL)?
    For the Enterprise pool, do I need to add the local machine name to the cert? The local machine names end in .ad, so I don't see how this would be possible.
    We're going to use manual config of the OCS clients. I assume therefore that we do not need to specify each SIP domain on every cert?

    Cheers!
    Friday, November 20, 2009 10:32 AM

Answers

  • Ah, that last post explained it a bit in more detail.  Yes, if you plan to use Manual configuration to set the same primary SIP domain for all OC client regardless of the user's configured SIP domain, then you are correct that you don't need to add the other SIP domains in any of the Edge certificates (the article I linked above explains that).

    And regarding the certificate request, that depends on third-party CA . If it's something like 'companyABC.ad' then I know that Digitcert (for example) will issue you an SSL certificate as long as you can validate that you are in fact 'companyABC'.  In fact they will issue you a cert for pretty much anything (could be generic like domain1.local) as long as it's not a real .com, .net, etc suffix.  If your company is in good standing and nothing appears fishy I'd bet you could get a cert for your domain.ad namespace.

    In that note I highly recommend deploying an internal CA as more and more systems are going to be requiring certificates to function and spending money for certificates on internal usage can get expensive over time.


    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    • Marked as answer by lws_33 Monday, November 23, 2009 4:29 PM
    Friday, November 20, 2009 4:21 PM
    Moderator

All replies

  • If you haven't already read through the Microsoft Certificates White Paper I highly suggest it, as it covers pretty much everything you'd ever need to know about certs in OCS: http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=77

    The Enterprise Edition Front-End certificate should have the Pool FQDN as the SN and the SAN would include the server FQDN and any supported SIP domains.  And you pool name should be in your AD name space (yourdomain.ad), not your SIP name space (yourdomain.com)

    Example:

    SN: pool1.yourdomain.ad
    SAN: ocsserver.yourdomain.ad, sip.yourdomain.com, sip.yourdomain2.com

    Also you should create all certificates requests with the settings (EKU, private key exportable, 1024 key length, etc).

    Whether you use Automatic or Manual configuration in OCS the SIP domains must still be included in the certificate for OCS to allow connections over TLS.  So you do in fact need to add every SIP domain to both internal EE cert and the external Access Edge cert.  See this blog article for more details on Edge certificate requirements:
    http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=79
    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Friday, November 20, 2009 2:37 PM
    Moderator
  • Thanks for the reply. I have read the certificate documentation previously.

    We have no internal CA, so how could I obtain a certificate for domain.ad from a third-party CA? Does this mean that any company with no internal CA and an AD name space such as domain.ad or domain.local cannot implement OCS?

    We will have around 50 SIP domains. The OCS clients will all point to a single FQDN specified under advanced configuration pushed out via Group Policy. I don't see the requirement for each SIP domain to be added to a cert in this situation. I fully understand that when auto config is used the SRV record for each SIP domain must resolve to an A record within the same domain plus a valid certificate.

    Thanks!
    Friday, November 20, 2009 3:33 PM
  • Ah, that last post explained it a bit in more detail.  Yes, if you plan to use Manual configuration to set the same primary SIP domain for all OC client regardless of the user's configured SIP domain, then you are correct that you don't need to add the other SIP domains in any of the Edge certificates (the article I linked above explains that).

    And regarding the certificate request, that depends on third-party CA . If it's something like 'companyABC.ad' then I know that Digitcert (for example) will issue you an SSL certificate as long as you can validate that you are in fact 'companyABC'.  In fact they will issue you a cert for pretty much anything (could be generic like domain1.local) as long as it's not a real .com, .net, etc suffix.  If your company is in good standing and nothing appears fishy I'd bet you could get a cert for your domain.ad namespace.

    In that note I highly recommend deploying an internal CA as more and more systems are going to be requiring certificates to function and spending money for certificates on internal usage can get expensive over time.


    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    • Marked as answer by lws_33 Monday, November 23, 2009 4:29 PM
    Friday, November 20, 2009 4:21 PM
    Moderator
  • Excellent.
    Unfortunately, deploying a CA is something I wouldn't have any influence in, but that's the way it goes. Verisign is our preferred supplier. 
    Is it an absolute requirement to add the local machine name? I notice it is a check box and isn't a forced option.

    Thanks.
    Friday, November 20, 2009 4:56 PM
  • Ther servername FQDN must be in the certificate as server-to-server MTLS connections will use this hostname to connect to it, while clients would use the poolname FQDN.  (If you have a standard Edition server these are the same names, but with an Enterprise Edition deployment they are different).

    The checkbox is used to add the server FQDN to the SAN field incase it's not entered in the SN field.
    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Friday, November 20, 2009 5:15 PM
    Moderator
  • Thanks.

    I assume I can add each front end FQDN to a single cert and then install this single certificate on all our front ends?
    Monday, November 23, 2009 4:09 PM
  • Yes, as long as each Front-End server is part of a different pool.  If they are part of an EE load balanced array for the same pool then you'll need a single SAN certificate with all names (servername1, servername2, poolname) on each node.


    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Monday, November 23, 2009 4:18 PM
    Moderator
  • Unfortunately VeriSign will not add the local machine names to the cert, as the domain name is valid and could be used for impersonation. Is there are any other way to set up MTLS without using the Front Ends FQDNs? Would it be possible to use TCP as a last resort?
    Tuesday, November 24, 2009 4:45 PM
  • You can only use TCP for internal OC client to Front-End Server communications.  All server-to-server communications within OCS (MTLS only), as well as external client login via an Edge Server (TLS only) all would require certificates.
    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Tuesday, November 24, 2009 5:18 PM
    Moderator