search

INSPIRE-MIF / helpdesk-geoportal

Community discussion for INSPIRE geoportal topics
11 stars 3 forks source link

INSPIRE GEOPORTAL doesn`t recognize SDI Digital certificate- SPAIN #48

Closed MarisolGomezAndres closed 2 years ago

MarisolGomezAndres commented 3 years ago

There is a problem in recognising our SDI certificate from FNMyT as a valid Authorisation Entity and that´s the reason by our metadata and services are not validated and visualized in the INSPIRE Geoportal. Therefore, the FNMyT Certification Authoritie shoud be included as a valid Authorisation Entity. We have analysed the validation errors and discover that the Geoportal INSPIRE doesn´t recognise our certificate. The same error has happened in the past for at least one year.

dartasensi commented 3 years ago

Dear @MarisolGomezAndres

apologies for the delay, but I was quite busy on other activities.

So, I finally had time to analyse the harvest of the ES endpoint, both on my local machine and production.

This is what I found:

  1. misconfigured certificates on your side. This occurs when a wrong certificate is applied to an endpoint or such certificate was generated with wrong parameters (ie. Subject CN). The error is Certificate for <***> doesn't match any of the subject alternative names: [***]. I was able to trace this specific error for the following domain endpoints:
    • https://www.catastro.minhap.es/
    • https://www.magrama.gob.es/
    • https://miteco.gob.es/
  2. missing RootCA certificate of Izenpe.com (fingerprint sha1: 2f783d255218a74a653971b52ca29c45156fe919) inside the current Java TrustStore. This was resolved through an import command.
  3. certificate chain is broken/misconfigured. This exception sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target appears with our current OpenJDK (SunJSSE implementation). I created a simple Java console application, that reproduce the issue with the above URLs, and I tested over OpenJDK 8/11/16. The opensource application is available here, so feel free to clone and use it. The following endpoints are affected:
    • https://wms.mapama.gob.es/
    • https://sig.mapama.gob.es/
    • ~https://geoportal.minetur.gob.es/~ fixed with a manual import of its RootCA
    • ~https://geoportalgasolineras.es/~ fixed with a manual import of its RootCA
    • https://wmts.mapama.gob.es/

Points 1 and 3 requires your intervention.

In particular, on point 3 I would suggest to get in contact with the certification authority in order to review if the certificate chains are configured correctly.

Finally, I'm available to organize a bilateral meeting with you and your IT team, to further discuss the involved issue, and the technical details behind my discoveries.

Kind regards, Davide

MarisolGomezAndres commented 3 years ago

Dear Davide:

Thanks for your email. Attached you can find our comments:

  1. Any of these names are included in the certificate:

a. https://www.magrama.gob.es/ Out of date, it shouldn´t be used. The right names are www.mapa.gob.eshttp://www.mapa.gob.es o www.miteco.gob.eshttp://www.miteco.gob.es y www.mapama.gob.eshttp://www.mapama.gob.es

 *   https://www.catastro.minhap.es/ doesn´t belong to our organization

c. https://miteco.gob.es/ redirects to https://www.miteco.gob.es/ which is the right name in the certificate.

  1. Solved by the certificate import.

  2. We have executed the Java console application that you sent us on https://wms.mapama.gob.es and reproduced the error.

java -jar url-tester.jar https://wms.mapama.gob.es

Creating connection

Testing URL: https://wms.mapama.gob.es

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

    at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)

    at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1964)

    at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:328)

    at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:322)

    at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1614)

    at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)

    at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)

    at sun.security.ssl.Handshaker.process_record(Handshaker.java:987)

    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072)

    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)

    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)

    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)

    at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:436)

    at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:384)

    at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)

    at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:376)

    at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:393)

    at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)

    at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)

    at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)

    at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)

    at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)

    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)

    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)

    at org.example.App.main(App.java:31)

Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

    at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)

    at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)

    at sun.security.validator.Validator.validate(Validator.java:260)

    at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)

    at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)

    at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)

    at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1596)

    ... 20 more

Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

    at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)

    at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)

    at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)

    at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)

    ... 26 more

The error is produced because the certificate we used is not in your Java truststore . We have imported the certificate in the truststore and have executed the Java console application that you sent us again:

java -jar url-tester.jar https://wms.mapama.gob.es

Creating connection

Testing URL: https://wms.mapama.gob.es

Completed successfully: HttpResponseProxy{HTTP/1.1 200 OK [Date: Thu, 22 Jul 2021 10:49:45 GMT, Server: Microsoft-IIS/8.5, Content-Type: text/html, Last-Modified: Fri, 10 Jul 2020 06:46:07 GMT, Accept-Ranges: bytes, ETag: "7f5520ca8556d61:0", X-Powered-By: ASP.NET, Vary: Accept-Encoding] @.**@.>}

As you can see this time there is no error. Therefore, it is necessary to import both certificates in the Java truststore. I attached both certificates in this email.

@.***D77F02.F1251380]

Best Regards.

Marisol Gómez Andrés

Information Technology and Communication Department Web and GIS services Manager

De: Davide Artasensi @. Enviado el: miércoles, 21 de julio de 2021 18:12 Para: INSPIRE-MIF/helpdesk-geoportal @.> CC: Gómez Andrés, Soledad @.>; Mention @.> Asunto: [MAIL_EXTERNO] Re: [INSPIRE-MIF/helpdesk-geoportal] INSPIRE GEOPORTAL doesn`t recognize SDI Digital certificate- SPAIN (#48)

Dear @MarisolGomezAndreshttps://github.com/MarisolGomezAndres

apologies for the delay, but I was quite busy on other activities.

So, I finally had time to analyse the harvest of the ES endpoint, both on my local machine and production.

This is what I found:

  1. misconfigured certificates on your side. This occurs when a wrong certificate is applied to an endpoint or such certificate was generated with wrong parameters (ie. Subject CN). The error is Certificate for <> doesn't match any of the subject alternative names: []. I was able to trace this specific error for the following domain endpoints:
  2. missing RootCA certificate of Izenpe.com (fingerprint sha1: 2f783d255218a74a653971b52ca29c45156fe919) inside the current Java TrustStore. This was resolved through an import command.
  3. certificate chain is broken/misconfigured. This exception sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target appears with our current OpenJDK (SunJSSE implementation). I created a simple Java console application, that reproduce the issue with the above URLs, and I tested over OpenJDK 8/11/16. The opensource application is available herehttps://github.com/dartasensi/jsse-url-tester, so feel free to clone and use it. The following endpoints are affected:

Points 1 and 3 requires your intervention.

In particular, on point 3 I would suggest to get in contact with the certification authority in order to review if the certificate chains are configured correctly.

Finally, I'm available to organize a bilateral meeting with you and your IT team, to further discuss the involved issue, and the technical details behind my discoveries.

Kind regards, Davide

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/INSPIRE-MIF/helpdesk-geoportal/issues/48#issuecomment-884312452, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASDYC7Y6LR3U7F6274Z556LTY3WTPANCNFSM5ADAR24A.

dartasensi commented 3 years ago

Thanks @MarisolGomezAndres for your prompt reply.

Before going into the matter, I would suggest you to reply directly here, in Github web UI, since their email feature offers limited support (eg. lack of text formatting support, it doesn't publish email attachments for security reasons).

Regarding this issue, I will again offer my availability for a bilateral meeting, to share our opinions and point of view.

About point 1 a/b/c: the indicated URLs are stated in the metadata offered by your catalogue, so the Geoportal software simply follows what is written there. Moreover, I can assure you that the Geoportal honors any redirection if correctly provided by the HTTP server (usually through http response 301/303).

About point 3:

  1. we follow the secure socket standards, so importing single endpoint certificates could break the chain of trusts offered by TLS/SSL itself. You should import only trustful Root CA.
  2. the involved Root CA (AC RAIZ FNMT-RCM, sha1 ec503507b215c4956219e2a89a5b42992c4c2c20) is already imported in the latest OpenJDK builds I tested (8u265, 11.0.10, 16.0.1). For instance, this URL https://www.mapa.gob.es offers the correct chain of certificates, with AC RAIZ FNMT on top.
  3. in principle we would rely on the current COTS implementations of TLS/SSL, HTTP clients and so on.

KR, Davide

MarisolGomezAndres commented 2 years ago

Dear Davide:

I hope you enjoyed the summer holidays.

We have solved the points 1 and 3 of your email but we still doesn´t view our WMS and downloads in the Inspire Geoportal. As you can see we have 91 datasets but only 39 downloads and 5 WMS.

@.***

Please let us know any further steps.

Kind regads

Marisol Gómez Andrés Information Technology and Communication Department Web and GIS services Manager

De: Davide Artasensi @. Enviado el: jueves, 22 de julio de 2021 19:31 Para: INSPIRE-MIF/helpdesk-geoportal @.> CC: Gómez Andrés, Soledad @.>; Mention @.> Asunto: [MAIL_EXTERNO] Re: [INSPIRE-MIF/helpdesk-geoportal] INSPIRE GEOPORTAL doesn`t recognize SDI Digital certificate- SPAIN (#48)

Thanks @MarisolGomezAndreshttps://github.com/MarisolGomezAndres for your prompt reply.

Before going into the matter, I would suggest you to reply directly here, in Github web UI, since their email feature offers limited support (eg. lack of text formatting support, it doesn't publish email attachments for security reasons).

Regarding this issue, I will again offer my availability for a bilateral meeting, to share our opinions and point of view.

About point 1 a/b/c: the indicated URLs are stated in the metadata offered by your catalogue, so the Geoportal software simply follows what is written there. Moreover, I can assure you that the Geoportal honors any redirection if correctly provided by the HTTP server (usually through http response 301/303).

About point 3:

  1. we follow the secure socket standards, so importing single endpoint certificates could break the chain of trusts offered by TLS/SSL itself. You should import only trustful Root CA.
  2. the involved Root CA (AC RAIZ FNMT-RCM, sha1 ec503507b215c4956219e2a89a5b42992c4c2c20) is already imported in the latest OpenJDK builds I tested (8u265, 11.0.10, 16.0.1). For instance, this URL https://www.mapa.gob.es offers the correct chain of certificates, with AC RAIZ FNMT on top.
  3. in principle we would rely on the current COTS implementations of TLS/SSL, HTTP clients and so on.

KR, Davide

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/INSPIRE-MIF/helpdesk-geoportal/issues/48#issuecomment-885087944, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASDYC73TSLMH5TJGGPVPJ73TZBIXBANCNFSM5ADAR24A.

jrc-inspire commented 2 years ago

The functionality of the INSPIRE Geoportal backend is being migrated to a GeoNetwork-based architecture.

Therefore, open issues affecting the current INSPIRE Geoportal backend will not be addressed unless cases of justified need are identified. Once the revamped Geoportal is ready, we will revisit this issue to check if the problems with the certificate remain.

Please contact us at JRC-INSPIRE-SUPPORT@ec.europa.eu in case you have any urgent request.