Custom URL does not work from version 120, with 119 it works.

[wimiti]

Since you upgrade to version 120 and later, the "Custom URL" option does not work with the same settings as for the previous version 119.

For example, in version 122, looking at the log, after 5 attempts it tells me "Custom URL -Could not upload the file" and "Custom URL: maximum attempts failed, giving up".

Also indicate that the SSL certificate has been validated correctly in the configuration.

That could be happening?

Thanks for the development of the application and the attention on this issue.

W.

[mendhak]

Hi what you'll want to do is record a debug log: https://gpslogger.app/#troubleshooting

Then recreate the problem. Then, look at the log to see what the problem is, it might be really apparent, or you can post it here, (but probably hide any location info and hide the domain name of what you're connecting to), or you can email it to me - gpslogger at mendhak.com and I can have a look.

[mendhak]

Sorry late reply. So, I saw the logs. The main error with redacted information is

javax.net.ssl.SSLPeerUnverifiedException: Hostname domain.name.yes not verified:
......
20:02:18 INFO  CustomUrlJob.onRun:62 - HTTP Request - https://domain.name.yes/nextcloud/xxxxxxxxxxxxxxxx
20:02:18 DEBUG Networks.getKnownServersStore:56 - Getting local truststore - /storage/emulated/0/Android/data/com.mendhak.gpslogger/files/knownservers.bks
20:02:18 DEBUG LocalX509TrustManager.isKnownServer:144 - Checking for certificate - HashCode: -1322352508, Subject: 1.2.840.113549.1.9.1=--------------------------id------------------------------------------,CN=domain.name.yes,OU=Private,O=DomainName,L=TATA,ST=TATA,C=WORLD, in keystore: true

From what I can tell, the certificate validation test did work, because the in keystore: true appears.

The certificate subject shows

CN=domain.name.yes,OU=Private,O=DomainName,L=TATA,ST=TATA,C=WORLD

I had a look at the code changes between version 119 and 120. The main change is the library version of okhttp, from 3.7 to 3.10. And in their changelog, this message seems to match up with the above behavior.

New: Don’t fall back to common name (CN) verification for hostnames. This behavior was deprecated with RFC 2818 in May 2000 and was recently dropped from major web browsers.

So could you try regenerating the certificate, but adding the domain name to the SAN list (subjectAltNames) of the certificate and try again?

[wimiti]

Thank you for reviewing the debuglog that I sent you. After a few weeks disconnected, I have been able to return to the topic and I have done what you have indicated. I have created a new certificate with SAN list (subjectAltNames) and it already works in versions higher than 119 (specifically, I have tried it in the most recent 123). Thanks for everything.

[mendhak]

Nice, that's good to hear. OK will close the issue.