Self-signed certificates

Self-signed certificates are generally certificates generated by the device/machine that needs it. Many firewalls will generate a "self-signed" certificate on first boot-up, for example. They are not signed by any CA, so establishing a chain of trust is not scalable at all. They are usually used for test labs only because of this limitation.

Many people also refer to internally issues certificates as "self-signed" although this terminology is abused and inaccurate. For larger organizations, it is perfectly normal to stand up an internal CA and issue certificates for clients, servers, users, and more. Any machine that trusts the CA will trust all certificates issued to is, so this is far more scalable. But external machines will still throw an error since they don't trust the CA. So you'll often see this type of deployment for resources that are internal to a network (not necessarily Microsoft) where centralized policies can push out the CA's root certificate and establish trust. Deploying an enterprise (not guest) WiFi with WPA2-Enterprise, for example. Or signing internal LOB applications, updates, various management agents, etc.

The benefit of this over a wildcard public cert is that individual certificates can be revoked as needed. Have a laptop stolen? Instead of revoking the wildcard cert, you revoke the certificate used to authenticate that laptop on the corporate wireless network. Far less intrusive and far more scalable.

Then, there are public certs, which I've never heard anybody refer to as self-signed. The only difference between these and internally signed certificates is that a public CA has paid companies money and passed certificates so their root certs are pre-installed in browsers and are trusted. That is why, when you visit a site that has a certificate from GoDaddy, you don't have to install the GoDaddy root cert (or starfield, or whatever.) It behaves the same otherwise. It still checks the chain for trust. Just the root is already trusted.