SSL Verification for DOD Websites in Google Apps Script

We recently encountered an error caused by changes in how Google uses the SSL trust in Google Apps Script in Google Apps for Gov. We have several Script application systems - in particular, it is a server monitoring system and a calendar synchronization tool based on webservice, which interact with the servers at our end via an SSL connection. This worked perfectly for several months, until ~ 9: 15 p.m. on September 20, 2012, when almost all of these (and similar) connections began to fail due to the inability to trust DOD-signed certificates, which are mandatory for us at our end of things.

The stranger still is that this is somewhat controversial, that is, I can successfully ask Google to connect to https://usuportal.usuhs.mil , and it only loads well. However, if I try any of:

https://www.us.army.mil

https://www.nps.edu

https://www.disa.mil

https://learning.usuhs.edu

... they all fail. I suspect that this is due to the root certificate to which some servers are attached, it is enough that all bindings to the "DOD Root CA-2" certificate as a terminator fail - a real problem for us.

For our server monitoring, we were able to temporarily work around this by disabling SSL checking in Script applications, but this option is not available for accessing web services [EDIT: we use SoapService to process requests and returns WS], leaving us unable to continue using these tools until as long as this problem is in place. Given the accuracy with which we can determine when the relevant changes occurred, I should hope that Google can at least (relatively) quickly determine what happened.

If this is useful, the following is a free Google Apps Script feature that will log out with success / failure based on whether it can trust the SSL certificate on the endpoint.

function checkSSL() { // The server to go look at to see if we can trust it. // Again, usuportal.usuhs.mil has been observed to work; all others tested have failed // var serverToTest = "https://www.disa.mil"; // options defines the options which will be used by the UrlFetchApp to define its behavior. // In this case, we may be interested in disabling SSL validation. // var options = { "validateHttpsCertificates" : false }; // First, try without disabling validation // try { response = UrlFetchApp.fetch(serverToTest); Logger.log("I was able to reach " + serverToTest +" without disabling certificate validation."); } catch (e) { // Logger.log(e.toString()); Logger.log("I was not able to reach " + serverToTest +" without disabling certificate validation."); } // Now let try it with validation disabled // try { response = UrlFetchApp.fetch(serverToTest, options); Logger.log("I was able to reach " + serverToTest +" with certificate validation disabled."); } catch (e) { // Logger.log(e.toString()); Logger.log("I was not able to reach " + serverToTest +" with certificate validation disabled. Maybe it really just down?"); } } 
+4
source share
1 answer

Record this in Problem Tracking . I was able to plunge into it internally, and this is actually the problem that we consider. After you register it in Tracker Issue, you can monitor the progress of this problem.

We will most likely resolve this by adding a similar validateHttpsCertificates flag for SoapSerivce, e.g. with UrlFetchApp

+1
source

Source: https://habr.com/ru/post/1440987/


All Articles