CERTMONGER(1)
β¨ getcert β CERTMONGER(1) β¨
okay bestie, welcome to the certmonger manual β this is getcert's page from the General Commands Manual, and it's lowkey iconic π
π NAME π
getcert
πΈ SYNOPSIS πΈ
getcert resubmit [options]
π¦ DESCRIPTION π¦
So basically? It tells certmonger to generate (or regenerate) a signing request, and then submit (or resubmit) that signing request to a CA so the CA can sign it. That's the whole vibe. β¨
π SPECIFYING REQUESTS BY NICKNAME π
-i NAME,--id=NAMEβ resubmit a signing request for the tracking request that has this nickname. Now here's the tea: if you don't pass this option, and a tracking entry already exists that matches the key and certificate storage options you specified, then that entry gets used instead. And if you don't specify it and there's no match? Then you gotta say where the certificate lives β either with a combo of the-dand-noptions, or with the-foption. periodt.
π SPECIFYING REQUESTS BY CERTIFICATE LOCATION π
-d DIR,--dbdir=DIRβ the certificate is chillin' in the NSS database in the directory you name. πΎ-n NAME,--nickname=NAMEβ the certificate in the NSS database named with-dhas this nickname. Only valid with-d, no cap.-t TOKEN,--token=TOKENβ if the NSS database has more than one token available, the certificate is stored in this token. ngl you'll only rarely need to specify this one. Only valid with-d.-f FILE,--certfile=FILEβ the certificate is stored in the named file. simple as that. π
π ENROLLMENT OPTIONS π
-c NAME,--ca=NAMEβ submit the new signing request to the specified CA instead of the one that was previously associated with this certificate. The CA's name should correspond to one listed bygetcert list-cas. slay.-T NAME,--profile=NAMEβ request a certificate using the named profile, template, or certtype, from the specified CA.--ms-template-spec SPECβ include a V2 Certificate Template extension in the signing request. This datum includes an Object Identifier, a major version number (positive integer), and an optional minor version number. The format is:<oid>:<majorVersion>[:<minorVersion>].-X NAME,--issuer=NAMEβ request a certificate using the named issuer from the specified CA.-I NAME,--id=NAMEβ assign the specified nickname to this task, replacing the previous nickname. glow-up for your task's name π
π₯ SIGNING REQUEST OPTIONS π₯
-N NAME,--subject-name=NAMEβ change the subject name to include in the signing request.-u keyUsage,--key-usage=keyUsageβ add anextensionRequestfor the specifiedkeyUsageto the signing request. ThekeyUsagevalue is expected to be one of these names:digitalSignaturenonRepudiationkeyEnciphermentdataEnciphermentkeyAgreementkeyCertSigncRLSignencipherOnlydecipherOnly
-U EKU,--extended-key-usage=EKUβ change theextendedKeyUsagevalue specified in anextendedKeyUsageextension part of theextensionRequestattribute in the signing request. TheEKUvalue is expected to be an object identifier (OID).-K NAME,--principal=NAMEβ change the Kerberos principal name specified as part of asubjectAltNameextension part of theextensionRequestattribute in the signing request.-E EMAIL,--email=EMAILβ change the email address specified as part of asubjectAltNameextension part of theextensionRequestattribute in the signing request.-D DNSNAME,--dns=DNSNAMEβ change the DNS name specified as part of asubjectAltNameextension part of theextensionRequestattribute in the signing request.-A ADDRESS,--ip-address=ADDRESSβ change the IP address specified as part of asubjectAltNameextension part of theextensionRequestattribute in the signing request.-l FILE,--challenge-password-file=FILEβ add an optionalChallengePasswordvalue, read from the file, to the signing request. AChallengePasswordis often required when the CA is accessed using SCEP.-L PIN,--challenge-password=PINβ add the argument value to the signing request as aChallengePasswordattribute. AChallengePasswordis often required when the CA is accessed using SCEP.
π OTHER OPTIONS π
-B COMMAND,--before-command=COMMANDβ whenever the certificate or the CA's certificates are saved to the specified locations, run the specified command as the client user before saving the certificates.-C COMMAND,--after-command=COMMANDβ whenever the certificate or the CA's certificates are saved to the specified locations, run the specified command as the client user after saving the certificates.-a DIR,--ca-dbdir=DIRβ whenever the certificate is saved to the specified location, if root certificates for the CA are available, save them to the specified NSS database.-F FILE,--ca-file=FILEβ whenever the certificate is saved to the specified location, if root certificates for the CA are available, and when the local copies of the CA's root certificates are updated, save them to the specified file.--for-caβ request a CA certificate.--not-for-caβ request a non-CA certificate (the default).--ca-path-length=LENGTHβ path length for CA certificate. Only valid with--for-ca.-w,--waitβ wait for the certificate to be reissued and saved, or for the attempt to obtain one to fail. patience is a virtue bestie π--wait-timeout=TIMEOUTβ maximum time to wait for the certificate to be issued.-v,--verboseβ be verbose about errors. Normally, the details of an error received from the daemon will be suppressed if the client can make a diagnostic suggestion. (basically: it shuts up when it thinks it knows what's wrong, unless you pass this. π)-o OWNER,--key-owner=OWNERβ after generation, set the owner on the private key file or database toOWNER.-m MODE,--key-perms=MODEβ after generation, set the file permissions on the private key file or database toMODE.-O OWNER,--cert-owner=OWNERβ after generation, set the owner on the certificate file or database toOWNER.-M MODE,--cert-perms=MODEβ after generation, set the file permissions on the certificate file or database toMODE.
π BUGS π
Please file tickets for any that you find at https://fedorahosted.org/certmonger/
(not me asking you to snitch on the bugs, but like, do it, they wanna know π«Ά)
β SEE ALSO β
certmonger(8) getcert(1) getcert-add-ca(1) getcert-add-scep-ca(1) getcert-list-cas(1) getcert-list(1) getcert-modify-ca(1) getcert-refresh-ca(1) getcert-refresh(1) getcert-rekey(1) getcert-remove-ca(1) getcert-request(1) getcert-start-tracking(1) getcert-status(1) getcert-stop-tracking(1) certmonger-certmaster-submit(8) certmonger-dogtag-ipa-renew-agent-submit(8) certmonger-dogtag-submit(8) certmonger-ipa-submit(8) certmonger-local-submit(8) certmonger-scep-submit(8) certmonger_selinux(8)
okay that's the whole page, you ate that reading it π this was the certmonger Manual, dated February 9, 2015 β and that's on periodt, bestie. go forth and resubmit those signing requests, no cap πΈπ¦β¨
π¦ where this page comes from
- alpine 3.24: certmonger-doc 0.79.21-r0 Β· GPL-3.0-or-later
- centos-stream 10: certmonger 0.79.21-1.el10 Β· GPL-3.0-or-later
- centos-stream 9: certmonger 0.79.21-1.el9 Β· GPLv3+
- debian trixie: certmonger 0.79.20-2 Β· GPL-3.0-or-later WITH OpenSSL exception
- fedora 43: certmonger 0.79.20-5.fc43 Β· GPL-3.0-or-later
- fedora 43: certmonger 0.79.21-1.fc43 Β· GPL-3.0-or-later
- fedora 44: certmonger 0.79.21-4.fc44 Β· GPL-3.0-or-later
- opensuse-leap 16.0: certmonger 0.79.19-160000.2.2 Β· GPL-3.0-or-later
- opensuse-leap 16.0: certmonger 0.79.19-160000.2.2 Β· GPL-3.0-or-later
- opensuse-leap 16.0: certmonger 0.79.19-160000.2.2 Β· GPL-3.0-or-later
- opensuse-leap 16.0: certmonger 0.79.19-160000.2.2 Β· GPL-3.0-or-later
- ubuntu noble: certmonger 0.79.19-1build4 Β· GPL-3.0-or-later WITH OpenSSL exception
- ubuntu questing: certmonger 0.79.20-2build1
- ubuntu resolute: certmonger 0.79.21-1 Β· GPL-3.0-or-later WITH OpenSSL exception
- ubuntu stonking: certmonger 0.79.21-1build1 Β· GPL-3.0-or-later WITH OpenSSL exception
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms