certtool(1)

certtool(1) β€” User Commands β€” certtool(1)

okay bestie, grab a lil snack πŸ“ because we're about to get so cozy with a certificate tool. it's certtool from GnuTLS and honestly? it's giving main character energy in the crypto world. let's go πŸ’…


✨ NAME ✨

certtool β€” GnuTLS certificate tool πŸŽ€


✨ SYNOPSIS ✨

certtool [-flags] [-flag [value]] [--option-name[[=| ]value]]

All arguments must be options.

yes bestie, literally every single argument has to be an option. no stray words, no random positional nonsense, she said options only and she meant it πŸ’€


✨ DESCRIPTION ✨

so what does this icon actually do? Tool to parse and generate X.509 certificates, requests and private keys. πŸ¦‹

you can run her interactively (just vibes, answering questions as they come) or non interactively by handing her a template via the template command line option. lowkey the second one is the move for scripts.

she accepts files or supported URIs through the --infile option. and if your URI access needs a PIN? no worries bestie, just hand it over using the environment variables GNUTLS_PIN and GNUTLS_SO_PIN. πŸ”‘


✨ OPTIONS ✨

  • -d num, --debug=num β€” turn on debugging. this one takes an integer number as its argument, and the value of num is constrained to being:

in the range 0 through 9999

it specifies the debug level. crank it up when things get mysterious πŸ”

  • -V, --verbose β€” more verbose output. she'll chat more. πŸ—£οΈ
  • --infile=file β€” input file. πŸ“₯
  • --outfile=str β€” output file. πŸ“€
  • --attime=timestamp β€” do the validation at the timestamp instead of at the system time. ⏰

timestamp is an instance in time encoded as Unix time or in a human readable timestring such as "29 Feb 2004", "2004-02-29". full documentation lives at <https://www.gnu.org/software/coreutils/manual/html_node/Date-input-formats.html> or locally via info '(coreutils) date invocation'. πŸ“†

  • -i, --certificate-info β€” print information on the given certificate. πŸ“œ
  • --pubkey-info β€” print information on a public key. πŸ”‘

when you combine this option with --load-request, --load-pubkey, --load-privkey and --load-certificate, she'll extract the public key of the object in question. sneaky but legal.

  • -s, --generate-self-signed β€” generate a self-signed certificate. she signs her own stuff, iconic πŸ’…
  • -c, --generate-certificate β€” generate a signed certificate. ✍️
  • --generate-proxy β€” generates a proxy certificate. 🧚
  • -u, --update-certificate β€” update a signed certificate. πŸ”„
  • --fingerprint β€” print the fingerprint of the given certificate. πŸ‘†

this is a simple hash of the DER encoding of the certificate. it can be combined with the --hash parameter. however, for identification it is recommended to use the key-id, which depends only on the certificate's key. so like... fingerprint is cute, key-id is correct.

  • --key-id β€” print the key ID of the given certificate. πŸ†”

this is a hash of the public key of the given certificate. it identifies the key uniquely, remains the same on a certificate renewal, and depends only on signed fields of the certificate. stable queen behavior.

  • --certificate-pubkey β€” print certificate's public key.
⚠️ this option is deprecated as a duplicate of --pubkey-info. NOTE: THIS OPTION IS DEPRECATED
  • --v1 β€” generate an X.509 version 1 certificate (with no extensions). minimalist era.
  • --sign-params=str β€” sign a certificate with a specific signature algorithm.

this option can be combined with --generate-certificate, to sign the certificate with a specific signature algorithm variant. the only option supported is 'RSA-PSS', and should be specified when the signer does not have a certificate which is marked for RSA-PSS use only. πŸ”

  • --crq-info β€” print information on the given certificate request. πŸ“„
  • -q, --generate-request β€” generate a PKCS #10 certificate request.
🚨 this option must not appear in combination with any of the following options: infile.

will generate a PKCS #10 certificate request. to specify a private key use --load-privkey. πŸ”‘

  • --no-crq-extensions β€” do not use extensions in certificate requests. πŸ™…β€β™€οΈ
  • --p12-info β€” print information on a PKCS #12 structure. 🎁

this option will dump the contents and print the metadata of the provided PKCS #12 structure.

  • --p12-name=str β€” the PKCS #12 friendly name to use.

