The following is firmly in the “unsupported” range of topics. Follow this line of thinking at your own risk. Don’t blame me or anyone else should this go sideways on you. If this does not bother you, read on.
Scenario
I am working a side project that involves connecting Jabber and Lync 2013 (SfB would work also I suspect) using a mix of the Cisco guidance and Lync 2013 documentation. The intent is to create an inter-domain federation using Lync 2013 Edge services on one side, with the Jabber organization presenting services via an ASA using an ASA feature that provides a TLS proxy. Interesting, yes? Notice that I did not invoke the phrase XMPP. As in the XMPP is not being used. And this is IM/P only.
Here is what we are doing:
Why are we here?
Without stepping too far out on the edge of the cliff, this article is going to concern itself with one element of this construction – namely the requirement to establish the TLS connection between the ASA doing TLS proxy, and the Lync 2013 Edge server (or servers). Basically, it works as you would expect, however, the ASA is looking for a certificate that has both client and server OID codes. And it needs to trust the issuing CA.
Using a certificate from a public authority – well from DigiCert at any rate – will fill this requirement for you (I don’t have a cert handy from another vendor)(oops, I spoke too soon. Entrust, GoDaddy, and Verisign all do it also, but you should check your vendor to make sure). If you are doing a one-off, then you might be using your internal Windows Certificate Authority, which does NOT issue this duality by default. Nor does the standard certificate request generated by the Lync (SfB) wizard prompt you for this requirement – basically because it has no clue as to what you are fixing on doing!
So, what to do? Well, If you have a Windows Enterprise CA, then you are in luck. If you have the standard version, some bright individual will have to figure out how to make a standard edition CA allow for templates. No, I am not that bright.
With your Windows Enterprise CA firmly in hand, open the template editor.
Then, copy the existing “Web Server” template…
Change things around as needed… I don’t know all the implications of making random changes – so tread carefully on some of these items….
But, on the General Tab, you will want to change the “Template display name”, and the “Template name” to something easy to remember. In the “Template name” I suggest using something with no spaces…maybe like this?
After that, head over to the “Extensions” tab…select the “Edit” button…
Select “Add”
Select Client Authentication, and click the obvious button marked “OK”
OK again…
And, one more time on the “OK” button…
So, close the template manager, then right click “Certificate Templates” and choose New | Certificate Template to Issue…
From the resulting list, choose whatever it is that you called your new template, and do the “OK” thing…
…and now we have our squeaky clean new template ready for you to use. Finally.
Skype
Let’s now turn to the real reason we are here, and use this new template to get a certificate for our Edge Server. Yes, usually we will do a public cert, and we have already proved that the major public CA issuers will give us what we want – but we do need to test this in lab first – or you may be doing a one-off, yes?
Open the SfB Deployment Wizard… get yourself over to step three of “Install or Update Skype for Business Server System” and lean on the “Run Again” or “Run” option…
Select the external group, and do “request”…
Adjust the parameters to meet some common-sense items – like shorten up that friendly name – holy crap – but remember that you need the “Advanced” button down at the bottom…
Prepare request now, but…
Specify a file name…
Gees. Finally we are where all this has lead up to!
Specify your alternate template name now. And if you did not heed the advice to use a name with no spaces, my guess is going to be caps count, and don’t use the spaces. Cleverly, having run into this before, I know not to use long certificate template names and long CA names. Adelante! If you have been reading along (or not) you will see that my modified template name is WebServerAndClient…
…which plugs into the SfB Deployment Wizard thusly:
At this point, you can proceed normally. At last.
Clean it up
If you do use an internal certificate source for the outside of your edge server, you will need to provide a copy of the trusted root that issued your Edge certificate to anyone who is wanting to connect – hence the reason we use public certificates. But, for our scenario, we placed the issuing root cert onto the ASA and wala!
Summary:
For whatever reason, you want to get a certificate for your SfB/Lync Edge Server that has both server and client OID authentication. We can fairly certain that public CA providers provide certificates with both by default. Windows Enterprise Certificate Authorities do not provide both OID’s by default – you must create and publish a custom certificate template. And we showed how to use that custom template with the SfB deployment wizard.
YMMV