Certificates and PKI: Why Every AV Web Interface Is “Not Trusted”

Why an AV engineer should care

You enter a switch, DSP or control processor’s IP address. The login page appears, immediately accompanied by:

Your connection is not private.

Often, the device is not actively attacking you. It shipped with a self-signed certificate that your computer has no reason to trust.

The warning still matters. If everyone learns to click through certificate errors automatically, nobody notices when a warning indicates an actual impersonation attempt. Today we’ll separate harmless-but-sloppy certificate problems from legitimate security problems—and fix the manageable ones.

Learning objectives

By the end of this lesson, you should be able to:

• Explain what TLS certificates do—and what they do not do.
• Understand certificate authorities and trust chains.
• Diagnose common browser certificate warnings.
• Select a practical certificate strategy for an AV system.
• Define useful certificate requirements in BMT standards.

---

1. HTTPS is performing two related jobs

When you connect to:

https://av-switch-01.client.com

TLS attempts to provide:

1. Encryption: Someone observing the network should not be able to read the username, password or configuration data.
2. Authentication: Your browser should have reasonable evidence that it is talking to the real av-switch-01.client.com.

The server’s certificate contributes to authentication by binding an identity to a public key. The corresponding private key remains on the server. RFC 5280 describes certificates as structures that bind public keys to subjects through a trusted digital signature. (rfc-editor.org) A certificate does not prove that:

• The product has no vulnerabilities.
• The web application is well written.
• The device’s administrator is trustworthy.
• The manufacturer still supports its firmware.
• The device belongs on the network.

It proves a narrower but valuable fact: a trusted issuer has associated the certificate’s stated identity with its public key, and the server can demonstrate possession of the matching private key.

---

2. The trust chain

Certificates normally form a chain:

• Leaf certificate: Installed on the switch, DSP or control processor.
• Intermediate CA: Signs leaf certificates.
• Root CA: The ultimate trust anchor.

Your computer maintains a trust store containing root CA certificates it already trusts. Public roots are generally supplied by Microsoft, Apple, Google, Mozilla or the operating-system vendor. A corporate IT department can also distribute its own private root to managed computers.

The browser validates the signatures upward:

Device certificate → Intermediate CA → Trusted root CA

If it can build and validate that chain, the issuer is trusted.

What is a self-signed certificate?

A self-signed certificate signs itself. There is no independent CA above it.

That can still encrypt traffic. The problem is identity: anyone can make a self-signed certificate claiming to be your switch. Your browser cannot distinguish the legitimate certificate from an attacker’s homemade version.

This is why “encrypted” and “trusted” are not interchangeable.

Anyone can generate a certificate; other computers trust it only when its issuing root has been deliberately placed in their trust stores. (letsencrypt.org)

---

3. The browser performs several tests

A certificate must pass more than one test. The warning details usually identify which one failed.

The classic AV name mismatch

Suppose the certificate was issued for:

av-core-01.customer.com

But the technician opens:

https://10.20.30.5

The certificate may be completely legitimate, but it does not identify 10.20.30.5. The browser requested one identity and received proof for another.

Modern certificates place valid names in the Subject Alternative Name, or SAN, extension. SAN entries can represent DNS names or IP addresses, but they must be encoded as the correct type. (rfc-editor.org) A certificate containing:

DNS:av-core-01.customer.com

does not automatically cover:

• 10.20.30.5
• av-core-01
• av-switch-01.customer.com
• Every other device on that VLAN

Use the exact hostname listed in the certificate. Although an IP address can be included as an IP SAN, stable DNS names are generally easier to manage.

---

4. Why accurate time suddenly matters again

Certificates contain a validity window:

• Not Before
• Not After

If a newly unboxed processor thinks it is January 1, 1970—or the year 2038—it may reject a valid certificate or present one that the browser considers invalid.

This gives NTP another AV job:

• Correct syslog timestamps
• Correct certificate validation
• Correct scheduled automation
• Better event correlation

BMT’s commissioning sequence should establish DNS, default gateway and NTP before testing secure web interfaces.

Otherwise, the certificate may be perfectly fine while the device is temporally living in the Nixon administration.

---

5. Three practical certificate strategies

Strategy A: Manage a factory-certificate exception deliberately

Do not blindly bypass a browser warning. Any exception requires client IT approval and verification of the device identity and certificate fingerprint through a trusted, out-of-band source. Prefer correcting trust and hostname issues; this is not a routine click-through procedure.

For an isolated, temporary or very small system, replacing every certificate may create more work than value.

If the product only supports its factory self-signed certificate:

1. Connect from the intended management network.
2. Compare the certificate fingerprint with a known value when the manufacturer provides one.
3. Change default credentials immediately.
4. Record the limitation in closeout documentation.
5. Do not tell users that every certificate warning is harmless.

This is an acknowledged limitation, not a complete fix.

Strategy B: Use the client’s internal CA

This is usually the best enterprise solution.

The client’s IT department issues certificates from an internal CA. Its root certificate is already trusted on managed workstations. Each AV device receives a unique certificate containing its assigned DNS name.

Example:

• Device IP: 10.40.12.21
• DNS name: av-qsys-01.campus.example.com
• Certificate SAN: DNS:av-qsys-01.campus.example.com
• Issuer: Client Enterprise CA

