Summary
I met errors on pkg_add and syspatch just after installing OpenBSD on VirtualBox the other day.
They were printed as TLS handshake failure and I solved by modifying /etc/installurl.
However, I didn't know what actually it happened and why.
I Finally found it had been because of wrong time of the machine thanks to kind comments from @yoshi_kaw (Yoshihiro Kawamata). He is a developer of FuguIta (河豚板) OS , a lightweight live system based on OpenBSD.
The point is that it fixes the TLS handshake failure to correct the system time. There are a few ways:
- Run
rtimeto NTP server (temporarily, for required every time) - Configure motherboard on VirtualBox VM
- Set
kern.utc_offsetin/etc/sysctl.conf- Alternative to 2.
Course of events and description
Creating VM
I started up VirtualBox and create a new VM and attached OpenBSD ISO to it.
Then I installed OpenBSD following the installer.
Well, my setting on timezone was:
What timezone are you in? ('?' for list) [Asia/Tokyo]
Then, I was asked after files copied:
Time appears wrong. Set to 'Fri Feb 17 23:50:51 JST 2022'? [yes]
Here, neither "yes" nor "no" did work...😅
TLS handshake failure
Just after it, I started the new system. In the VM, unfortunately, both syspatch and pkg_add returned the error below:
$ doas pkg_add -u
https://cdn.openbsd.org/pub/OpenBSD/7.0/packages-stable/amd64/: TLS handshake failure: ocsp verify failed: ocsp response not current
https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: TLS handshake failure: ocsp verify failed: ocsp response not current
https://cdn.openbsd.org/pub/OpenBSD/7.0/packages/amd64/: empty
Nevertheless ping was successful:
$ ping cdn.openbsd.org
ping cdn.openbsd.org
PING cdn.openbsd.org ((...)): 56 data bytes
64 bytes from (...): icmp_seq=0 ttl=254 time=76.429 ms
64 bytes from (...): icmp_seq=1 ttl=254 time=45.498 ms
^C
--- cdn.openbsd.org ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 45.498/60.964/76.429/15.465 ms
How wrong the time was
Here, I printed the system date and time.
$ date
Fri Feb 18 08:51:52 JST 2022
No way. It was night on Feb 17. It seemed set 9 hours fast.
How to fix it
rdate (temporarily)
How could I correct it? rdate! I used time.cloudflare.com, NTP server provided by CloudFlare, a company building "a global network designed to make everything you connect to the Internet secure, private, fast, and reliable".
$ rdate time.cloudflare.com
Thu Feb 17 23:51:28 JST 2022
Then I checked again.
$ date
Thu Feb 17 23:51:53 JST 2022
Yay, fixed.
Now both pkg_add and syspatch will end up with success.
Configure motherboard on VirtualBox VM
As to this issue, rdate has a problem. You have to run it every time you boot up. It's really inconvenient.
Check "Hardware Clock in UTC Time" as below, and it'll be fixed permanently!
(Optional) Set kern.utc_offset in /etc/sysctl.conf
It is an alternative way to configure vm. Configure kernel instead.
Create /etc/sysctl.conf and write the below in it:
kern.utc_offset=540
Then reboot. You'll see the system information modified:
kern.utc_offset: 0 -> 540
Fixed
Then, happily, pkg_add and syspatch finished successfully.
$ doas pkg_add -u
quirks-4.54 signed on 2022-02-16T11:41:33Z
quirks-4.54: ok
$ doas syspatch
Conclusion
At the first steps in TLS handshake, client sends CliendHello to server, and server replies ServerHello.
Here, incorrect system time of client resulted in failure saying "ocsp verify failed: ocsp response not current". It is because CA (Certificate Autorities) cannot verify server certificate at the future time. (OCSP means Online Certificate Status Protocol.)
It is possible to fix it to configure system time via VM settings or kernel conf. Also, running rdate to your NTP server is useful temporarily.
Top comments (0)