Message hash algorithm '/<path>/ta.key' not found

gartom

Hi,
I had to redo all my customized OpenVPN settings on my Synology NAS, as I have lost the possibility to sign new client certificates with the original CA I used when I set up the environment in 2016. Now when I am doing all things from "scratch" again, I don't seem to get past the tls-auth part of the connection, if I understand correctly. The end part of the logfile (with verb 11) is:

Thu Feb 3 02:14:04 2022 us=805713 Diffie-Hellman initialized with 4096 bit key
Thu Feb 3 02:14:04 2022 us=807197 Message hash algorithm '/usr/syno/etc/packages/VPNCenter/openvpn/mykeys/ta.key' not found
Thu Feb 3 02:14:04 2022 us=807269 Exiting due to fatal error

I have created a new PKI with all the needed certs and keys using XCA on Windows, and generated the 'ta.key' on the Synology NAS itself (if that would even matter). I also exported the client cert/key to a PKCS#12 file that I imported to Windows credential storage in the same way I had it before.

The only thing that I am doing differently on purpose is that I increased the dh key to 4096 bits from 2048 bits that I used before. The (pre-installed) openvpn version on the Synology NAS is somewhat old (?):
Thu Feb 3 02:14:04 2022 us=702225 OpenVPN 2.3.11 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Sep 22 2021
Thu Feb 3 02:14:04 2022 us=702271 library versions: OpenSSL 1.0.2u-fips 20 Dec 2019, LZO 2.09

What can be wrong? Where to start looking?

I checked the source code to get an understand what part is throwing the error but could not really understand how the function is called:

static const mbedtls_md_info_t *
md_get(const char *digest)
{
    const mbedtls_md_info_t *md = NULL;
    ASSERT(digest);

    md = mbedtls_md_info_from_string(digest);
    if (!md)
    {
        msg(M_FATAL, "Message hash algorithm '%s' not found", digest);
    }
    if (mbedtls_md_get_size(md) > MAX_HMAC_KEY_LENGTH)
    {
        msg(M_FATAL, "Message hash algorithm '%s' uses a default hash size (%d bytes) which is larger than " PACKAGE_NAME "'s current maximum hash size (%d bytes)",
            digest,
            mbedtls_md_get_size(md),
            MAX_HMAC_KEY_LENGTH);
    }
    return md;
}
bool
md_valid(const char *digest)
{
    const mbedtls_md_info_t *md  = mbedtls_md_info_from_string(digest);
    return md != NULL;
}

Shall I interpret the error that openvpn can't access the file for some reason?
I made sure to set root as owner for the file and folder and access rights are '400', i.e. the same as for 'dh4096.pem' that is in the same folder.
Part of openvpn config:

dh /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/dh4096.pem
ca /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/XXXXXXXXXXX_CA.crt
cert /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/Server.crt
key /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/Server.key
tls-auth /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/ta.key 0

The ta.key is added inline in the 'client.ovpn' configuration file.

I plan to post more details about server and client config files as soon as I have time.

gartom

Full server config:

push "route 192.168.111.0 255.255.255.0"
push "route 10.8.0.0 255.255.255.0"

# Use routing instead of bridging
dev tun
server 10.8.0.0 255.255.255.0

management 127.0.0.1 1195

# The backup task will include this location
dh /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/dh4096.pem
ca /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/XXXXXXXXXX_CA.crt
cert /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/Server.crt
key /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/Server.key
tls-auth /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/ta.key 0

max-clients 5

#comp-lzo

cipher AES-256-CBC
data-ciphers AES-256-CBC

persist-tun
persist-key

# verb 3
# Verbose logging for debug
verb 11

# Don't forget logrotate script
log-append /var/log/openvpn.log

keepalive 10 60
reneg-sec 0

plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf

# KEEP THIS DISABLED
#client-cert-not-required
username-as-common-name
duplicate-cn

status /tmp/ovpn_status_2_result 30
status-version 2
proto udp6

port 1194

Client ovpn file:

client
dev tun
proto udp

remote <my-host>.<my-domain>.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server

# WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set. <-- If comp-lzo is set
# comp-lzo

auth-user-pass
key-direction 1
cipher AES-256-CBC
data-ciphers AES-256-CBC

# This is for using PKCS12 certs imported into Windows credential storage.
cryptoapicert "THUMB:XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX"

