The revocation status of the domain controller certificate used for smartcard authentication could not be determined. There is additional information in the system event log. Please contact your system administrator.
If you have smartcard authentication set up for logging into certain Active Directory systems, and also a restrictive web proxy on the machine acting as the RDP client, you may run into this issue.
My mistake was checking that the RDP server had access to the CRL mentioned in the certificate.
Yes, the RDP server might be quite happy in terms of checking the certificate revocation, but if the RDP client can’t access the CRL URL (perhaps through the configured proxy), you will receive this same error.
Check connectivity to the stated CRL distribution point from the RDP client and RDP server!
The march of freely available TLS certificates for domain validation continues in the form of the Let’s Encrypt project and I’m very pleased that it does.
I’m very happy with the Certbot client on most systems where I need to deploy Let’s Encrypt, but on hosts facing the big wide world that are Windows-based, Certbot obviously is not an option!
Fortunately, I’ve had success with the ACMESharp library for PowerShell. What’s cool about the library is that it does break down the process into individual commands, meaning you can automate, script and report on your certificate status with a great deal of flexibility.
For simpler scenarios, though, the letsencrypt-win-simple client offers a nice friendly command line interface to the ACMESharp library and is a nice easy way to quickly retrieve and install a Let’s Encrypt certificate on a public-facing IIS instance. Automating the renewal process is easy too — just create a Task Scheduler task.
Yes, it’s a command line client, and there are Windows folks who may not be comfortable with that, but it walks you through every part of the process. No memorising of switches and flags are needed!
There really is no excuse — now is the perfect time to get everything on HTTPS!
Before the release of Apple’s OS X Mountain Lion, when the Gatekeeper feature was first announced, Apple proudly proclaimed on the relevant page that developers distributing their apps outside of the Mac App Store would be able to get a “free Developer ID certificate”.
Unfortunately, I did not have the foresight to screenshot the page that said this, because now, even a month after the release of Mountain Lion, their generosity appears to have evaporated.
Only Mac Developer Program members are eligible to request Developer ID certificates and sign applications or installer packages using them.
The aforementioned Developer Program(me) is the standard, $99/£69 per year subscription that entitles you to full Mac App Store distribution rights. Unless I am missing something obvious, and I really wish that I am, there are no free Developer ID certificates.
This disappoints me — I cannot justify enrolment in the paid program for DfontSplitter for Mac, which doesn’t generate me significant donation revenue at all. This means I cannot sign DfontSplitter for use with Gatekeeper, which degrades the experience for Mountain Lion users of the software, and maybe even puts them off entirely.
I am definitely in favour of security measures that put the control in the hands of the user. I cannot, however, get behind a system which appears to discriminate against all developers who are not in a position to join Apple’s certification programme. I am left disappointed, and my app is left unsigned.
There used to be advertising here, but I no longer feel sure that advertising delivers the best experience and truly reflects the values of this site.
Keeping things running, however, is not without financial cost. If you would like to support the time and effort I have put into my tutorials and writing, please
consider making a donation.
