WMS HTTPS of Catastro de España not working

[ivanrome]

What steps will reproduce the problem?

1. Download some area in Spain
2. Active the Imaginary "Catastro de España": Imágenes > Mapa > Catastro de España

What is the expected result?

JOSM should render the imaginary "Catastro de España"

What happens instead?

It get this error for the areas I dont have in cache :
javax.net.ssl.HandshakeException ; sun.security.validator.Validatorexception: PKIX path building failed:

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

See attached file

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2021-11-01 23:05:46 +0100 (Mon, 01 Nov 2021)
Revision:18303
Build-Date:2021-11-01 22:25:18
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (18303 es) Linux Mint 20.2
Memory Usage: 308 MB / 1986 MB (95 MB allocated, but free)
Java version: 11.0.11+9-Ubuntu-0ubuntu2.20.04, Ubuntu, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: :0.0 1920×1080 (scaling 1.00×1.00)
Maximum Screen Size: 1920×1080
Best cursor sizes: 16×16→16×16, 32×32→32×32
Environment variable LANG: es_ES.UTF-8
System property file.encoding: UTF-8
System property sun.jnu.encoding: UTF-8
Locale info: es_ES
Numbers with default locale: 1234567890 -> 1234567890
Desktop environment: X-Cinnamon
Java package: openjdk-11-jre:amd64-11.0.11+9-0ubuntu2~20.04
fonts-noto: fonts-noto:-
Dataset consistency test: No problems found

Plugins:
+ FixAddresses (35640)
+ OpeningHoursEditor (35640)
+ areaselector (368)
+ austriaaddresshelper (1597341117)
+ ejml (35458)
+ log4j (35852)
+ reverter (35846)
+ tageditor (35640)
+ turnlanes-tagging (288)
+ utilsplugin2 (35856)

Map paint styles:
- https://josm.openstreetmap.de/josmfile?page=Styles/Lane_and_Road_Attributes&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Enhanced_Lane_and_Road_Attributes&zip=1
- https://raw.githubusercontent.com/species/josm-preset-traffic_sign_direction/master/direction.mapcss
- https://josm.openstreetmap.de/josmfile?page=Styles/Coloured_Postcode&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/AddressValidator&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Cycleways&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Lane_features&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Lane_features_ryg&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Cycleways&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/ParkingLanes&zip=1
+ https://josm.openstreetmap.de/josmfile?page=Styles/Sidewalks&zip=1
+ https://josm.openstreetmap.de/josmfile?page=Styles/Coloured_Streets&zip=1

Last errors/warnings:
- 00037.840 W: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Causa: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Causa: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
- 00037.847 W: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Causa: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Causa: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
- 00037.848 W: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Causa: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Causa: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
- 00037.878 W: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Causa: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Causa: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
- 00039.961 W: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Causa: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Causa: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
- 00039.962 W: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Causa: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Causa: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
- 00039.962 W: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Causa: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Causa: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
- 00039.996 W: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Causa: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Causa: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
- 00040.000 W: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Causa: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Causa: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
- 00040.001 W: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Causa: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. Causa: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

[benetj]

Hello,

This error is due to the SSL policy changes in the Spanish government infrastructure.
To fix this issue, just change the URL from ​https://ovc.catastro.meh.es to ​https://www.sedecatastro.gob.es the rest is the same.

Cheers

[skyper]

Take a look at Maps/Spain. At the bottom of a the page is a the option to edit. Description is on Maps.

[caligari]

I can confirm this problem with Catastro server. Eventually, it works using http instead https:

Imagery > Imagery preferences... > Selected entries: > + WMS >

wms:http://ovc.catastro.meh.es/Cartografia/WMS/ServidorWMS.aspx?FORMAT=image/jpeg&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&Layers=Catastro&STYLES=&SRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox}

[skyper]

Replying to benetj:

This error is due to the SSL policy changes in the Spanish government infrastructure.
To fix this issue, just change the URL from ​https://ovc.catastro.meh.es to ​https://www.sedecatastro.gob.es the rest is the same.

A quick test by only changing the URL does not work. Something else needs to be adjusted.

Replying to caligari:

I can confirm this problem with Catastro server. Eventually, it works using http instead https:

Imagery > Imagery preferences... > Selected entries: > + WMS >

wms:http://ovc.catastro.meh.es/Cartografia/WMS/ServidorWMS.aspx?FORMAT=image/jpeg&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&Layers=Catastro&STYLES=&SRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox}

This does not really help. We need a server supporting ssl.

[skyper]

Ticket #21612 has been marked as a duplicate of this ticket.

[javiersanp]

This report

​https://www.ssllabs.com/ssltest/analyze.html?d=ovc.catastro.meh.es

show Java in red, but handshake simulation is ok

Java 6u45 No SNI 2 RSA 2048 (SHA256) TLS 1.0 TLS_RSA_WITH_AES_128_CBC_SHA No FS
Java 7u25 RSA 2048 (SHA256) TLS 1.0 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA ECDH secp256r1 FS
Java 8u161 RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
Java 11.0.3 RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
Java 12.0.1 RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS

[skyper]

• This server's certificate chain is incomplete. Grade capped to B.
• This server's certificate is not trusted by Java trust store (see below for details).

Additionally, I read "self-signed" and missing support for TLS 1.3. ​The results for JOSM, e.g. are much better.