<ca>
-----BEGIN CERTIFICATE-----
MIIF/jCCA+agAwIBAgIIEcLp+uHgAG4wDQYJKoZIhvcNAQELBQAwgZQxCzAJBgNV
PfkTbzRO5wS3IoaXLc0bvTAge1nUu47TTrFpHnAshPlXjCX3YH1p5MR0Oj96Pbtr
|
|
|
GWvcPLn9LBcthjdkpgYZrPI6qnEMfIIOx+fp9AKuE40RszrPrnukSKNCEnMGkslf
1hDvve5tMfEVOYjWxXcj/UIqFVLapJLOgi3+cJhRA/inhLas6njS89fK3xJnnxSW
mMYAt3PWx9aXW2rl/ji8Hz7DNjOgeoL1yEdyNypPjU4ZH54PzIejLyoYP5kJbbzT
-----END CERTIFICATE-----
</ca>

<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
de522bbb8ce83e64fa16218a7bb1ba01
71528938a33c3bd66895cb92ae3d3252
|
|
|
199753c1aaaffe177bef94d02bf5fbb2
994b21ad7558fc7a6ddcb98cfaa066f4
-----END OpenVPN Static key V1-----
</tls-auth>

TinCanTech

gartom wrote Thu Feb 3 02:14:04 2022 us=807197 Message hash algorithm '/usr/syno/etc/packages/VPNCenter/openvpn/mykeys/ta.key' not found

This error message suggest that you have the following in your server config

auth /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/ta.key 0

Note: 'tls-' is missing.

(I presume this key is inlined in your client).

gartom

TinCanTech wrote This error message suggest that you have the following in your server config

auth /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/ta.key 0

Note: 'tls-' is missing.

(I presume this key is inlined in your client).

Thanks for the suggestion. Unfortunately that does not seem to be the issue as shown in my 2nd post above.

You are correct, the key is inlined in the client config (also shown in 2nd post above).

TinCanTech

gartom wrote The (pre-installed) openvpn version on the Synology NAS is somewhat old (?):
Thu Feb 3 02:14:04 2022 us=702225 OpenVPN 2.3.11 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Sep 22 2021
Thu Feb 3 02:14:04 2022 us=702271 library versions: OpenSSL 1.0.2u-fips 20 Dec 2019, LZO 2.09

Actually, the openvpn version is old but it was built recently.

Anyway, the error message is due to not being able to find a HASH algorithm and nothing to do with either --tls-auth or a missing file. I have no idea how your NAS works, so you may have to report this to your NAS vendor.

gartom

Ok, thanks for helping.

What I don't understand is why it stopped working when I replaced the keys and certificates. How can the inability to find a HASH algorithm be related to that change?

TinCanTech

Sorry, your OpenVPN version is not supported by us any longer: https://community.openvpn.net/openvpn/wiki/SupportedVersions

The version that you have has been built in 2019 and then you updated your NAS and installed it.
I would check to see if there is an up to date version of openvpn available and if not then complain to your vendor.

Considering how easy it is to keep openvpn upto date on their devices, I must conclude that they are all ..

gartom

Yes, I understand that it is an old version of openvpn on the NAS, but what I don't understand is why it stopped working with my new configuration.

TinCanTech

Try setting it up again. If it happens again then it's possibly a bug in the NAS GUI.

gartom

Thanks for supporting. I am not using the NAS OpenVPN GUI at all as it does not enable enough security to be set up. Instead, It recognizes that I define my own configuration file and the GUI can be used for enabling/disabling OpenVPN.

The only other change I made (except updating certificates) was to update dh to 4096 bits instead of 2048 bits. I will try to go back to 2048 to see if that makes a change. If not, I will try to set up OpenVPN in my router instead (that I just found out have the possibility as well).

gartom

The OpenVPN settings in my router did not provide the security options that I want, so I am still trying to get the OpenVPN configuration to work on my NAS (despite the old OpenVPN server version).

In an effort to start over from the beginning, I tried to restore everything to the original settings with my old CA configuration. The strange thing is that I now get the same error message with the old configuration. Any ideas around what can be the issue?

Log file entry with original CA setup:

Wed Feb  2 18:46:37 2022 Diffie-Hellman initialized with 2048 bit key
Wed Feb  2 18:46:37 2022 Control Channel Authentication: using '/usr/syno/etc/packages/VPNCenter/openvpn/mykeys/ta.key' as a OpenVPN static key file
Wed Feb  2 18:46:37 2022 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Feb  2 18:46:37 2022 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication

First log file entry after changing to new CA setup:

