Technical hiccups, for better or worse, are something every IT professional runs into sooner or later. What really matters is how we handle them: staying professional, fixing the issue quickly, and minimizing the impact on users.
I bring this up because yesterday, when I tried visiting the official website of Ubuntu’s KDE-based spin, Kubuntu (kubuntu.org), I noticed that users were being met with an HTTPS connection error message. And while that’s not really the main issue here, I’ll take a moment to share a few technical, boring details—just to help make things a bit clearer for everyone.
The kubuntu.org domain is currently presenting an HTTPS certificate issued by “Caddy Local Authority – ECC Intermediate” because this is not a public CA trusted by browsers. Instead, it’s part of the Caddy web server’s internal certificate system, used only for local testing or internal environments.
When a Caddy server is misconfigured — for example, when it’s set to use its local CA instead of publicly trusted ones by Let’s Encrypt, ZeroSSL, etc. — it issues a self-signed certificate that is valid only for a few hours (in this case, exactly 12 hours).
Of course, this kind of certificate cannot be validated by any browser because it lacks a trusted root in the global CA chain. As a result, browsers display the “Your connection isn’t private” or “Not Secure” warning and block access to the site. That’s it for the technical aspects.
Now for the more concerning part. What really surprised me is that, even 24 hours later, nothing has changed. That raises some serious questions—mainly, what kind of message does this send to users of a project that’s supposed to be an official Ubuntu flavor?
Just over two weeks ago, the website of another official Ubuntu flavor, Xubuntu, was compromised. The download button, intended to provide the installation ISO image, instead linked to a file packed with malware targeting Windows computers.
It’s been 24 hours now, and Kubuntu still hasn’t fixed the certificate issue — even though, honestly, with all due respect, it’s something that should take no more than twenty minutes to sort out — obtain the valid-signed SSL certificate from trusted public provider, point the web server’s configuration to it, reload the service, and that’s it.
What I’m trying to say is that I really don’t think this attitude to the issue, with 24 hours without taking steps to resolve it, is the kind of message Ubuntu wants to send to users of its official flavors.
Of course, if we’re talking about my home lab where I share a few services with close friends, that’s no big deal. However, this is different — we’re talking about a distro that bears the Ubuntu name, one of the most respected brands in the Linux ecosystem. Having this kind of attitude toward something as important as one’s online presence is, to put it mildly, unacceptable.
And without knowing how much freedom Ubuntu actually gives its official flavors to make their own technical decisions, maybe—and I really do mean maybe—it’s time for Canonical to step in and take a more active role in how its official flavors represent the brand. Because no matter how you look at it, the signals being sent to users, and we’re talking hundreds of thousands of them, aren’t a good one.
Kubuntu’s website is now up and running smoothly on my Dell Latitude 7490 with Waterfox 6.5.10.