[skyper]

Ticket #21728 has been marked as a duplicate of this ticket.

[skyper]

Don-vip wrote on #21728:

It seems the WMS URL has not changed, but the TLS configuration has two problems:
​https://www.ssllabs.com/ssltest/analyze.html?d=ovc.catastro.meh.es

1. The chain is incomplete, this must be fixed on server side.
2. The CA is not in trust store, and must be loaded by JOSM at startup:

1 	Sent by server 	*.catastro.meh.es
Fingerprint SHA256: dc3abe0f8ac26d72ae8f75d17ef1d2018f61b0431568a02f16b55ecd904754c5
Pin SHA256: NE2Xf665LZJTsyjE4Eqe+59JW+DjiJRxXPGiOq0kgZs=
RSA 2048 bits (e 65537) / SHA256withRSA

2 	Extra download 	FNMT-RCM / AC Componentes Informáticos
Fingerprint SHA256: f038421f07f20d63a20d3691e5a178ab8459ebe570c1647b7690554ef23876ab
Pin SHA256: MEJWDQI0WXBrEdYtj1u1WdwD26XsIXQQ+57NkgXsoGc=
RSA 2048 bits (e 65537) / SHA256withRSA

3 	Extra download
  Not in trust store		FNMT-RCM / AC RAIZ FNMT-RCM   Self-signed	
Fingerprint SHA256: ebc5570c29018c4d67b1aa127baf12f703b4611ebc17b7dab5573894179b93fa
Pin SHA256: L8VmekuaJnjtasatJUZfy/YJS/zZUECXx6j6R63l6Ig=
RSA 4096 bits (e 65537) / SHA256withRSA 

[skyper]

See #18920 and #22045.

[taylor.smock]

For the record, we are already adding the FNMT-RCM / AC RAIZ FNMT-RCM certificate (see source:trunk/src/org/openstreetmap/josm/io/CertificateAmendment.java@HEAD:196-199#L196​ ).

So the problem is that we are missing the FNMT-RCM / AC Componentes Informáticos. Java does have the ability to download intermediate certificates (see ​AIA), but it is disabled by default for "backwards compatibility". I'm disinclined to change the defaults, since I don't know what the security implications are. I would assume that it verifies the download CA against the CA's in the trusted store, but I'd rather not rely upon that assumption.

[taylor.smock]

Ticket #22045 has been marked as a duplicate of this ticket.

[stoecker]

Did someone contact them and ask them to fix the incomplete certificate chain?

[taylor.smock]

Replying to stoecker:

Did someone contact them and ask them to fix the incomplete certificate chain?

I haven't. I'll go ahead and ask this to the ticket I closed (#22045) so that the reporter there has a chance to respond as well. I would presume no one else has contacted the server owner.

[Yonseca]

Replying to taylor.smock:

Replying to stoecker:

Did someone contact them and ask them to fix the incomplete certificate chain?

I haven't. I'll go ahead and ask this to the ticket I closed (#22045) so that the reporter there has a chance to respond as well. I would presume no one else has contacted the server owner.

Hi,

Thanks for all your answers. I found a contact form ​here, but I'm afraid they're already aware of the certificate problems. That web has a link pointing ​here that tells people to download and install both root and intermediate FNMT certificates.

Should this solution be accepted, or should I try to contact them?

[taylor.smock]

Keeping in mind that I used a translation service:

• It sounds like they expect users to install the root certificate and the intermediate certificate. We (JOSM) already do the root certificate. Unfortunately, we cannot currently do the intermediate certificate (it isn't in any of the root CA stores which we depend upon for adding missing root certificate authorities). So someone would have to do a bunch of coding (note: we would not want to hardcode the certificate into JOSM). The hard part will be ensuring that we don't accidentally work around a security feature.

I really don't want to carve out an exception. Maybe someone else does, but I think everyone would be better off if someone in the community set up a ​mapproxy server instead. We wouldn't have to worry about someone (like me) accidentally opening up everyone who uses JOSM to a malicious actor. Otherwise, starting JOSM with -Dcom.sun.security.enableAIAcaIssuers=true should "fix" the problem. I think that option is safe, but I haven't checked to see what happens when the root certificate authority is not trusted. I presume it fails at that point, but I'm not 100% certain, so use it at your own risk.

With all that said, we should probably investigate whether or not com.sun.security.enableAIAcaIssuers is safe for us to enable by default.

[stoecker]

• It's a bad deployment strategy to deliver an incomplete certificate chain! Chains always should go up to the root (including or not including the root, that's matter of debate). That's what they would need to fix. Asking users to download CA is (a bit) OK. Downloading intermediate is simply wrong.

• As far as I know the current workaround is to simply use http. I thought somebody did that already, but seems not - I did it now.

• JOSM strategy is to rely on java for certificate handling with a few exceptions for important roots. We wont add intermediate certificates.

[javiersanp]

I reported this problem to Catastro in 2018 using the contact form. I just reported this again now to soporte.ovc@… with a link to this ticket.

[Yonseca]

I'm now getting a "SocketException: Connection reset" when using http instead of https, so we have no tiles available as the workaround is not working. Hopefully, they're working on it.

[stoecker]

That's strange. In the webbrowser it works (preview mode). Is this still an issue or was it temporary.