the name to be used for the primary certificate and private key in a PKCS #12 file. name her something cute.

  • --to-p12 β€” generate a PKCS #12 structure. ✨

it requires a certificate, a private key and possibly a CA certificate to be specified.

  • --pbmac1 β€” use PBMAC1 in a PKCS #12 structure. πŸ”
  • -k, --key-info β€” print information on a private key. πŸ”
  • --p8-info β€” print information on a PKCS #8 structure.

this option will print information about encrypted PKCS #8 structures. that option does not require the decryption of the structure. so you get the tea without unlocking the vault, love that for us.

  • --to-rsa β€” convert an RSA-PSS key to raw RSA format.

it requires an RSA-PSS key as input and will output a raw RSA key. this command is necessary for compatibility with applications that cannot read RSA-PSS keys. glow-down for accessibility.

  • -p, --generate-privkey β€” generate a private key. πŸ—οΈ

when generating RSA-PSS or RSA-OAEP private keys, the --hash option will restrict the allowed hash for the key; for RSA-PSS keys the --salt-size option is also acceptable.

  • --key-type=str β€” specify the key type to use on key generation.

this option can be combined with --generate-privkey, to specify the key type to be generated. valid options are, 'rsa', 'rsa-pss', 'rsa-oaep', 'dsa', 'ecdsa', 'ed25519, 'ed448', 'x25519', and 'x448'.'. when combined with certificate generation it can be used to specify an RSA-PSS certificate when an RSA key is given.

  • --key-format=str β€” specify the key format to use on key generation.

this option can be combined with --generate-privkey, to specify the key format to be generated, when the key type is ML-DSA. valid options are, 'seed', 'expanded', and 'both'.

  • --bits=num β€” specify the number of bits for key generation. this option takes an integer number as its argument. πŸ“
  • --curve=str β€” specify the curve used for EC key generation.

supported values are secp192r1, secp224r1, secp256r1, secp384r1 and secp521r1. 🌈

  • --sec-param=security parameter β€” specify the security level [low, legacy, medium, high, ultra].

this is alternative to the bits option.

  • --to-p8 β€” convert a given key to a PKCS #8 structure.

this needs to be combined with --load-privkey. πŸ”—

  • -8, --pkcs8 β€” use PKCS #8 format for private keys. 8️⃣
  • --provable β€” generate a private key or parameters from a seed using a provable method.

this will use the FIPS PUB186-4 algorithms (i.e., Shawe-Taylor) for provable key generation. when specified the private keys or parameters will be generated from a seed, and can be later validated with --verify-provable-privkey to be correctly generated from the seed. you may specify --seed or allow GnuTLS to generate one (recommended). this option can be combined with --generate-privkey or --generate-dh-params.

that option applies to RSA and DSA keys. on the DSA keys the PQG parameters are generated using the seed, and on RSA the two primes. 🌱

  • --verify-provable-privkey β€” verify a private key generated from a seed using a provable method.

this will use the FIPS-186-4 algorithms for provable key generation. you may specify --seed or use the seed stored in the private key structure. βœ…

  • --seed=str β€” when generating a private key use the given hex-encoded seed.

the seed acts as a security parameter for the private key, and thus a seed size which corresponds to the security level of the private key should be provided (e.g., 256-bits seed). 🌰

  • -l, --crl-info β€” print information on the given CRL structure. 🚫
  • --generate-crl β€” generate a CRL.

this option generates a Certificate Revocation List. when combined with --load-crl it would use the loaded CRL as base for the generated (i.e., all revoked certificates in the base will be copied to the new CRL). to add new certificates to the CRL use --load-certificate. πŸ“‹

  • --verify-crl β€” verify a Certificate Revocation List using a trusted list.
🚨 this option must appear in combination with the following options: load-ca-certificate.

the trusted certificate list must be loaded with --load-ca-certificate. πŸ”

  • -e, --verify-chain β€” verify a PEM encoded certificate chain.

verifies the validity of a certificate chain. that is, an ordered set of certificates where each one is the issuer of the previous, and the first is the end-certificate to be validated. in a proper chain the last certificate is a self signed one. it can be combined with --verify-purpose or --verify-hostname. ⛓️

  • --verify β€” verify a PEM encoded certificate (chain) against a trusted set.

