When you imported a key (be in primary secret key or primary public key), or you were given a primary public key for applying certification, you need to do what it is called "certify" process. This guide shows you how to certify a given primary secret key or primary public key.
For advanced users who deleted their "certify" capability secret key, you need to restore it back for key creations. You can verify it by using the following command:
$ gpg --list-secret-keys
Example:
$ gpg --list-secret-keys
...
---------------------------
sec rsa4096 2020-01-10 [C]
AC51A10307C10B2A4BB1C89AF5EF57A0FB4EF0EF
uid [ultimate] "Shotgun" John, Smith (Main ID) <john.smith@email.com>
You want to observe the key with [C
] capability and the sec
label does not have a hash ("sec#
"). If it does, you need to restore the key by loading the backup copy and use the following command to restore it:
$ gpg --import /path/to/you/key.asc
The next thing is to ensure the target primary key is available in your local GnuPG keyring. Go ahead and import the keyfile:
Now is to apply the certification.
We start off by obtaining your primary key ID and the targeted sub-key. This is by using the following command and find your key:
gpg --list-secret-keys
Example:
$ gpg --list-secret-keys
...
---------------------------
sec rsa4096 2020-01-10 [C]
AC51A10307C10B2A4BB1C89AF5EF57A0FB4EF0EF
uid [ultimate] "Shotgun" John, Smith <john.smith@company.com>
uid [ultimate] "Shotgun" John, Smith (Main ID) <john.smith@email.com>
ssb rsa4096 2020-01-10 [S] [expires: 2022-01-09]
ssb rsa4096 2020-01-10 [E] [expires: 2022-01-09]
ssb rsa4096 2020-01-10 [A] [expires: 2022-01-09]
ssb ed25519 2020-01-10 [S] [expires: 2022-01-09]
ssb ed25519 2020-01-10 [A] [expires: 2022-01-09]
ssb cv25519 2020-01-10 [E] [expires: 2022-01-09]
In the example above,
AC51A10307C10B2A4BB1C89AF5EF57A0FB4EF0EF
. Make sure this is the primary key you wanted to export.The next step is to identify the target primary key ID. This is done through the following command:
gpg --list-keys
Example:
$ gpg --list-keys
...
---------------------------
...
sec rsa4096 2018-09-23 [SC]
1F6E1C8C1F1A3458A267EEFD445AC05FC0F56EA9
uid [ unknown ] Jane (Michael) Smith (Personal Individual Identity) <jane.smith@example.com>
ssb rsa4096 2018-09-23 [E]
ssb rsa4096 2018-09-23 [E]
ssb rsa4096 2018-09-23 [S]
In the example above,
1F6E1C8C1F1A3458A267EEFD445AC05FC0F56EA9
. Make sure this is the target key with unknown trust level.To certify key, you do the following command:
$ gpg -u <secret key ID> --sign-key <target public key ID>
Based on the example above:
$ gpg -u AC51A10307C10B2A4BB1C89AF5EF57A0FB4EF0EF --sign-key 1F6E1C8C1F1A3458A267EEFD445AC05FC0F56EA9
The next step is to verify your certification. This is done through the following command again:
gpg --list-keys
Example:
$ gpg --list-keys
...
---------------------------
...
sec rsa4096 2018-09-23 [SC]
1F6E1C8C1F1A3458A267EEFD445AC05FC0F56EA9
uid [ full ] Jane (Michael) Smith (Personal Individual Identity) <jane.smith@example.com>
ssb rsa4096 2018-09-23 [E]
ssb rsa4096 2018-09-23 [E]
ssb rsa4096 2018-09-23 [S]
In the example above,
Once you had verified the key, a good practice is to export back to owner and not back to keyserver. This allows the key owner to update the key on his/her part and allowing him/her to push the key to keyserver on his side.
That's all about certifying key.