Download manually created Certificate Request via RMS

[Zugschlus]

Hi,

it’s me again Last time for today, I promise.

Since I need to make some progress, I now use the RMS to access my remote device’s WebUI, doing things manually. I used System => Administration => Certificate to generate a certificate request for a client certificate and a corresponding private key:

Note that “Private key decryption password” is “Off”. We’ll need that information later.

After clicking on “Create”, the device worked for a minute and then showed the key and the certificate request:

Clicking on Preview shows sensible data, but not the certificate request itself:

I then click the checkbox of the certificate Request and “Export” from the menu line:

Browser now happily says “Certificate download was successful”.

But, my Browser didn’t download anything. The downloads directory is empty. It looks to me like the RMS is somehow “eating” my download.

When I log on the device’s WebUI directly without going through the RMS, download of the certificate request is successful immediately. But that’s a luxury that I don’t always have; most of my devices are behind a NAT devices that I cannot control, and therefore cannot connect directly to my devices. That’s why I am using the RMS in the first place!

Where is my download going to?

Now lets assume that everything was successful and I was able to create my OpenVPN configuration:

When I now enable the configuration, this appears in my log:

776 Thu Oct 23 15:13:16 2025 daemon.notice openvpn(inst1)[18045]: Note: cipher ‘AES-256-CBC’ in --data-ciphers is not supported by ovpn-dco, disabling data channel offload.
777 Thu Oct 23 15:13:16 2025 daemon.notice openvpn(inst1)[18045]: OpenVPN 2.6.9 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH/PKTINFO] [AEAD] [DCO]
778 Thu Oct 23 15:13:16 2025 daemon.notice openvpn(inst1)[18045]: library versions: OpenSSL 3.0.14 4 Jun 2024, LZO 2.10
779 Thu Oct 23 15:13:16 2025 daemon.notice openvpn(inst1)[18045]: DCO version: N/A
780 Thu Oct 23 15:13:16 2025 daemon.warn openvpn(inst1)[18045]: WARNING: No server certificate verification method has been enabled. See 2x HOW TO for more info. 781 Thu Oct 23 15:13:16 2025 daemon.warn openvpn(inst1)[18045]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts 782 Thu Oct 23 15:13:16 2025 daemon.warn openvpn(inst1)[18045]: OpenSSL: error:05800074:x509 certificate routines::key values mismatch: 783 Thu Oct 23 15:13:16 2025 daemon.warn openvpn(inst1)[18045]: Cannot load private key file /etc/certificates/myrouter.key.pem 784 Thu Oct 23 15:13:16 2025 daemon.err openvpn(inst1)[18045]: Error: private key password verification failed 785 Thu Oct 23 15:13:16 2025 daemon.notice openvpn(inst1)[18045]: Exiting due to fatal error`

I didn’t set a password on the private key!

What is going wrong here?

Sorry for being a nuisance, I am trying really hard to not be.

Greetings, Marc Haber

[Matas]

Hello,

I have a sneaking suspicion that the errors you’re getting are due to the fact, that you didn’t sign your certificate, judging from the screenshots:

Could you perhaps try & re-generate it, but this time make sure the “Sign the certificate” option is enabled?

Regards,
M.

[Zugschlus]

I didn’t sign the certificate on the device since I have an external Certificate Authority. The device generated a Certificate Request (myrouter.REQ.pem) which I downloaded and then signed with my external Certificate Authority, yielding the file 20251023_rutx08-7833_CRT.pem which I uploaded to the device again and selected when creating the OpenVPN connection. This is the normal way of handling X509 certificates when you have an external CA.

[Zugschlus]

I found a workaround: If I put a password on the generated private key, then OpenVPN can use the key when I enter the same password in the OpenVPN configuration. That doesn’t make sense, so it is really just a workaround.

So, this is now a bug report: If a private key is generated on the device and the optional switch “Private Key Decryption Password” remains at its default (off) during key generation, the generated key is not useable in an OpenVPN configuration later.

Additionally, entering the password for the private key in the OpenVPN configuration (Certificate Configuration => Advanced Settings => Private key decryption password (optional)) doesnt seem to reliably work, what worked last night now gets the following log entry

1166 Fri Oct 24 10:36:47 2025 daemon.err openvpn(inst1)[16585]: neither stdin nor stderr are a tty device and you have neither a controlling tty nor systemd - can’t ask for ‘Enter Private Key Password:’.  If you used --daemon, you need to use --askpass to make passphrase-protected keys work, and you can not use --auth-nocache.

despite the correct password being entered there.

Please forward this to the appropriate internal medium of Teltonika so that this bug can be fixed.

Greetings, Marc Haber

[Matas]

Hello there,

First off, glad you were able to resolve this issue! I’ll go ahead and register this for our R&D to analyze. Thank you very much for the details and the time that you put into this.

Kind regards,
M.

[Zugschlus]

Thank you! Your products have a new challenge each day, and I accept those challenges I am happy that you are responsive and helpful.

Greetings, Marc Haber

[Zugschlus]

Do we have any news on this?

After trying a bit, I think the configuring OpenVPN via the RMS is fundamentally broken and I shall open a new thread for that.

One issue remains that can probably be easily fixed.

When I access the device’s web UI via the RMS, downloads initiated from the device seem to go to a place where I cannot access them. Where do they go? See Picture 1 where I exported a certificate and don’t find that file anywhere. Maybe that file should show up in “Recent device files”? Maybe there should be a download option in Actions/Actions where I also can export backups, event logs and troubleshoot files?

Picture 1:

[Matas]

Hello!

I’m still waiting for a response from the R&D.

Thank you for your patience,
M.

[Zugschlus]

You might tell them that the issue with the key password is gone. I cannot reproduce that any more. I just need advice where my downloads are going to. That should be much simpler. If the answer is “your downloads are going to the bucket, the RMS doesn’t know how to handle downloads yet” I’m fine with that because I can stop worrying and thinking about doing things wrong.

[Matas]

Thanks for updating. Passed the information.

[Zugschlus]

Found another workaround. When accessing the WebUI, I have always punched the “Connect” button:

Then the WebUI opens as kind of sub-window to the RMS and downloads go “somewhere”.

But you can also copy the link:

and paste the link into a different browser tab. That will open the WebUI of the target device in its dedicated windows, and downloads work.

I still would like to know the comment of your development people, but I’m fine for now with this way.

Greetings, Marc Haber

[Matas]

Thank you, passed this information as well.

Regards,
M.

[Matas]

Hi,

We’ve attempted to test this on multiple different Web Browsers and were unable to reproduce the issue of being unable to download the certificate files. Perhaps, if possible, could you try using a different Web browser to see if the issue persists? Or could there be possible restrictions set on your computer/browser that don’t allow these downloads to happen properly?

Additionally, I can suggest downloading/exporting such files through the use of Task Manager:

You can do so by specifying the file location.

Regards,
M.

[Zugschlus]

You’re right. It works in Chromium. It doesn’t work in Firefox (on Linux).

Greetings, Marc Haber