the trusted certificate list can be loaded with --load-ca-certificate. if no certificate list is provided, then the system's trusted certificate list is used. note that during verification multiple paths may be explored. on a successful verification the successful path will be the last one. it can be combined with --verify-purpose or --verify-hostname. πŸ•΅οΈβ€β™€οΈ

  • --verify-hostname=str β€” specify a hostname to be used for certificate chain verification.

this is to be combined with one of the verify certificate options. 🏠

  • --verify-email=str β€” specify a email to be used for certificate chain verification.
🚨 this option must not appear in combination with any of the following options: verify-hostname.

this is to be combined with one of the verify certificate options. πŸ“§

  • --verify-purpose=str β€” specify a purpose OID to be used for certificate chain verification.

this object identifier restricts the purpose of the certificates to be verified. example purposes are 1.3.6.1.5.5.7.3.1 (TLS WWW), 1.3.6.1.5.5.7.3.4 (EMAIL) etc. note that a CA certificate without a purpose set (extended key usage) is valid for any purpose. 🎯

  • --verify-allow-broken β€” allow broken algorithms, such as MD5 for verification. πŸ’€

this can be combined with --p7-verify, --verify or --verify-chain.

  • --verify-profile=str β€” specify a security level profile to be used for verification.

this option can be used to specify a certificate verification profile. Certificate verification profiles correspond to the security level. this should be one of 'none', 'very weak', 'low', 'legacy', 'medium', 'high', 'ultra', 'future'. note that by default no profile is applied, unless one is set as minimum in the gnutls configuration file. πŸ“Š

🌸 PKCS#7 structure options 🌸

  • --p7-generate β€” generate a PKCS #7 structure.

this option generates a PKCS #7 certificate container structure. to add certificates in the structure use --load-certificate and --load-crl. πŸ“¦

  • --p7-sign β€” signs using a PKCS #7 structure.

this option generates a PKCS #7 structure containing a signature for the provided data from infile. the data are stored within the structure. the signer certificate has to be specified using --load-certificate and --load-privkey. the input to --load-certificate can be a list of certificates. in case of a list, the first certificate is used for signing and the other certificates are included in the structure. ✍️

  • --p7-detached-sign β€” signs using a detached PKCS #7 structure. πŸ–ŠοΈ
  • --p7-sign β€” bestie, this one is so the signature flex πŸ’… it builds a PKCS #7 structure holding a signature for the data you fed in through infile. The signer cert has to be handed over with --load-certificate and --load-privkey. And here's the cute part: what you give --load-certificate can totally be a list of certificates β€” when it is, the first certificate does the signing and all the other ones just get tucked into the structure like little plus-ones. πŸŽ€
  • --p7-include-cert, --no-p7-include-cert β€” the signer's certificate gets included in the cert list. The no-p7-include-cert form turns the whole thing off. This option is enabled by default.

This option works with --p7-sign or --p7-detached-sign, and it'll either include or exclude the signer's certificate into the generated signature. ✨

  • --p7-time, --no-p7-time β€” will include a timestamp in the PKCS #7 structure. The no-p7-time form turns it off.

So yeah, this option will include a timestamp in the generated signature. ⏰

  • --p7-show-data, --no-p7-show-data β€” will show the embedded data in the PKCS #7 structure. The no-p7-show-data form turns it off.

You can pair this one with --p7-verify or --p7-info and it'll display the embedded signed data inside the PKCS #7 structure. πŸ‘€

  • --p7-info β€” print information on a PKCS #7 structure.
  • --p7-verify β€” verify the provided PKCS #7 structure.

This option verifies the signed PKCS #7 structure, fr fr. The certificate list used for verification can be specified with --load-ca-certificate. When no certificate list is provided, then the system's certificate list is used. Alternatively a direct signer can be provided using --load-certificate. A key purpose can be enforced with the --verify-purpose option, and the --load-data option will utilize detached data. πŸ¦‹

  • --smime-to-p7 β€” convert S/MIME to PKCS #7 structure.

✨ Other options ✨

  • --generate-dh-params β€” generate PKCS #3 encoded Diffie-Hellman parameters.

This will generate random parameters to be used with Diffie-Hellman key exchange. The output parameters will be in PKCS #3 format. Note that it is recommended to use the --get-dh-params option instead. 🌸

NOTE: THIS OPTION IS DEPRECATED πŸ’€
  • --get-dh-params β€” list the included PKCS #3 encoded Diffie-Hellman parameters.

Returns stored DH parameters in GnuTLS. Those parameters returned are defined in RFC7919, and can be considered standard parameters for a TLS key exchange. This option is provided for old applications which require DH parameters to be specified; modern GnuTLS applications should not require them. πŸ‘‘

  • --dh-info β€” print information on PKCS #3 encoded Diffie-Hellman parameters.
  • *--load-privkey=str* β€” loads a private key file.

This can be either a file or a PKCS #11 URL. πŸ”‘

  • *--load-pubkey=str* β€” loads a public key file.

This can be either a file or a PKCS #11 URL. πŸ”‘

  • *--load-request=str* β€” loads a certificate request file.

This option can be used with a file. πŸ“„

  • *--load-certificate=str* β€” loads a certificate file.

This option can be used with a file. πŸ“„

  • *--load-ca-privkey=str* β€” loads the certificate authority's private key file.

This can be either a file or a PKCS #11 URL. πŸ”‘

  • *--load-ca-certificate=str* β€” loads the certificate authority's certificate file.

This can be either a file or a PKCS #11 URL. πŸ”‘

  • *--load-crl=str* β€” loads the provided CRL.

This option can be used with a file. πŸ“„

  • *--load-data=str* β€” loads auxiliary data.

This option can be used with a file. πŸ“„

  • *--password=str* β€” password to use.

You can use this option to specify the password right there in the command line instead of reading it from the tty. But bestie, note that the command line arguments are available for view in others in the system β€” everybody can see your lil secret, so be careful. πŸ™ˆ Specifying password as '' is the same as specifying no password.

  • --null-password β€” enforce a NULL password.

This option enforces a NULL password. This is different than the empty or no password in schemas like PKCS #8.

  • --empty-password β€” enforce an empty password.

This option enforces an empty password. This is different than the NULL or no password in schemas like PKCS #8.

  • --hex-numbers β€” print big number in an easier format to parse.
  • --cprint β€” in certain operations it prints the information in C-friendly format.

In certain operations it prints the information in C-friendly format, suitable for including into C programs. πŸ’œ

  • --rsa β€” generate RSA key.

When combined with --generate-privkey it generates an RSA private key.

NOTE: THIS OPTION IS DEPRECATED πŸ’€
  • --dsa β€” generate DSA key.

When combined with --generate-privkey it generates a DSA private key.

NOTE: THIS OPTION IS DEPRECATED πŸ’€
  • --ecc β€” generate ECC (ECDSA) key.

When combined with --generate-privkey it generates an elliptic curve private key to be used with ECDSA.

NOTE: THIS OPTION IS DEPRECATED πŸ’€
  • --ecdsa β€” this is an alias for the --ecc option.
NOTE: THIS OPTION IS DEPRECATED πŸ’€
  • *--hash=str* β€” hash algorithm to use for signing.

Available hash functions are SHA1, RMD160, SHA256, SHA384, SHA512, SHA3-224, SHA3-256, SHA3-384, SHA3-512. 🌈

  • *--salt-size=num* β€” specify the RSA-PSS key default salt size. This option takes an integer number as its argument.

Typical keys shouldn't set or restrict this option.

  • *--label=str* β€” specify the RSA-OAEP label, encoded in hexadecimal.

Typical keys shouldn't set or restrict this option.

  • --inder, --no-inder β€” use DER format for input certificates, private keys, and DH parameters. The no-inder form turns it off.

The input files will be assumed to be in DER or RAW format. Unlike options that in PEM input would allow multiple input data (e.g. multiple certificates), when reading in DER format a single data structure is read. ⚠️

  • --inraw β€” this is an alias for the --inder option.
  • --outder, --no-outder β€” use DER format for output certificates, private keys, and DH parameters. The no-outder form turns it off.

The output will be in DER or RAW format.

  • --outraw β€” this is an alias for the --outder option.
  • --disable-quick-random β€” no effect.
