Cannot access interface: SSL_ERROR_RX_RECORD_TOO_LONG

When trying to access Duplicati 2’s web interface on Windows 10, I get the following error in Firefox. I cannot access it, but it appears to be running in the system tray and Task Manager.

An error occurred during a connection to localhost:8200. SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG

This is at the address: https://localhost:8200/

I am not sure if it was an update to Duplicati 2 which has done this, or if it was myself messing around with self-signed certs on this computer (for an unrelated task). Both of these I have done recently and may be the cause.

Have tried rebooting and uninstall/reinstall. Not sure what else to try.

Just use http://localhost:8200 (not https)

Welcome to the forum!

Thank you. I initially tried that and it didn’t work, Chrome was redirecting to HTTPS. Although after your suggestion I tried a previously unused browser (IE11) and using HTTP seems to work. So thank you!

Follow up question. Do I need to worry about data integrity when using regular HTTP? Is there any chance of data corruption? Setting or config corruption when making setting changes via web interface? Similar to how HTTPS prevents this online, is it needed with a local server or for Duplicati 2?

I don’t think you have to worry about using HTTPS. Duplicati UI is only reachable on localhost (by default) so the web traffic never traverses any network, therefore no reason to worry about encrypting it.

I was more worried about data integrity. Not security or snooping. HTTPS is a good way to ensure data is not corrupted in transit. And I was wondering if there was any need to worry about that with Duplicati 2? For example restoring backups, checking file, etc. Or is it all irrelevant?

Data integrity of the Web UI traffic itself? TCP/IP already has built in mechanisms to detect corruption. Packets that fail checksum are retransmitted. And if you are talking to a localhost server I don’t see how there would be packet corruption anyway.

If you’re talking about backup traffic itself, well it may very well use a TLS (SSL) security layer. Depends on what protocol you selected for your target location.

I guess I am worried over nothing. HTTP should be fine as it’s running on localhost. Thank you for your replies :slight_smile: