content: The keys would be nearly useless, because its the server side key not a critical any-domain signing key, and the server side key is meant to be protected for a variety of reasons, but if you had for example someones ssl xxx.key and xxx.cert files, the thing is associated right in the record itself with a domain, or a subdomain, or sometimes a "wildcard" (*) domain, but the word DOMAIN is important in this context. The record in SSL (HTTPS) is used along with DNS. So the DNS server record points to the machine to go to, and the machine has to have ssl certificate matching the domain someone is using at that ip address as well. traditionally you use one ip per ssl , but in recent years you can concatenate a few.  The cert has no value if stolen other than as part of a NSA man in the middle along the exact ip path to the same target IP from the dns record. someone getting all your ssl key types including the messages signing ones could sign documents in your name, but for https purposes it requires an attack on DNS as well. regarding root : On macintosh os x machines there no longer is root unless you boot a special way, and also setup a root and root password with another tool. Nevertheless I understand you mean that people on a machine could possibly copy the files somehow. It is possible in a file server (web server, node web server, apache, etc) to store certs in memory ram only  and write gibberish over the disk source files or keep them in unmounted after boot volume with a password. But its not a big deal if you loose them the way you are thinking. To issue a new SSL requires control of the email server email accounts with the domain as part of a special set of allowed email addresses. If an IT contractor stole a copy of the whole hard drive, and also got passwords to control all DNS server records everywhere... that would be a problem, but the real owner would revoke the ssl certificates and get new ones issued or would use their power account for their domain record to redirect the 2 or 3 (sometimes 5) primary authoritative DNS servers to use new trusted servers under the owners control and delist the old ones the it contractor took over. propagation in 1 to 2 days max would flush out all the old cached dns records to the compromised dns servers. If you know that key and cert files might be copied, you can add the untrusted old SSL Certificate to the Certificate Revocation List (CRL). This will alert other participants in the Public Key Infrastructure (PKI) that the certificate in question can no longer be trusted, but your new SSL key files would not be on that blacklist database. You cant steal a web site really without stealing control of domain records and email that controls ssl records and domain itself. if that still happens... then a photo id tied to corporate documents sent to the .com registrar and a legal notice can still steal it back if you are merely regaining legit ownership you had prior.