NOTE: THIS OPTION IS DEPRECATED πŸ’€
  • *--template=str* β€” template file to use for non-interactive operation.
  • --stdout-info β€” print information to stdout instead of stderr.
  • --ask-pass β€” enable interaction for entering password when in batch mode.

This option will enable interaction to enter password when in batch mode. That is useful when the template option has been specified. 🫢

  • *--pkcs-cipher=cipher* β€” cipher to use for PKCS #8 and #12 operations.

Cipher may be one of 3des, 3des-pkcs12, aes-128, aes-192, aes-256, rc2-40, arcfour.

  • *--provider=str* β€” specify the PKCS #11 provider library.

This will override the default options in /etc/gnutls/pkcs11.conf. 🧚

  • --text, --no-text β€” output textual information before PEM-encoded certificates, private keys, etc. The no-text form turns it off. This option is enabled by default.

Output textual information before PEM-encoded data. ✨

  • -v arg, --version=arg β€” output version of program and exit. The default mode is v, a simple version. The c mode will print copyright information and n will print the full copyright notice.
  • -h, --help β€” display usage information and exit.
  • -!, --more-help β€” pass the extended usage information through a pager.

🌸 FILES 🌸

πŸ’– Certtool's template file format πŸ’–

A template file can be used to avoid the interactive questions of certtool. Initially create a file named cert.cfg that contains the information about the certificate. The template can be used as below:

$ certtool --generate-certificate --load-privkey key.pem     --template cert.cfg --outfile cert.pem    --load-ca-certificate ca-cert.pem --load-ca-privkey ca-key.pem

An example certtool template file that can be used to generate a certificate request or a self signed certificate follows.

# X.509 Certificate options
#
# DN options

# The organization of the subject.
organization = "Koko inc."

# The organizational unit of the subject.
unit = "sleeping dept."

# The locality of the subject.
# locality =

# The state of the certificate owner.
state = "Attiki"

# The country of the subject. Two letter code.
country = GR

# The common name of the certificate owner.
cn = "Cindy Lauper"

# A user id of the certificate owner.
#uid = "clauper"

# Set domain components
#dc = "name"
#dc = "domain"

# If the supported DN OIDs are not adequate you can set
# any OID here.
# For example set the X.520 Title and the X.520 Pseudonym
# by using OID and string pairs.
#dn_oid = "2.5.4.12 Dr."
#dn_oid = "2.5.4.65 jackal"

# This is deprecated and should not be used in new
# certificates.
# pkcs9_email = "none@none.org"

# An alternative way to set the certificate's distinguished name directly
# is with the "dn" option. The attribute names allowed are:
# C (country), street, O (organization), OU (unit), title, CN (common name),
# L (locality), ST (state), placeOfBirth, gender, countryOfCitizenship,
# countryOfResidence, serialNumber, telephoneNumber, surName, initials,
# generationQualifier, givenName, pseudonym, dnQualifier, postalCode, name,
# businessCategory, DC, UID, jurisdictionOfIncorporationLocalityName,
# jurisdictionOfIncorporationStateOrProvinceName,
# jurisdictionOfIncorporationCountryName, XmppAddr, and numeric OIDs.

#dn = "cn = Nikos,st = New Something,C=GR,surName=Mavrogiannopoulos,2.5.4.9=Arkadias"

# The serial number of the certificate
# The value is in decimal (i.e. 1963) or hex (i.e. 0x07ab).
# Comment the field for a random serial number.
serial = 007

# In how many days, counting from today, this certificate will expire.
# Use -1 if there is no expiration date.
expiration_days = 700

# Alternatively you may set concrete dates and time. The GNU date string
# formats are accepted. See:
# https://www.gnu.org/software/tar/manual/html_node/Date-input-formats.html

#activation_date = "2004-02-29 16:21:42"
#expiration_date = "2025-02-29 16:24:41"

# X.509 v3 extensions

# A dnsname in case of a WWW server.
#dns_name = "www.none.org"
#dns_name = "www.morethanone.org"

An othername defined by an OID and a hex encoded string

#other_name = "1.3.6.1.5.2.2 302ca00d1b0b56414e5245494e2e4f5247a11b3019a006020400000002a10f300d1b047269636b1b0561646d696e" #other_name_utf8 = "1.2.4.5.6 A UTF8 string" #other_name_octet = "1.2.4.5.6 A string that will be encoded as ASN.1 octet string"

# Allows writing an XmppAddr Identifier #xmpp_name = juliet@im.example.com

# Names used in PKINIT #krb5_principal = user@REALM.COM #krb5_principal = HTTP/user@REALM.COM

# A subject alternative name URI #uri = "https://www.example.com"

# An IP address in case of a server. #ip_address = "192.168.1.1"

# An email in case of a person email = "none@none.org"

# TLS feature (rfc7633) extension. That can is used to indicate mandatory TLS # extension features to be provided by the server. In practice this is used # to require the Status Request (extid: 5) extension from the server. That is, # to require the server holding this certificate to provide a stapled OCSP response. # You can have multiple lines for multiple TLS features.

# To ask for OCSP status request use: #tls_feature = 5

# Challenge password used in certificate requests challenge_password = 123456

# Password when encrypting a private key #password = secret

# An URL that has CRLs (certificate revocation lists) # available. Needed in CA certificates. #crl_dist_points = "https://www.getcrl.crl/getcrl/"

# Whether this is a CA certificate or not #ca

# Subject Unique ID (in hex) #subject_unique_id = 00153224

# Issuer Unique ID (in hex) #issuer_unique_id = 00153225

#### Key usage

# The following key usage flags are used by CAs and end certificates

# Whether this certificate will be used to sign data (needed # in TLS DHE ciphersuites). This is the digitalSignature flag # in RFC5280 terminology. signing_key

# Whether this certificate will be used to encrypt data (needed # in TLS RSA ciphersuites). Note that it is preferred to use different # keys for encryption and signing. This is the keyEncipherment flag # in RFC5280 terminology. encryption_key

# Whether this key will be used to sign other certificates. The # keyCertSign flag in RFC5280 terminology. #cert_signing_key

# Whether this key will be used to sign CRLs. The # cRLSign flag in RFC5280 terminology. #crl_signing_key

# The keyAgreement flag of RFC5280. Its purpose is loosely # defined. Not use it unless required by a protocol. #key_agreement

# The dataEncipherment flag of RFC5280. Its purpose is loosely # defined. Not use it unless required by a protocol. #data_encipherment

# The nonRepudiation flag of RFC5280. Its purpose is loosely # defined. Not use it unless required by a protocol. #non_repudiation

#### Extended key usage (key purposes)

# The following extensions are used in an end certificate # to clarify its purpose. Some CAs also use it to indicate # the types of certificates they are purposed to sign.

# Whether this certificate will be used for a TLS client; # this sets the id-kp-clientAuth (1.3.6.1.5.5.7.3.2) of # extended key usage. #tls_www_client

# Whether this certificate will be used for a TLS server; # this sets the id-kp-serverAuth (1.3.6.1.5.5.7.3.1) of # extended key usage. #tls_www_server

# Whether this key will be used to sign code. This sets the # id-kp-codeSigning (1.3.6.1.5.5.7.3.3) of extended key usage # extension. #code_signing_key

# Whether this key will be used to sign OCSP data. This sets the # id-kp-OCSPSigning (1.3.6.1.5.5.7.3.9) of extended key usage extension. #ocsp_signing_key

# Whether this key will be used for time stamping. This sets the # id-kp-timeStamping (1.3.6.1.5.5.7.3.8) of extended key usage extension. #time_stamping_key

# Whether this key will be used for email protection. This sets the # id-kp-emailProtection (1.3.6.1.5.5.7.3.4) of extended key usage extension. #email_protection_key

# Whether this key will be used for IPsec IKE operations (1.3.6.1.5.5.7.3.17). #ipsec_ike_key

## adding custom key purpose OIDs

# for microsoft smart card logon # key_purpose_oid = 1.3.6.1.4.1.311.20.2.2

# for email protection # key_purpose_oid = 1.3.6.1.5.5.7.3.4

# for any purpose (must not be used in intermediate CA certificates) # key_purpose_oid = 2.5.29.37.0

### end of key purpose OIDs

### Adding arbitrary extensions # This requires to provide the extension OIDs, as well as the extension data in # hex format. The following two options are available since GnuTLS 3.5.3. #add_extension = "1.2.3.4 0x0AAB01ACFE"

