Do not use an IP Address as a Domain Name

Public TLS certificates are built around verified domain names, not around treating an IP address like it is a hostname. In practice, that means you should request a certificate for the actual DNS name users connect to, such as vpn.example.edu or mail.example.edu, rather than trying to make a raw IP address serve as the site’s identity. This matters for both security and operations. DNS names are easier to understand, easier to manage, and easier to change when infrastructure moves behind a load balancer, proxy, failover system, or cloud migration.

IP addresses are much more brittle: they can change, they are harder for humans to validate, and they often encourage people to bypass the naming and ownership controls that certificate processes are designed around. The CA/Browser Forum has also continued tightening rules around IP-related validation and reverse-address techniques, reflecting the industry’s preference for stronger, DNS-based proof of control instead of loose or ambiguous identity practices.

A simple example: if a server is moved from 128.83.x.x to a new address, a certificate tied to a stable DNS name can continue to work after DNS is updated, while a certificate strategy centered on the IP itself becomes a maintenance headache and a future outage waiting for coffee time.

Avoid multiple copies of any private key

A certificate’s private key is the secret that proves the certificate really belongs to you. The more copies of that key you make, the larger your attack surface becomes. Every backup, copied file, admin laptop, shared folder, configuration management export, or forgotten test system becomes one more place that key can be stolen, mishandled, or left behind after staff turnover. If a private key is compromised, an attacker may be able to impersonate your service, decrypt traffic in some circumstances, or carry out man-in-the-middle attacks until the certificate is revoked and replaced. Good practice is to generate keys in the system that will use them, protect them with strong access controls, store them elsewhere only where necessary, and rotate them cleanly when replacing certificates.

In higher education environments especially, where responsibilities are often distributed across central IT, departmental admins, and research systems, key sprawl can happen quietly. Keeping one controlled copy per deployment target is usually far safer than letting the same private key drift across multiple administrators and machines like an unchaperoned house key ring. CA/B Forum rules and related PKI practice documents emphasize lifecycle management, issuance safeguards, and protection of certificate-related material precisely because weak key handling undermines the trust model the certificate is supposed to provide.

Avoid wildcard certificates

Wildcard certificates, such as *.example.edu, are convenient because one certificate can cover many subdomains. That convenience is exactly why they deserve caution. A wildcard private key often ends up protecting a very broad slice of your environment, so if that one key is compromised, the impact can extend across many hosts and services instead of only one.

Wildcards also make it easier to blur ownership boundaries between teams or departments: the same certificate may quietly get reused on unrelated systems, which increases risk and makes incident response harder. They can also encourage overbroad trust—someone deploying a service under a covered subdomain may inherit certificate coverage without the tighter review that a host-specific certificate would have forced.

In most environments, individual certificates for specific names such as login.example.edu, api.example.edu, or hr.example.edu create better isolation, clearer ownership, and smaller blast radius. Wildcards still have valid use cases, especially in heavily automated environments, but they should be treated as exceptions rather than defaults. As certificate lifetimes shrink and automation becomes more common, the old operational reason for leaning on wildcards—“it’s easier than managing lots of certs”—gets weaker, while the security downside remains very real.

Where do changes in certificate use come from?

The CA/Browser Forum

The CA/Browser Forum is the main industry body where certificate authorities and browser/application vendors coordinate requirements for publicly trusted certificates. Its Baseline Requirements define core expectations for issuance, validation, lifecycle management, and auditing of public TLS certificates. Those requirements are not just abstract guidance; they are the framework that CAs use and that browser vendors rely on when deciding what should be trusted. The Forum updates these requirements over time to respond to new threats, implementation weaknesses, and operational lessons learned across the web PKI. In other words, when certificate practices change industry-wide, the change usually starts as discussion and ballots in the CA/B Forum, then lands in updated Baseline Requirements, and then becomes something certificate providers and subscribers must actually follow.

CA/Browser Forum Meets in Person

Your note about two in-person meetings each year is directionally right. The CA/Browser Forum publishes face-to-face meeting minutes, and those records show a regular pattern of in-person meetings alongside other working-group activity. Those meetings are where browser representatives, CAs, and other participants discuss ballots, operational concerns, validation methods, revocation practices, and upcoming changes before they become formal requirements. The public ballots page then shows how those discussions turn into specific proposed and passed changes. So the process is not “a rule appears out of nowhere”; it is usually discussion, drafting, debate, voting, publication, and then rollout into the Baseline Requirements.