Update of certificates at JOSM startup on Windows is slow

[GerdP]

What steps will reproduce the problem?

1. Start JOSM on Windows
2. Check first console messages

What is the expected result?

Either faster start or better information for the reason of the delay

What happens instead?

Please provide any additional information below. Attach a screenshot if possible.

The log shows 12 secs delay. Method that is invoked is in MainApplication: CertificateAmendment.addMissingCertificates();

2018-11-18 15:53:41.260 INFORMATION: Protokollierungsgrad ist bei INFORMATION (INFO, 800)
2018-11-18 15:53:53.882 INFO: Invalid plugin description '${plugin.description}' in plugin config

Build-Date:2018-11-18 15:53:40
Revision:14428
Is-Local-Build:true

Identification: JOSM/1.5 (14428 SVN en) Windows 10 64-Bit
OS Build number: Windows 10 Home 1803 (17134)
Memory Usage: 447 MB / 3641 MB (90 MB allocated, but free)
Java version: 1.8.0_191-b12, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: \Display0 1920x1080
Maximum Screen Size: 1920x1080
VM arguments: [-agentlib:jdwp=transport=dt_socket,suspend=y,address=localhost:57241, -ea, -Dfile.encoding=UTF-8]

Plugins:
+ OpeningHoursEditor (34535)
+ apache-commons (34506)
+ buildings_tools (34721)
+ download_along (34503)
+ ejml (34389)
+ geotools (34513)
+ importvec (34520)
+ jaxb (34506)
+ jts (34524)
+ merge-overlap (34664)
+ o5m (34405)
+ opendata (34698)
+ pbf (34576)
+ poly (34546)
+ reverter (34552)
+ undelete (34568)
+ utilsplugin2 (34506)

Map paint styles:
- https://josm.openstreetmap.de/josmfile?page=Styles/PublicTransport&zip=1

Last errors/warnings:
- W: Update plugins - org.openstreetmap.josm.plugins.PluginHandler$UpdatePluginsMessagePanel[,0,0,0x0,invalid,layout=java.awt.GridBagLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]
- E: Old Id 'idecor-wms' is not unique - used by 'Córdoba SDI (WMS)' and 'Córdoba SDI (WMS)'!
- W: No configuration settings found.  Using hardcoded default values for all pools.

[Don-vip]

I noticed it too on Windows 7 but never on Windows 10. It's because we need to be sure Windows downloads some certificates on its own, see #15992. Not sure how to improve the implementation right now.

[GerdP]

I think it started a few days ago. Maybe an MS update causes it.
Maybe you can add a log message that shows what is going on?

[Don-vip]

You can have them with --debug. I can reproduce too:

2018-11-18 19:38:10.910 FINE: powershell -Command $PSVersionTable.PSVersion.Major
2018-11-18 19:38:11.907 FINE: powershell -Command [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12;[System.Net.WebRequest]::Create('https://acme-v02.api.letsencrypt.org').GetResponse()
2018-11-18 19:38:13.686 FINE: powershell -Command $PSVersionTable.PSVersion.Major
2018-11-18 19:38:14.652 FINE: powershell -Command [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12;[System.Net.WebRequest]::Create('https://roottest-g2.pkioverheid.nl').GetResponse()
2018-11-18 19:38:16.058 FINE: Adding certificate for TLS connections: CN=Staat der Nederlanden Root CA - G2,O=Staat der Nederlanden,C=NL
2018-11-18 19:38:16.058 FINE: powershell -Command $PSVersionTable.PSVersion.Major
2018-11-18 19:38:17.027 FINE: powershell -Command [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12;[System.Net.WebRequest]::Create('https://roottest-g3.pkioverheid.nl').GetResponse()
2018-11-18 19:38:18.454 FINE: Adding certificate for TLS connections: CN=Staat der Nederlanden Root CA - G3,O=Staat der Nederlanden,C=NL
2018-11-18 19:38:18.455 FINE: powershell -Command $PSVersionTable.PSVersion.Major
2018-11-18 19:38:19.438 FINE: powershell -Command [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12;[System.Net.WebRequest]::Create('https://www.certigna.fr').GetResponse()
2018-11-18 19:38:20.811 FINE: Adding certificate for TLS connections: CN=Certigna,O=Dhimyotis,C=FR
2018-11-18 19:38:20.812 FINE: powershell -Command $PSVersionTable.PSVersion.Major
2018-11-18 19:38:21.786 FINE: powershell -Command [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12;[System.Net.WebRequest]::Create('https://eidas.disig.sk').GetResponse()
2018-11-18 19:38:23.287 FINE: Adding certificate for TLS connections: CN=CA Disig Root R2,O=Disig a.s.,L=Bratislava,C=SK

[GerdP]

It seems that the return code of powershell -Command $PSVersionTable.PSVersion.Major could be stored to reduce the number of powershell commands. Maybe all certificates can be added with one command?

[GerdP]

Attached patch reduces the time to 5 secs, needs reformatting.

[Don-vip]

That's a good start indeed :)

[GerdP]

There is also a registry entry to check the powershell version.
My understanding of certificates is poor :-(
Would it be an option to change the code to be more optimistic so that it first tries to use the existing certificate and only adds it if missing?
17006-v2.patch implements these two ideas, but it will fail if Windows can contain a wrong version of the needed certificate.
Still, it should be possible to verify if the existing certificate is the one we want, right?

[Don-vip]

Replying to GerdP:

Would it be an option to change the code to be more optimistic so that it first tries to use the existing certificate and only adds it if missing?

Unfortunately we can't. Certificates must be added before the Java network stack is initialized, that's why we do it very early and we can't check if this is needed or not. Unless we find a way to re-initialize the Java network stack...

[Don-vip]

Maybe this patch works. To test, you can read my analysis in ticket:15992#comment:29 to understand how certificates work on Windows. When starting JOSM, the call to Powershell makes Windows download the certificate using IE engine and add it to the Windows root trust store on its own. Then it is available to Java when we make https requests.

[Don-vip]

I've changed a few things to make it work :) Polishing, testing and committing soon.

[Don-vip]

In 14431/josm:

fix #17006 - improve startup time on Windows by reworking certificate fetching (patch by GerdP, modified)

[Don-vip]

Thanks a lot! It should be much better now :)

[GerdP]

Yes, thanks, start time is much better :)
I was not able to reproduce the certificate problem, so I hope that it also works where needed ;)