# As above but encode the data as an octet string #add_extension = "1.2.3.4 octet_string(0x0AAB01ACFE)"

# For portability critical extensions shouldn't be set to certificates. #add_critical_extension = "5.6.7.8 0x1AAB01ACFE"

# When generating a certificate from a certificate # request, then honor the extensions stored in the request # and store them in the real certificate. #honor_crq_extensions

# Alternatively only specific extensions can be copied. #honor_crq_ext = 2.5.29.17 #honor_crq_ext = 2.5.29.15

# Path length constraint. Sets the maximum number of # certificates that can be used to certify this certificate. # (i.e. the certificate chain length) #path_len = -1 #path_len = 2

# OCSP URI # ocsp_uri = https://my.ocsp.server/ocsp

# CA issuers URI # ca_issuers_uri = https://my.ca.issuer

# Certificate policies #policy1 = 1.3.6.1.4.1.5484.1.10.99.1.0 #policy1_txt = "This is a long policy to summarize" #policy1_url = https://www.example.com/a-policy-to-read

#policy2 = 1.3.6.1.4.1.5484.1.10.99.1.1 #policy2_txt = "This is a short policy" #policy2_url = https://www.example.com/another-policy-to-read

# The number of additional certificates that may appear in a # path before the anyPolicy is no longer acceptable. #inhibit_anypolicy_skip_certs 1

# Name constraints

# DNS #nc_permit_dns = example.com #nc_exclude_dns = test.example.com

# EMAIL #nc_permit_email = "nmav@ex.net"

# Exclude subdomains of example.com #nc_exclude_email = .example.com

# Exclude all e-mail addresses of example.com #nc_exclude_email = example.com

# IP #nc_permit_ip = 192.168.0.0/16 #nc_exclude_ip = 192.168.5.0/24 #nc_permit_ip = fc0a:eef2:e7e7:a56e::/64

# Options for proxy certificates #proxy_policy_language = 1.3.6.1.5.5.7.21.1

# Options for generating a CRL

# The number of days the next CRL update will be due. # next CRL update will be in 43 days #crl_next_update = 43

# this is the 5th CRL by this CA # The value is in decimal (i.e. 1963) or hex (i.e. 0x07ab). # Comment the field for a time-based number. # Time-based CRL numbers generated in GnuTLS 3.6.3 and later # are significantly larger than those generated in previous # versions. Since CRL numbers need to be monotonic, you need # to specify the CRL number here manually if you intend to # downgrade to an earlier version than 3.6.3 after publishing # the CRL as it is not possible to specify CRL numbers greater # than 2**63-2 using hex notation in those versions. #crl_number = 5

# Specify the update dates more precisely. #crl_this_update_date = "2004-02-29 16:21:42" #crl_next_update_date = "2025-02-29 16:24:41"

# The date that the certificates will be made seen as # being revoked. #crl_revocation_date = "2025-02-29 16:24:41"

πŸ’– EXAMPLES πŸ’–

okay bestie this is the part where it all comes together, like the montage scene in a movie except it's cryptography 🎬✨

πŸ”‘ Generating private keys

wanna make an RSA private key? run:

$ certtool --generate-privkey --outfile key.pem --rsa

and if you want a DSA key or an elliptic curves (ECDSA) key instead, it's literally the same command, you just swap in dsa or ecc instead. mix and match, it's giving choose-your-own-adventure 🌈


πŸ“ Generating certificate requests

