Certificates are all about trust. The data is public, not encrypted, but you still want some way to know that it was generated by a "good guy", and that it hasn't been tampered with.
For example, on github you may see commits as "verified". Commonly this is done on commits that Github themselves made, such as merging a pull request (whom you trust, because they're Github), or by someone that Github trusts. If you can't trust Github, then that "verified" badge realistically means nothing, because they, as a "bad guy" could have tampered with the commit, and you would still verify it successfully. But as long as Github can show that they're not tampering with commits, and that they're not compromised, then you can trust that a "verified" commit is exactly the change that it was intended to be by the creator.
This notion of trust comes down to cryptographic signatures. Basically, someone wanting to sign a commit will generate a pair of public and private keys, and then pass the commit through a tool like GPG, along with your private key. The result is a signature that can only be generated by the private key, and can only be verified by the public key. You then publish the public key so that anyone can check that the signature is valid, and since the public key is related to the private key, it gives you assurance of who created that signature. Furthermore, you can verify that the commit hasn't been tampered with, because a tampered commit will also make the signature fail verification,since the signature is based on the original data.
To complete the example above, Github knows who it can trust by you giving them your public key. That way, when you sign a commit, they can verify the signature, and only commits from its matching private key will show as "verified". So in all, if you can trust the person who signed a commit, you can also trust that they are the only one who created the commit.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Certificates are all about trust. The data is public, not encrypted, but you still want some way to know that it was generated by a "good guy", and that it hasn't been tampered with.
For example, on github you may see commits as "verified". Commonly this is done on commits that Github themselves made, such as merging a pull request (whom you trust, because they're Github), or by someone that Github trusts. If you can't trust Github, then that "verified" badge realistically means nothing, because they, as a "bad guy" could have tampered with the commit, and you would still verify it successfully. But as long as Github can show that they're not tampering with commits, and that they're not compromised, then you can trust that a "verified" commit is exactly the change that it was intended to be by the creator.
This notion of trust comes down to cryptographic signatures. Basically, someone wanting to sign a commit will generate a pair of public and private keys, and then pass the commit through a tool like GPG, along with your private key. The result is a signature that can only be generated by the private key, and can only be verified by the public key. You then publish the public key so that anyone can check that the signature is valid, and since the public key is related to the private key, it gives you assurance of who created that signature. Furthermore, you can verify that the commit hasn't been tampered with, because a tampered commit will also make the signature fail verification,since the signature is based on the original data.
To complete the example above, Github knows who it can trust by you giving them your public key. That way, when you sign a commit, they can verify the signature, and only commits from its matching private key will show as "verified". So in all, if you can trust the person who signed a commit, you can also trust that they are the only one who created the commit.