Wed Feb  2 23:03:22 2022 Diffie-Hellman initialized with 4096 bit key
Wed Feb  2 23:03:22 2022 Message hash algorithm '/usr/syno/etc/packages/VPNCenter/openvpn/mykeys/ta.key' not found
Wed Feb  2 23:03:22 2022 Exiting due to fatal error

Log file entry when reverting to original CA setup:

Sat Feb 12 11:43:20 2022 Diffie-Hellman initialized with 2048 bit key
Sat Feb 12 11:43:20 2022 Message hash algorithm '/usr/syno/etc/packages/VPNCenter/openvpn/mykeys/ta.key' not found
Sat Feb 12 11:43:20 2022 Exiting due to fatal error

I guess the old saying "don't fix it if it ain't broke" applies... :-)

(but in this case it was actually my only option to change CA setup to be able to add users as I lost the ability to add users in my old CA config)

TinCanTech

gartom wrote Message hash algorithm '/usr/syno/etc/packages/VPNCenter/openvpn/mykeys/ta.key' not found

The command you have in your config is incorrect.

gartom

TinCanTech wrote
gartom wrote Message hash algorithm '/usr/syno/etc/packages/VPNCenter/openvpn/mykeys/ta.key' not found
The command you have in your config is incorrect.

Which command do you mean?

TinCanTech

https://forums.openvpn.net/viewtopic.php?f=6&t=33663&p=104924#p104713

gartom

I've tried both "tls-auth" and "auth" command. Neither of them works.

TinCanTech

They are not interchangeable .. You must use the correct one and it must have the correct parameter.

I have no idea what you have done ..maybe you are looking at the wrong file ..

gartom

Thanks for trying to help. I will try to "remove" security to see if can get a connection again and work from there.

gartom

TinCanTech wrote I have no idea what you have done ..maybe you are looking at the wrong file ..

I listed the full config in my second post... :-)

TinCanTech

You are using an unsupported version of openvpn: https://community.openvpn.net/openvpn/wiki/SupportedVersions

Ask who-ever built it for you.

gartom

TinCanTech wrote You are using an unsupported version of openvpn: https://community.openvpn.net/openvpn/wiki/SupportedVersions
Ask who-ever built it for you.

It's an old Synology DS412+ NAS that I have used for a long time that has this old OpenVPN image. I have no hope of getting Synology to build a newer version for this old HW.

As mentioned, the reason for changing the settings was that I lost the ability to add more clients in the CA so I had to setup a new PKI, and I had a working setup before.

Anyhow, after re-doing a lot of the steps, I got it working again.

The final server config looks like this:

# <XXXXXXXX LAN> specific config
server 10.8.0.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"
push "route 192.168.xxx.0 255.255.255.0"

# The backup task will include this location
dh /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/dh4096.pem
ca /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/XXXXXXXX_CA.crt
cert /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/Server.crt
key /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/Server.key
tls-auth /usr/syno/etc/packages/VPNCenter/openvpn/mykeys/ta.key 0

### Generic config below

management 127.0.0.1 1195

topology subnet
push "sndbuf 0"
push "rcvbuf 0"
sndbuf 0
rcvbuf 0

# Use routing instead of bridging
dev tun
proto udp
port 1194
max-clients 5
fast-io
comp-lzo no

cipher AES-256-CBC
# option "data-ciphers" not supported by OpenVPN 2.3.11 running on Synology DS412+
# data-ciphers AES-256-CBC

prng SHA256 32
auth SHA256

tls-version-min 1.2 or-highest
remote-cert-tls client

persist-tun
persist-key

verb 3

# Don't forget logrotate script
log-append /var/log/openvpn.log

keepalive 10 60
reneg-sec 0

plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf

username-as-common-name
duplicate-cn

status /tmp/ovpn_status_2_result 30
status-version 2

And the final client config looks like this:

client
dev tun
proto udp

remote <my-host-ip> 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server

comp-lzo no

auth-user-pass
key-direction 1
cipher AES-256-CBC
data-ciphers AES-256-CBC

# This is for using PKCS12 certs imported into Windows credential storage. Unique for each client cert.
cryptoapicert "THUMB:XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX"

# Don't know why this route is not pushed by server... - Added to get access to local LAN
route 192.168.xxx.0 255.255.255.0

auth SHA256

<ca>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</ca>

<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
-----END OpenVPN Static key V1-----
</tls-auth>

As said, everything works now but I don't understand why I can't get the LAN IP range pushed to the client so it shows up in the routing table. I have to add it explicitely in the client config which I don't like. I want my client configs to be agnostic about the LAN config and get the correct routing table upon connection. I consider it good enough for now, though.