so a certificate request (you need one of these when the certificate is issued by another party, like when you're not the one signing it) goes like this:

certtool --generate-request --load-privkey key.pem    --outfile request.pem

and if your private key lives on a smart card?? you can still make a request, you just point at the private key object URL instead:

$ ./certtool --generate-request --load-privkey "pkcs11:..."   --load-pubkey "pkcs11:..." --outfile request.pem

smart card girlies stay winning πŸ’…


πŸ‘‘ Generating a self-signed certificate

self-signed certificate time, here's the command:

$ certtool --generate-privkey --outfile ca-key.pem
$ certtool --generate-self-signed --load-privkey ca-key.pem    --outfile ca-cert.pem
lowkey important note: a self-signed certificate usually belongs to a certificate authority, aka the thing that signs other certificates. so like. it's the parent, not the child. main character energy, honestly.

πŸŽ€ Generating a certificate

to generate a certificate using the request you made earlier:

$ certtool --generate-certificate --load-request request.pem    --outfile cert.pem --load-ca-certificate ca-cert.pem    --load-ca-privkey ca-key.pem

and to generate a certificate using the private key only, no request needed:

$ certtool --generate-certificate --load-privkey key.pem    --outfile cert.pem --load-ca-certificate ca-cert.pem    --load-ca-privkey ca-key.pem

both are valid, pick whichever one matches your vibe 🫢


πŸ” Certificate information

want to see what's inside a certificate? nosy bestie behavior, we love it:

$ certtool --certificate-info --infile cert.pem

πŸ”„ Changing the certificate format

turning a certificate from PEM into DER format:

$ certtool --certificate-info --infile cert.pem --outder --outfile cert.der

πŸ“ PKCS #12 structure generation

to make a PKCS #12 structure out of that key and certificate from before:

$ certtool --load-certificate cert.pem --load-privkey key.pem    --to-p12 --outder --outfile key.p12
πŸ’€ okay so some tools (reportedly web browsers, so. the usual suspects) have problems with that file, because it does not contain the CA certificate for the certificate. rude of them honestly. the workaround in the tool is to use the --load-ca-certificate parameter like this:
$ certtool --load-ca-certificate ca.pem   --load-certificate cert.pem --load-privkey key.pem   --to-p12 --outder --outfile key.p12

problem solved, slay ✨


🌸 Obtaining Diffie-Hellman parameters

to get the RFC7919 parameters for Diffie-Hellman key exchange:

$ certtool --get-dh-params --outfile dh.pem --sec-param medium

βœ… Verifying a certificate

to verify a certificate in a file against the system's CA trust store:

$ certtool --verify --infile cert.pem

and yes you can also simulate hostname verification, with these options:

$ certtool --verify --verify-hostname www.example.com --infile cert.pem

vibe check: passed 🌈


🧚 Proxy certificate generation

so a proxy certificate is how you delegate your credential to a temporary certificate β€” typically a short-lived one. to create one from the certificate you already made, first make a temporary key, then generate a proxy certificate for it, like:

$ certtool --generate-privkey > proxy-key.pem
$ certtool --generate-proxy --load-ca-privkey key.pem   --load-privkey proxy-key.pem --load-certificate cert.pem   --outfile proxy-cert.pem

delegating but make it ✨elegant✨


🚫 Certificate revocation list generation

to create an empty Certificate Revocation List (CRL), do:

$ certtool --generate-crl --load-ca-privkey x509-ca-key.pem            --load-ca-certificate x509-ca.pem

and to create a CRL that actually contains some revoked certificates, you put those certificates in a file and use --load-certificate like so:

$ certtool --generate-crl --load-ca-privkey x509-ca-key.pem   --load-ca-certificate x509-ca.pem --load-certificate revoked-certs.pem

to verify a Certificate Revocation List (CRL), do:

$ certtool --verify-crl --load-ca-certificate x509-ca.pem < crl.pem

πŸšͺ EXIT STATUS πŸšͺ

one of the following exit values will be returned, and bestie you will be checking these:

  • 0 β€” (EXIT_SUCCESS) Successful program execution. it ate and left no crumbs πŸŽ‰
  • 1 β€” (EXIT_FAILURE) The operation failed or the command syntax was not valid. 😭 it's giving typo, check ur flags

πŸ‘€ SEE ALSO πŸ‘€

  • p11tool (1)
  • psktool (1)
  • srptool (1)

go read those too, they're the rest of the friend group πŸ’œ


✍️ AUTHORS ✍️


Copyright (C) 2020-2023 Free Software Foundation, and others all rights reserved. This program is released under the terms of the GNU General Public License, version 3 or later

legal bestie moment, but fr read the license, it's important πŸ’…

πŸ› BUGS πŸ›

found something cursed? please send bug reports to: bugs@gnutls.org β€” they actually want to hear about it, no gatekeeping 🫢


and that's a wrap on certtool(1), bestie!! this whole page is from version 3.8.13, dated 29 Apr 2026 🌸 go forth and generate keys responsibly, you've got this, mwah πŸ’–βœ¨πŸŽ€