Tuesday, October 28, 2014

Exchange 2010 - The certificate is invalid for Exchange Server usage

After attempting to open OWA I received a lovely message about the certificate being invalid today.  Huh?  That can't be right.  Unfortunately we don't utilize OWA very often, so the error had gone unnoticed for a long period of time.


First things first, look at the cert. 
  • Certificate path is fine
  • Still within the valid date timeframe
  • SAN cert and all the DNS names look fine
  • As far as the certificates MMC all is swell.
But Exchange still shows "The certificate is invalid for Exchange Server usage"
After some browsing on the old google I find lots about this when the cert path is wrong.  So I play around with the intermediate / roots, but feel pretty confident that it's correct (and the cert is showing the path valid).


Finally, I assign the Exchange roles to the self signed cert, delete the third party cert, and reimport it.  Same error, but now I of course can't assign the roles back to it because it's invalid.  So, of course after a few minutes people get a popup about the self signed cert.  Doh.  No problem though.  We can force that with the shell.
  • Get-ExchangeCertificate | fl
  • Find the cert wanted and get it's Thumbprint
  • Enable-ExchangeCertificate -Thumbprint [thumbprintfromabove] -Services "SMTP,IIS"  (we don't use POP or IMAP)
Okay, at least now we're back where we had been, but what's going on.


Opening up the shell I do a Get-ExchangeCertificate -Thumbprint thumbprint## | fl.  It shows a RootCAType of unknown.  Eh?  That's definitely not right.


I pull up https://www.digicert.com/help/ and do a cert check.  Uhm, pretty sure it shouldn't say "SSL Certificate is revoked".  Yikes!


After some more head scratching I recall that with the latest project that I'm working with in my off hours (Exchange 2013) I had rekeyed the cert.  Of course when I rekeyed the cert I did import the new cert onto the old Exchange 2010 box, so that shouldn't be the issue.


So, I look at the new Exchange 2013 box cert and compare it's Serial Number to the one on the Exchange 2010.  They should be the same, but what the heck they are not!  Somewhere in the process I messed up the import into the 2010 box. (and I know I did the import, I logged it in our tickets with the steps)


Export the cert again from Exchange 2013, quick import into 2010, reassign the roles and all is happy!


So:
  1. Exchange doesn't specifically complain that the cert is revoked.  It just states it's invalid.
  2. If I had paid more attention to the OWA error I would have seen that it specifically said "The organizations certificate has been revoked" and it was correct.
  3. The certificates snap-in mmc doesn't, as far as I can tell, show when a cert has been revoked.
  4. Certificates can be dang confusing, double check that you've got the right one (serial number seems to be a good way).

Wednesday, October 8, 2014

Java Security Prompts not saving

With a recent upgrade to one of our software's we needed to update to a newer version of Java.  In particular Java 1.7_67.  It was quickly brought to my attention that users would be prompted for the Java security warning every time they logged into the application.  So, clearly it wasn't saving the setting that stored the "never ask again" settings.


After a huge amount of googling I found a lot of information, but nothing ever pointed me at this new location.  (note: after I found the location on my own and did a google search of appdata\locallow\sun\java\deployment\cache\6.0 I got THIS site in my results, unfortunately I had already essentially resolved the problem at that point in order to know to google that... DOH).




We're using Citrix XenApp 6.5 with Profile Manager.  Of course we've set our profiles up so that they do not store junk temp data located in AppData\LocalLow or AppData\Local locations (after all that is the purpose of AppData\Roaming, if it's important store it there).  So, I immediately assumed that Oracle must be storing something in those locations when they should be in Roaming in order for the settings to be retained. 




After some trial and error I had my answer as to the location of the files in question. 


AppData\LocalLow\Sun\Java\Deployment\cache\6.0\34\ (the .lap file)
(note: the \34\ directory may change for different applications)
and
AppData\LocalLow\Sun\Java\Deployment\security\trusted.certs



Both files must be retained to save the "Do not show this again for apps from the publisher and location above" and also "Do not show this again for this app and web site" options.








Before this issue I greatly disliked Oracle's Java, this just pounds in my belief even more that it will be a grand day when I no longer have to install Java RTE on my servers.  Getting very close at this point.  Netscaler (being moved away from Java is my understanding), ProCurve switches (which I rarely have to manage and a single workstation is sufficient anyways), one other application (the one this came up with which is moving away from Java).  I do believe I will throw a party the day these three are done with Java. :)   Then hopefully Crystal Reports death will be next! Haha