Re: OpenSSL: error:0308010C:digital envelope routines::unsupported while reading CRL
Antonio Quartulli <[email protected]>
| Newsgroups | gmane.network.openvpn.user |
|---|---|
| Message-ID | <[email protected]> |
Hi, On 29/11/2023 16:19, Aleksandar Ivanisevic wrote: > > >> On 29. Nov 2023, at 12:23, Antonio Quartulli <[email protected]> wrote: >> >> Hi, >> >> On 29/11/2023 11:21, Aleksandar Ivanisevic wrote: >>> what is your openssl version, maybe that has something to do with it? mine is >>> OpenSSL 3.0.11 19 Sep 2023 (Library: OpenSSL 3.0.11 19 Sep 2023) >> >> Same as yours. You can see it in my previous email: >> >> 2023-11-28 15:01:34 us=767885 library versions: OpenSSL 3.0.11 19 Sep 2023, LZO 2.10 >> >>>> Do you see this error upon *every* client connect? >>> yes, every connect is the same sequence (on verb 4): >> >> makes sense, because if the file has somehow changed and loading fails, it will retry every time. > > yes, but the same exact config with the only addition being "providers legacy default” does not show the error? > I am speculating here, so bear with me. Assuming you have 2 different files, one loaded at startup and one being read at runtime, I am imagining that this second file is old and was created with MD5 as hash. Hence using the legacy provider is fixing the issue as the second file is now accepted too. > >> >> Could you please share your config? >> It may contain important details that otherwise we can only speculate on. > > here it is: thank you for sharing this > ----------------------------------- > mode server > tls-server > management 127.0.0.1 5001 > script-security 3 > multihome > > > topology subnet > push "topology subnet" > ifconfig 192.168.13.1 255.255.255.0 > ifconfig-pool 192.168.13.10 192.168.13.253 255.255.255.0 > route-gateway 192.168.13.1 > push "route-gateway 192.168.13.1" > push "route 192.168.13.0 255.255.255.0" > > inactive 900 > > port 5001 > proto udp > dev tun0 > mute-replay-warnings > passtos > > # https://github.com/wangyu-/UDPspeeder/wiki/UDPspeeder-openvpn-config-guide > # but it can be useful in general > sndbuf 2000000 > rcvbuf 2000000 > txqueuelen 4000 > push "sndbuf 2000000" > push "rcvbuf 2000000" > > ca /home/support/config/vpn/ca.crt > key /home/support/config/vpn/ca.key > cert /home/support/config/vpn/server.crt > crl-verify /home/support/config/vpn/2e.crl > dh /home/support/config/vpn/dh2048.pem > > # send notifications for more graceful server and client restarts > explicit-exit-notify 1 > push "explicit-exit-notify" > > keepalive 10 30 > comp-lzo > max-clients 150 > user root > group root > persist-key > persist-tun > status /var/run/openvpn/openvpn-status.log > > # maybe fix the spurious ssl errors like > # OpenSSL: error:0308010C:digital envelope routines::unsupported while reading CRL > providers legacy default > > route-up /home/support/config/vpn/routes.sh > down /home/support/config/vpn/routes.sh > client-config-dir /home/support/config/vpn/ccd > ccd-exclusive > > verb 4 > ---------------- > the rest is just a bunch of > > route xxxx > push “route xxx" > > > routes.sh is > ------------------ > #!/bin/sh > action=$6 > logger "routes.sh $@" > case "$action" in > init|restart) > systemctl try-restart nftables > systemctl try-restart snmpd > ;; > esac > > exit 0 > > > this is the systemd unit, im actually mounting the config dir read only, one reason less for the crl to change Rather than the CRL changing, I am trying to imagine if the CRL is being "substituted" between startup and runtime. This is why I speculated about chroot. Mounting the config folder is not far from that, but I presume the mount happens before starting the openvpn process, so I can't see how you end up with a different file. Does /home/support/config/vpn/ contain anything before starting the openvpn process (and thus mounting the config dir)? Cheers, -- Antonio Quartulli _______________________________________________ Openvpn-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openvpn-users