This works well when:

• The client manages its computers.
• The AV management interfaces are private.
• The products support CSR generation or certificate import.
• IT owns certificate issuance and renewal.

Strategy C: Use a publicly trusted CA

A public certificate can work when the organization owns a real domain and can validate control of it. A device does not necessarily need to be exposed to the internet; DNS-based validation can sometimes issue a certificate for an internally resolved hostname under a domain the client owns.

Example:

av-switch-01.management.example.com

This requires coordination, secure handling of private keys and a renewal process. Public CAs cannot simply certify arbitrary local names such as switch01.local; nobody uniquely owns those names. Let’s Encrypt makes the same point regarding localhost and recommends a locally trusted root for local-only certificates. (letsencrypt.org) Do not expose an AV device’s web interface directly to the internet merely to obtain a certificate. That solves the wrong problem with impressive enthusiasm.

---

6. A practical installation workflow

Where the product supports custom certificates:

1. Assign a stable management IP.
2. Create a DNS record such as av-dsp-01.site.customer.com.
3. Set DNS and NTP on the device.
4. Generate the private key and CSR on the device, if possible.
5. Include the actual management hostname in the SAN.
6. Have the client’s CA or approved public CA sign the CSR.
7. Import the signed leaf certificate and any required intermediates.
8. Browse using the exact DNS name—not the raw IP.
9. Verify the certificate chain, hostname and expiration date.
10. Record the issuer, SAN, serial number, expiration and renewal owner.

A CSR, or Certificate Signing Request, contains the public key and requested identity information. It does not contain the private key.

Generating the key on the device is preferable because the private key never needs to leave it. If external generation is required, transfer it securely and delete working copies afterward.

Never install one shared certificate and private key on every AV product. If one box is compromised, every device using that key becomes impersonable.

---

7. Commercial-AV examples

Example 1: Ruckus switch management

A technician opens https://10.10.50.5 and receives a warning.

Inspection shows:

• The certificate is self-signed.
• Its name is unrelated to the project.
• It expired two years ago.
• HTTPS still encrypts the session, but identity validation fails.

For an enterprise project, BMT should request:

• DNS record: av-sw-05.site.customer.com
• Unique certificate containing that DNS SAN
• Issuance by the client’s trusted CA
• Certificate renewal assigned to IT or the service provider

The technician then uses the hostname shown on the drawings and equipment schedule.

Example 2: DSP and control-processor interfaces

A Q-SYS Core, Biamp DSP or Crestron processor may offer HTTPS management, but certificate-management capabilities vary by model and firmware.

BMT should verify:

• Can it generate a CSR?
• Can it import a certificate and private key?
• Which formats does it accept: PEM, DER, PFX/P12?
• Can it store intermediate certificates?
• Does replacing firmware or performing a factory reset erase the certificate?
• Is there an API or management platform for renewal?

If custom certificates are unsupported, document the limitation rather than promising the client that every management page will become warning-free.

---

BMT standards takeaway

Add a Management Security section to the device schedule containing:

• Management DNS name
• HTTPS support
• Custom certificate support
• Certificate issuer
• SAN entries
• Expiration date
• Renewal owner
• Certificate backup/recovery procedure
• Behavior after firmware update or factory reset

Also require that administrative drawings and closeout records use the DNS name where practical, not only the IP address.

Practical exercise

Open the certificate details for one AV device that produces a browser warning. Record:

1. Issuer
2. Subject and SAN entries
3. Valid-from and expiration dates
4. Hostname or IP used in the browser
5. Whether the chain reaches a trusted root

Then identify the exact failure:

• Unknown issuer?
• Name mismatch?
• Expired certificate?
• Incorrect clock?
• Missing intermediate?
• Obsolete TLS?

Do not install or trust anything during the exercise. Diagnose first.

Compact glossary

• TLS: Protocol that secures the network session.
• HTTPS: HTTP carried inside TLS.
• PKI: Public Key Infrastructure—the certificates, authorities, policies and processes supporting trust.
• CA: Certificate Authority.
• Root CA: Highest trust anchor in a certificate chain.
• Leaf certificate: Certificate installed on the endpoint.
• SAN: Subject Alternative Name; lists identities covered by the certificate.
• CSR: Request submitted to a CA for certificate issuance.
• Private key: Secret key retained by the device.
• Trust store: Root certificates trusted by an operating system or application.

Review questions

1. Can a self-signed certificate still encrypt traffic?
2. Why does a valid certificate for av-core-01.example.com produce a warning when accessed through 10.20.30.5?
3. What must BMT document besides the certificate’s expiration date?

Answers

1. Yes. It can provide encryption, but the browser cannot independently validate the server’s identity.
2. The requested IP address does not match the certificate’s DNS identity.
3. The issuer, SAN, renewal owner, replacement procedure and what happens after resets or firmware updates.

Where we are headed

This completes our practical introduction to certificates and PKI. Lesson 16 will cover secure remote AV support: why direct port forwarding is dangerous, and how VPNs, jump hosts, vendor cloud services and zero-trust access can provide support without leaving a control processor hanging naked on the public internet. The requested USB 2/3, USB-C, PD and DisplayPort Alt Mode primer is also coming soon.