Debian Curl/PHP/wget etc show an certificate error falsely

Problem: curl php wget and others show a cert error like the following since 6. Oct 2021, even though the cert has not expired:

curl: (60) SSL certificate problem: certificate has expired
More details here:

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

The asked server uses a Letsencrypt certificate.

Discussion: Currently Letsencrypt includes two chains for validation of the certificate:

  1. Cert -> R3 -> ISRG Root X1 (in new trust store)
  2. Cert -> R3 -> ISRG Root X1 -> DST Root CA X3 (in old trust stores but expired)

Chain one works for all modern OSes and browsers, but on Debian (at least with 9.0) the cert check fails because it finds the expired CA “X3” in chain 2, and does not use the direct chain with CA “X1”. Debian 9.0 includes both CA certs.

The reason to keep the expired cert in the provided chain is that some old devices need this X3 cert, and accept it despite its expire date. e.g. Android >=2.3.6 and <7.1.1

Solution: Start the following command and deactivate the expired CA cert on the client.

# dpkg-reconfigure ca-certificates

This bug is not limited to Debian because this issue seems to be related to openssl-1.1.0, which you will find in many products. Removing the expired cert might work there as well.

F5 iRule Class Match Crash

Problem: F5 iRules with “class match” crash sometimes with this message:

/Common/UA_DETECT – ambiguous option “-“: must be -all, -index, -element, -name, or -value while executing “class match [string tolower [HTTP::header User-Agent]] contains UA_STRINGS”

Discussion: the class match command has optional parameters, when the HTTP header User-Agent starts with a “-” it gets intepreted by the tcl interpreter. This is dangerous, because it’s actually a kind of code injection, with possible terrible impact.

Solution: add “‐‐” as first parameter to the class match command

class match ‐‐ [string tolower [HTTP::header User-Agent]] contains UA_STRINGS

Version: F5 LTM 12.1.2

Ubiquiti UniFi the Next Botnet ?

I tested a Ubiquiti access point today. UAP-AC-Lite seems to be a very good and cheap access-point.

When you take it out of the box and connect it to the network it gets an IP address using DHCP and waits for a configuration. In this mode it sends broadcasts to find a controller and listens on port 22 (ssh) with standard login/password of ubnt/ubnt.
That’s not best practice but very usual for devices of this kind.

I tried two configuration modes:

    1. MobileApp based using my Android Phone:
      This App looks good, and works great, if you need just one SSID and not VLAN. Thumbs up, well done ubiquiti.
      But I guess this method will not work if this is you first access point in the network, because you will end with a chicken and egg problem.
    2. UniFi Controller based:
      UniFi runs on Win/Mac and Linux. The Debian package is far to big but it installs cleanly (Why does this webapp need 27MB of fonts?).
      With this webapp you can configure everything and it works good. But then I checked the security…

First I checked what new ports are open on my server:

tcp6 0 0 :::8443            :::* LISTEN 1373/java 
tcp6 0 0 :::6789            :::* LISTEN 1373/java 
tcp6 0 0 :::8843            :::* LISTEN 1373/java 
tcp6 0 0 :::8880            :::* LISTEN 1373/java 
tcp6 0 0 :::8080            :::* LISTEN 1373/java 
udp6 0 0 MYPUBLICIP:50880   :::* 1373/java 
udp6 0 0 :::10001           :::* 1373/java 
udp6 0 0 :::3478            :::* 1373/java 
udp6 0 0 MYINTERNALIP:58426 :::* 1373/java 

That’s to much for a Linux box with a public IP interface.
The documentation tells a little bit what these ports are used for, but some are not explained or not needed for normal operation.
I tried to strip down the open ports for security reasons, but I found no way to disable unused services or at least bind only to one IP. My minimum requirement would be to bind only to an internal interface and block the public interface.

But no way (officially: )

Shure I could write an iptables filterlist to block these ports, but that’s risky. Today they use these 9 ports, but what will happen on the next update ?

Then I checked what services are actually running on these ports. It’s a tomcat server !
A java/tomcat server that listens in all directions IPv4/6 and no easy way to limit this access. What can possibly go wrong?

Most people will never update this controller software, and tomcat had and will have security problems.

Hopefully ubiquiti will provide a smaller footprint configuration tool, with a bit more settings than the app, and add some security settings to the controller software.
Then I would really recommend this nice piece of hardware: Vendor Link  ,  Amazon Link

Version: UAP-AC-Lite, unifi 5.4.11-9184