This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Howard, we are looking at making these changes, and will let you know. Meanwhile, I have a question for you. Normally, a URL uses "http" and the handshake with the server then redirects it to https transparently (other than the authentication challenge) to the client . The advantage is that you are letting the server decide what security it wants to use, rather than the client. Im wondering why you dont do it that way? > Simply, can you make following changes (allow "https:") on the netCDF > package? We (ATEC development team) can take care of the self-signed > certificate issue and the connection timeout issue. > > The timestamp of the NetCDF source code I'm working is on Jan. 05 2010. > > Three files are expected to be modified to support https: > - NetcdfFile.java > - NetcdfDataset.java > - DODSNetcdfFile.java > > The attached "NetCDF-Java-modified.zip" contains the original source > code and the modified source > > Thank you, > Howard > > FYI: The detail of change: > > [NetcdfFile.java] > > if (uriString.startsWith("http:")) { // open through URL > > ==> > if (uriString.startsWith("http:") || > uriString.startsWith("https:")) { // open through URL > > > [NetcdfDataset.java] > > } else if (location.startsWith("http:")) { > > ==> > } else if (location.startsWith("http:") || > location.startsWith("https:")) { > > [DODSNetcdfFile.java] > > if (urlName.startsWith("http:")) > ==> > if (urlName.startsWith("http:") || urlName.startsWith("https:")) > > } else if (datasetURL.startsWith("http:")) { > > ==> > } else if (datasetURL.startsWith("http:") || > datasetURL.startsWith("https:")) { > > > > On 3/16/2010 3:09 PM, Unidata netCDF Java Support wrote: > >> > >> > >> > >> Unidata netCDF Java Support wrote: > >>> 1. you should tell the Army theres no point in using ssl without > >>> authentication, > >> you are just slowing everything down for no gain. > >> > >> We have tried reasoning with the Army but as you might guess it is > >> somewhat futile. > > > > i guess it was a rhetorical statement > > > >> > >>> > >>> 2. im not really sure if things fail because theres no authentication, or > >>> because > >> of the self-signed certificate. If you can eliminate one of those > >> possibilities, that would be helpful. > >> > >> The Army machines require certificates from the DOD and not from > >> Thawte or other private type CAs. It isn't technically self signed > >> but probably most browsers don't recognize the DOD as an official CA. > >> > >> I can turn on the authentication via thredds if you think that will > >> help. > > > > one thing that would probably work is to add the DOD cert to your client(s) > > trusted certificate store. is that feasible? > > > > we are looking at how to allow self-signed certificates but im not sure how > > long it will take us to do that. > > > > > > Ticket Details > > =================== > > Ticket ID: ZTB-960075 > > Department: Support netCDF Java > > Priority: Urgent > > Status: Open > > Ticket Details =================== Ticket ID: ZTB-960075 Department: Support netCDF Java Priority: Urgent Status: Open