IP addresses are not a secure way of identifying someone across the internet, and the translation of domain names to IP addresses is also not particularly secure.
For the web to be useful, people needed to be able to access a web site and be sure that they were communicating directly with it, not to a man in middle who was reading their traffic and forwarding it to the real web site. They wanted people to be able to do this without first having to use some other secure means of communicating with the web site and having them courier a personal encryption key.
The way they solved this was to devise encryption systems where you could encrypt with publicly available keys, but there was a different key used to decrypt, which was not made public.
You still have the problem that anyone could give you a public key and claiming they were, say your bank. To get round this your create certification authorities that are widely known and trusted (in practice you trust your browser supplier, OS supplier, phone supplier, etc. to determine which ones they think you should trust). They also have public and private encryption keys, and they encrypt the target site’s name, other information public key, using their private key, and bundle that with the clear text forms, to create a certificate. The site can then hand out the certificate, which they do whenever you make an HTTPS connection to them, and you can decrypt it it using the certification authorities public key and confirm the result matches the clear text information.
(Certification authority public keys are also distributed as certificates, but at the topmost level, they reference themselves - self signed certificates.)
An organisation can be its own certification authority, in which case it has to arrange to manually install its certification authority certificate in the browsers, phones, etc. that need to trust them.
This has become the de facto way of confirming there is no man in the middle, and choosing working encryption keys (public/private key systems are too slow to use for the main traffic, and increase its size) in nearly all cases where encryption is desired on the internet.
It is bad practice to use the same encryption key for a long time, because it gives more material for an attacker to use to try to discover it, technology advances and what was once secure may no longer be secure, and there is more chance that it may leak, e.g. through defective humans. As such, time limits are imposed on the validity of keys, and therefore the certificate that verifies them. For the last case, there was a mechanism to declare a certificate invalid, but that has never really worked in practice.
As a result of this (and some argue some cynical commercial reasons), a policy is developing of rather than having lifetimes of a year or two, they are being brought down to under a month.
There are two types of certificate that might need updating in an endpoint: that of the endpoint, and that of the certification authority. I think many people run phones without a certificate for the phone. In the case of the PC, it has to choose a new private key and convince the certifying authority that it really is who it says it is, and get them to issue a new certificate to verify the corresponding public key.
For an organisation level certifying authority, a phone specific way of installing it needs to be used. I presume that the well known ones are included in firmware updates. For PCs, etc., the well known ones are one of the things that gets updated during software updates.