Question on Entrust OCS Certs RRS feed

  • Question

  • We have a farily simple 2 server installation that is up a running with self-issued certs on both servers.  I created a seperate cert for each server using the FQDN of the server as the Subject Name and including all other names (e.g. sip.claritycon.com...) each server uses as Subject Alternate Names:


    Standard Ed Server FQDN: clarityocs1.clarityinternal.net

    Edge Server FQDN: clarityocs-edge.claritycon.com


    I'm now ready to order certs from a third party.  I was assuming that I could simply order two certs with the same configuration, but none of the cert vendors we've used in the past issue certs that include SANs, so I'm now taking a look at the OCS certs from Entrust.


    The question I have is how do I create a cert request for Entrust that will work on both servers given that it appears that OCS requires that the Subject Name on the cert match the FDQN of the server? 


    I tried creating a single self-issued cert that had both machines FQDNs included as SANs, but the OCS services failed on startup because the Subject Name did not match the FDDN of the server. 


    Do the Entrust Certs have all of the names as SNs rather than SANs??






    Monday, January 7, 2008 4:19 PM

All replies

  • You shouldn't need to request a third-party certificate for the internal Standard Server, only the Edge server.  The supported deployment is to use an internal CA is issue a certificate to the internal Front-End server, and your domain-member workstations will trust that certificate chain by default.  The external Edge server would require a trusted third-party certificate to support connections made by non-domain-member external clients, PIC, and federated servers.

    Monday, January 7, 2008 6:53 PM
  • I purchased a cert through entrust. The additional names are all SANs. By definition, you can only have one subject name which does have to match the server name for standard edition servers. Jeff is right though, if you have an enterprise CA configured correctly so all your domain members trust it, you wouldn't need a public cert for the internal server, just the edge. Also, you should list the server FQDN again in the SAN, FIRST, just for good measure(unless you really need all 10 of the SAN's entrust gives you). I've read where people run into problems with ISA/SSL/reverse proxy scenarios(KB940779) when they don't do this.


    FYI, if you haven't used entrust yet, I'd look at GoDaddy now... they just added UCC's and they're offering them for $60/year(5 SAN's). Their support staff is a bit green on how they work and support them still. I got caught up in the domain verification process and it took about 3 calls to get things pushed through. Still, it's a huge price difference.


    Good luck.

    Sunday, February 10, 2008 8:59 PM
  • You should only need 3 certs total, 2 internal and 1 external.


    1. Cert for OCS POOL (Internal CA)
    2. Cert for Internal Interface of Edge (Internal CA)
    3. Cert for External Interface of Edge (External with SANs for each role)
    Monday, February 11, 2008 12:20 AM
  • I've reference the Entrust UC certificate at least a couple times on this forum - it works well for exactly what you are trying to do.  Set the subject name to your Access Edge FQDN and load up the 10 SANs they give you with everything else you need (OCS, Exchange 2007, Sharepoint, web server, etc.).  You basically get 10 fully trusted certs for $1100.

    Monday, February 11, 2008 12:27 PM

    I tried using one Entrust UCC cert on the EDGE server and cannot get it working.  It appears that I will need at least two certs on that server as someone stated above.  An external with the subject name of the Access service (if you plan to ever federate or use PIC) and an internal cert with the FQDN of the internal name of the server.  Using one UCC cert from Entrust will not do the trick.


    Side note, Entrust will re-issue without a charge for the life of the UCC cert.  This is very useful if you plan to add roles later (as long as they do not require the subject name to be the FQDN) and is also good since the documentation from MS is less than stellar on the OCS 07 product and you most likely will not get everything right the first shot.

    Monday, February 11, 2008 7:46 PM
  • Joshua,


    Sorry to hear that the UC cert isn't working for you, but I have to believe there is another issue that is causing this since I've done this a few times now in small and test environments.  Others have also reported success:




    Good info regarding the reissuance policy - I wasn't aware of this.

    Monday, February 11, 2008 9:20 PM

    Thanks for the reply Mike.


    I think I can explain what I see as the root cause of my issue, I would be curious to see the response.  When you configure the Edge server and its roles, you can type in a different FQDN and IP address for each role (internal, Web Conf, and Access).  It appears that the FQDNs are changed to match the subject name of the cert whenever I apply it.  Once applied, it does not allow the option of changing the FQDNs (greyed out).  For example:


    I have one Entrust UC cert with the subject name of sip.domain.com.  In the Subject Alternate names I have edgeconference.domain.com, edgeaccess.domain.com, sip.domain.com, and internal server name.internaldomain.com


    After applying this cert to the Edge interfaces using the certificate wizard, all of the FQDNs of the three roles (internal, access, and WebConf) are changed to sip.domain.com.  If I right click on the OCS application in Comp. Mgmt, I can choose properties, "edge interfaces" tab and choose configure.  The FQDN field is un-editable for any of the interfaces and I need it to reflect edgeconference.domain.com not sip.domain.com for the Web Conferencing Role.


    How can I use the same certificate and configure the OCS Edge server to use one of the SAN for the web conferencing component?  It cannot be sip.domain.com because that record in Public DNS resolves to the IP address of the Access role, the web conference role IP has a different last octet.


    Not doubting that this has worked for you before in small and test environments, I had it working using trial certificates in my Proof of Concept test but the catch there was that I was using 1 certificate for each role (no trial UC certs that I am aware of).  This is contrasted to what I am reading throughout the forums.  I would love to be able to make it work using the certificate I have already purchased.  (since the project is over budget already! :-) ) 


    I am not sure how to load screenshots up to the forum but would be glad to post them to a personal blog or flickr.  There appears to be a lot of confusion over certificates throughout the community here, hopefully this dialog can help clarify some things for me and others.

    Monday, February 11, 2008 9:46 PM
  • That is very interesting. I just verified that when using a cert with SANs on the external interface of the Edge server it changes the FQDN to the CN of the cert and you cannot change it. As long as you have your A records pointing to the correct IP addresses for the correct service then you wont have any issues because of the SANs though. I have this working in production with an Entrust cert and we dont have any issues remotely.


    Monday, February 11, 2008 10:11 PM

    mhanczaruk - That seems to be the rub for me.  I am beating my head against this today trying to get external web conferencing working.  Even though I have an externally resolvable edgeconference.domain.com DNS A record I cannot connect to the web conferencing service.  Editing the user accounts in the Live Meeting client (the latest update of it),  I have tried using the name alone (edgeconference.domain.com), the name with a port (edgeconference.domain.com:443), the external IP, and the external IP with a port (x.x.x.x:443)


    All of the above yield the same result with the exception of the ip:443 combo.  That one returns an error about the certificate while the other three return an error that the server was unreachable or there was an issue with the username


    Would it be possible to PM me your external addresses and I could send you mine?  I would be curious to see the differences between the two environments.  Also, I am considering further testing of this by downloading a trail cert and using it to certify the Web Conferencing role.  Another option is to change the port of the WebConf role and use the same IP but I am hesitant to do that as I don't know what/if any issues would be caused later on with updates/service packs or other solutions that work with OCS.

    Monday, February 11, 2008 10:24 PM
  • How are you trying to access it for testing? Have you tested your ISA reverse proxy to make sure that your failure is not there? ISA will be responsible for publishing conference materials. Another thing you can do is generate a certificate off your internal CA (if you have one) with a CN for your edge conference role and try to connect to it remotely and see what happends. Just make sure you have the root CA trusted on the computer your testing from.


    Monday, February 11, 2008 10:30 PM

    Confirmed this morning that the ISA server troubleshooting links still worked, they do.  As of right now, I am feeling pretty comfortable with the EDGE server and its two roles (Webconf and Access).  Here is what we have and what I had to tweak to get it working.  It is important to note that we have two domains, an internal and and external and we did not have the option of creating the internal sip.tls record for autoconfiguration/sign on to work.  That really throws a wrinkle in things but can be handled using Group Policy to populate the internal/external server names in the Communicator and Live Meeting Clients.


    Certificates:  1 UCC cert from Entrust on the Edge Access/Web Conference server.  This cert has to have the external FQDN of the Access service if you want to federate or use PIC.  At a minimum, the Subject Alternate Names on this cert will need to include the webconferencing role and the internal FQDN of the server. Our includes: sip.domain.com, edgeaccess.domain.com, edgeconference.domain.com, serverinternalname.internaldomain.com


    We do not have an internal CA so I am using the one UCC cert on the internal ip address also.  This was a challenge since the cert had to have the external FQDN as the subject name and that automatically overwrites the name of the internal interface.  To solve that, I placed an entry in the hosts file on the Internal front end server that pointed the sip.domain.com entry to the internal ip of the Edge server.  After restarting the services, that worked.


    Things to note:  I would surmise that would have been a lot easier if we were using the autoconfiguration records like we did in our Proof of Concept.  Because we did not, I struggled figuring out the correct external server name to populate in the clients.  That was the rub in this whole thing and what was causing the external web conferencing issues.  The external server name for the Communicator and Live Meeting client should be as follows:


    Communicator: sip.domain.com:443

    Live Meeting: edgeaccess.domain.com:443


    I initially tried just using the addresses, they will fail without forcing the port (they appear to use 5061 by default).  The Web Conference one was really tricky and we finally figured out this morning that it needed to point to the External Access service, not the webconference service.  When pointed to the webconference service it was being blocked by our firewall since the webconference service is not allowed back in to the front end server, only the Access service is allowed back in if you configure your firewall per the MS documentation in the Edge Server Deployment guide.  We could see the IP address we had configured for the Web Conference role trying to talk to internal FE server and realized we should try the edeaccess role inside of the Live Meeting client instead.  Boom!  It worked.


    To answer the initial post's question (after working through our issues) you can utilize one Entrust UCC cert as other posters have indicated if you have an internal CA that you can use to provide a different cert with the interal server name as the subject.  If you do not have the internal CA, you can still use the one Entrust UCC cert but may have to make an entry in your hosts file on the FE server so it can get to the Edge server.  Also, if no internal CA you will need a separate certificate for the internal server so it looks like your bottom line will be purchasing 2 certificates and making sure to order the Edge certificate with the subject name of the external FQDN of the Access role if you ever plan to federate.

    Tuesday, February 12, 2008 4:14 PM