This comment covers the topic of uploading SSL certificates for the Omada hardware controllers. In this comment, I have a main bug report as well as general background, root causes for problems, questions, comments, and suggestions.

 

Main Bug Report

 

When doing PEM upload, the files will not validate if they contain two or more periods. For example, "192.168.0.2.pem" will fail. This is a bug; the filename should not matter.

 

Workaround: Upload PEM files with filenames with only one period (the one right before the file extension). For example, using "cert.pem" and "key.pem" works fine.

 

Background

There is considerable dissatisfaction online having to do with uploading SSL certificates for Omada hardware controllers so that HTTPS works correctly. You can see this on Reddit on forums as well as blog posts. The root causes include the following.

 

Root Causes

 

1. Bugs in the Omada Controller regarding certificates.
2. A lack of visibility into certificate errors. (a) The UI sometimes gives a brief error message without actionable detail. (b) There is no way that I know of to get more details, such as a log file. The Omada log files seem to only track network and device behavior, not configuration.
3. Lack of support for some certificate formats. This seems to have gotten better in the last, say, nine months.
4. The complexity around certificates in general.
5. OpenSSL is quite complex, with a complicated command-line interface;
6. A lack of definitive clear documentation from TP-Link to mitigate (3) and (4), above.

 

Questions, Comments, and Suggestions

 

Bug Tracking

 

Where can users check on the status of already-filed bugs?

 

Is there a Jira system, for example? (This is not to say that I recommend Jira!)

 

Better Log Visibility

 

Give people logs and you empower them.

 

Open Source the Controller Software

 

Has TP-Link considered open-sourcing the controller software?

 

What is the company's stated position on *not* doing so yet?

 

Error Messages

 

What is TP-Link planning to do with regards to cryptic error messages?

 

Suggestion: Error messages should be handled systematically and comprehensively

I suggest that error messages include (1) a short one-line summary and (2) an error code that can be cross-referenced to documentation. Why? Source code deployments are relatively resource intensive and therefore slow. Documentation, on the other hand, can be updated rapidly.
 

For inspiration, look at how the Rust compiler error messages are handled for both end-users and compiler developers. I could not paste full links in here, but I'll try to find a way later.

Versions & Details

 

Controller version: 5.9.32

Model: OC200 2.0

Firmware Version: 2.9.3 Build 20230328 Rel.52390