Ever since version 2008 it has been a well-known “feature” within Windows CA server that some certificate templates would not be available for web enrollment. The reason for this would be that some certificate features would “promote” the certificate schema version from 2 to 3. As of today, where SHA-1 is considered “dead” and Cryptography Next Generation (CNG) templates should be the only rational choice, certificates with schema version below 3 are just not available.
For most Windows based systems this is not a big problem, as certificate requests can just as easily be made from MMC certificate snap-in. But for Linux servers, or legacy appliances, not being able to generate a Certificate Signing Request (CSR) and issue a certificate based on that will imply running several “openssl” commands to “split” your manually issued certificate into private key and public certificate files – and making sure that it matches the server or appliance’s requirements.
I have often been missing the opportunity to just paste the CSR into the web enrollment portal and bring the resulting certificate back to the requesting server, but as I have been told for years that would simply not be possible for newer templates. Until recently, as I once more was facing a “CSR scenario” and came across this article from Microsoft. This was perhaps well-known for you IT pros out there, but for me this was breaking news!
The solution is quite simple, and involves nothing but a little ADSI Edit where you manually define the schema version to be something else. Be careful to test it properly, preferrably on a separate/duplicated certificate template. Because schema version 3 certificates might require data not provided through web enrollment, the workaround might not be completely safe for production environments.
This worked perfectly in my case, which was for a CentOS server, even with an X.509v3 CSR including Subject Alternate Name records.
In my previous job as a hired consultant I generally wanted the Lync/Skype for Business servers to have certificates lasting beyond the two year default validity period. Why? Because I, along with the customer, would consider a Lync or Skype for Business solution to have a horizon stretching beyond two years – and therefore issuing a certificate that would expire only after two years would be meaningless.
In a recent project I have been working on voice VLAN implementation and 802.1x (or dot1x) authentication in our Cisco switching infrastructure. There was little to nothing on the subject to be found online, so I thought I would share my experiences.
The other day I ran into a strange issue: When opening Lync Management Shell on one Front End, I was prompted to trust “Microsoft Corporation” as a Trusted issuer. Now, immediately this got me worried, although the certificate details looked legitimate. After some review, I chose the “Run once” option to see what happened next, only to be prompted over and over again. By now I got fed up and hit “Never run”. Bad mistake, as the Management Shell or
import-module Lync in Powershell now would not work any more.
Had a “funny” problem the other day, where a customer who I installed Lync Server 2013 for was struggling. They were experiencing that incoming calls would appear twice (two toasts) whenever simultaneous ring or Call-forwarding was enabled. Normal outbound calls to the same forwarded number was working. I set up a test account myself, but for me the Call would just terminate if sim-ring or Call-forwarding was enabled. Since my Lync running the test account was on a Virtual machine with no sound Device, I was not sure whether I could trust the results.
In a recent Lync project I needed to advice my customer on what reverse proxy to apply. On 12th of September Microsoft announced the end-of-life for my previous favourite, the Forefront TMG. This was a well documented, proven and stable platform for both Lync as well as other web applications/services needing to be published safely in the outer perimeter.