Cisco ASA Firewall Presents Only “ASA Temporary Self Signed Certificate”

Recently we started to get reports of untrusted certificates for AnyConnect and when accessing the ASDM web page. When you browse to the web site it was presenting the default “ASA Temporary Self Signed Certificate” rather than our public SSL certificate.

After opening a case with Cisco TAC about this they pointed us to the release notes issue in ASA 9.4(x):

Elliptic curve cryptography for SSL/TLS—When an elliptic curve-capable SSL VPN client connects to the ASA, the elliptic curve cipher suite will be negotiated, and the ASA will present the SSL VPN client with an elliptic curve certificate, even when the corresponding interface has been configured with an RSA-based trustpoint. To avoid having the ASA present a self-signed SSL certificate, the administrator needs to remove the corresponding cipher suites using the ssl cipher command. For example, for an interface configured with an RSA trustpoint, the administrator can execute the following command so that only RSA based ciphers are negotiated:

ssl cipher tlsv1.2 custom

As soon as I added the command into our ASA it started working again. It sounds like this should be a default entry going forward for all ASA firewalls.

Want to learn more about elliptic curve cryptography  or look at this for a primer.

Microsoft Intune and Conditional Access to Exchange On-Premise Configuration Problems

I’m trying to setup the Microsoft Intune MDM solution with the Conditional Access policies to our Exchange On-Premise server.  The idea behind this is that users must enroll their device with Intune via the Company Portal app on their mobile device and then once they meet the requirements, they will be granted access to Exchange ActiveSync.

The basic setup is straightforward and easy to setup following this Technet article.  However we have run into two issues:

I received emails previously (last week) from the Intune Exchange Connector that looked like the following:

To access your organization’s email, you must enroll your device and make sure that it complies with your organization’s security policies. Follow the steps below for the relevant device.

Instructions for your Android with ID androidxxxxxxxxxxxxx
1. If you haven’t enrolled your device yet, enroll it now
2. After a couple of minutes activate your email
3. Check to see if your device is compliant

But after upgrading the latest version of the Microsoft Intune On-Premises Connect for On-Premises Exchange, I’m no longer receiving these emails but other users are.

The other issue is that the “activate your email” link doesn’t work.  The URL points to the following web site:, but also includes options to POST the following:


And the response to this URL and POST commands just looks like the following:

{“Message”:”No API matching request was found, verify URL and parameters are correct”,”TraceId”:”90baac77-3ac9-43e6-bb67-3b47a6c3726f”,”Time”:”04-28-2015 11:37:57Z”}

And the TraceId above has nothing to do with the obfuscated TraceId above.

I have opened a case with Microsoft Online Support about this and will update once I get more information.