Sysadmin 17.0.3.8: Port Management and HTTPS Setup throw on a certificate with an empty subject

Hello,

I am aware that support for commercial modules are supposed to be handled via support tickets, but I don’t have a support contract and would like to report this anyway. This refers to the free version of System Admin module, and I don’t know where else to report because this wouldn’t be accepted on Github either.

We use certbot to handle certificates renewals on our system and if we receive a cert with an empty Subject (which is valid), all the HTTPS handling in Module Admin breaks.

Environment: FreePBX 17, sysadmin 17.0.3.8, framework 17.0.33.2, certman 17.0.3.15, Debian 12, PHP 8.2.35, Apache 2.4.68.

Problem
A certificate with an empty subject and a critical SAN is valid (RFC 5280) and is accepted by browsers. After installing one for Apache, Port Management and HTTPS Setup fail with:

Unexpected output from openssl - subject=
SSL.class.php:161, parseOpenSSLOutput, called from getSSLSettingsAjax (views/portmgmt.php:38)

Steps to reproduce

  1. Set a certificate with an empty subject as the default in Certificate Manager.
  2. Run: fwconsole sa ihc --set=
    It prints " has been installed successfully" and exits 0.
  3. Open Admin > System Admin > Port Management.

Expected: the page renders, or ihc refuses the certificate with a clear error.
Actual: an exception on every load.

Findings

  • getSSLSettingsAjax runs: openssl x509 -in /var/run/asterisk/ssl/webserver.crt -noout -subject -issuer
  • parseOpenSSLOutput throws on “subject=”. It accepts “subject=CN = x” and “subject=O = x”.
  • The pages rendered again after removing the files ihc created under /var/run/asterisk/ssl/.
    We had also removed /etc/apache2/pki/webserver.* and the kvstore key apache-cert.

Certificates issued without a subject are becoming more common: Let’s Encrypt’s tlsserver
and shortlived profiles omit the CN.

Honestly, I would gladly avoid having the module managing HTTPS at all if I could, but it seems to have a nasty tendency to silently disable any other Apache vhosts on every update (which while we are at it, could be made configurable at least).

In any case, thanks!