feature request #8931
closedTaxeditor supports https
100%
Description
The Taxeditor seems not able to connect cdm instances via https.
With this configuration:
{
"name" : "edit-test",
"server" : "test.e-taxonomy.eu",
"port" : 443,
"prefix" : "cdmserver/",
"ignoreCdmLibVersion" : true
},
the connection fails because the taxeditor attempts to connect with HTTP instead of HTTPS. The Server response:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>400 Bad Request</title> </head><body> <h1>Bad Request</h1> <p>Your browser sent a request that this server could not understand.<br /> Reason: You're speaking plain HTTP to an SSL-enabled server port.<br /> Instead use the HTTPS scheme to access this URL, please.<br /> </p> <hr> <address>Apache/2.4.10 (Debian) Server at test.e-taxonomy.eu Port 443</address> </body></html>
Conclusions:
- The Taxeditor should be able to detect the required protocol that is to recover from such protocol failures by using the correct protocol after such errors.
- When the server redirects the editor from port 80 (http) to port 443 (https) the editor must follow the redirect and must use the correct protocol (see point 1.)
- Redirects from port 443 (https) to 80 (http) must work also
- The taxeditor needs a place to store information on the required protocol. data on connections is stored in
.cdmLibrary\cdm_remote_servers.json
the json object needs to be extended by a protocol field. The taxeditor should update the connection infotmation when a server redirects from http to https or vice verca. - Configuration of HTTP connection is done at two places separately. (
CdmApplicationRemoteConfiguration
,CdmServerInfo
) There should be a central point for this.
{
"name" : "edit-test",
"server" : "test.e-taxonomy.eu",
"protocol": "https"
"port" : 443,
"prefix" : "cdmserver/",
"ignoreCdmLibVersion" : true
},
Related issues
Updated by Andreas Müller over 4 years ago
- Target version changed from Unassigned CDM tickets to Release 5.15
Updated by Andreas Kohlbecker over 4 years ago
- Assignee changed from Katja Luther to Andreas Kohlbecker
- Target version changed from Release 5.15 to Release 5.14
- % Done changed from 0 to 10
Connecting the test server (test.e-taxonomy.eu) via https fails with:
.... 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:387) at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:230) 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:1496) ... 75 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.securit
This is most probably caused by java 8 not bringing the latest root certificates (see https://stackoverflow.com/questions/9619030/resolving-javax-net-ssl-sslhandshakeexception-sun-security-validator-validatore)
Updated by Andreas Kohlbecker over 4 years ago
Atlassian provides detaild information on this problem at https://confluence.atlassian.com/kb/unable-to-connect-to-ssl-services-due-to-pkix-path-building-failed-error-779355358.html
and has a nice little class which helps test servers:
$JAVA_HOME/bin/java SSLPoke server.example.com 443
Updated by Andreas Kohlbecker over 4 years ago
- Description updated (diff)
- Target version changed from Release 5.14 to Release 5.15
There are no problems connecting the production server api.cybertaxonomy.org:443
So the problem above seems rather to be a configuration or certificate problem of test.e-taxonomy.eu
Connecting the Taxeditor via HTTPS basically works now, so that it can be used when the connection is configured properly.
This however requires manually adapting .cdmLibrary\cdm_remote_servers.json
which is not an option for general users.
Therefore I am moving this ticket to the next milestone now
Updated by Andreas Müller about 4 years ago
- Target version changed from Release 5.15 to Release 5.18
Updated by Andreas Kohlbecker over 3 years ago
- Target version changed from Release 5.18 to Release 5.19
Updated by Andreas Kohlbecker over 3 years ago
- Target version changed from Release 5.19 to Release 5.21
Updated by Andreas Müller over 3 years ago
- Target version changed from Release 5.21 to Release 5.22
Updated by Andreas Kohlbecker over 3 years ago
- Target version changed from Release 5.22 to Release 5.48
Updated by Andreas Müller almost 3 years ago
- Related to feature request #9840: Add the possibility to enter new server added
Updated by Andreas Müller almost 3 years ago
- Status changed from New to Feedback
- Target version changed from Release 5.48 to Release 5.51
- % Done changed from 10 to 50
Andreas Kohlbecker wrote:
There are no problems connecting the production server api.cybertaxonomy.org:443
So the problem above seems rather to be a configuration or certificate problem of test.e-taxonomy.eu
Connecting the Taxeditor via HTTPS basically works now, so that it can be used when the connection is configured properly.
This however requires manually adapting.cdmLibrary\cdm_remote_servers.json
which is not an option for general users.Therefore I am moving this ticket to the next milestone now
I guess the open issue is handled in #9840 and we can close this ticket?
Updated by Andreas Kohlbecker almost 3 years ago
- Status changed from Feedback to Closed
- % Done changed from 50 to 100
Updated by Andreas Kohlbecker almost 3 years ago
- Target version changed from Release 5.51 to Release 5.15
i think we should move this ticket back to 5.15 or even to 5.14