GnuTLS ¶

3.3.1 Encryption algorithms used in the record layer ¶

Confidentiality in the record layer is achieved by using symmetric ciphers like AES or CHACHA20. Ciphers are encryption algorithms that use a single, secret, key to encrypt and decrypt data. Early versions of TLS separated between block and stream ciphers and had message authentication plugged in to them by the protocol, though later versions switched to using authenticated-encryption (AEAD) ciphers. The AEAD ciphers are defined to combine encryption and authentication, and as such they are not only more efficient, as the primitives used are designed to interoperate nicely, but they are also known to interoperate in a secure way.

The supported in GnuTLS ciphers and MAC algorithms are shown in Table 3.1 and Table 3.2.

3.3.2 Compression algorithms and the record layer ¶

In early versions of TLS the record layer supported compression. However, that proved to be problematic in many ways, and enabled several attacks based on traffic analysis on the transported data. For that newer versions of the protocol no longer offer compression, and GnuTLS since 3.6.0 no longer implements any support for compression.

3.3.3 On record padding ¶

The TLS 1.3 protocol allows for extra padding of records to prevent statistical analysis based on the length of exchanged messages. GnuTLS takes advantage of this feature, by allowing the user to specify the amount of padding for a particular message. The simplest interface is provided by gnutls_record_send2, and is made available when under TLS1.3; alternatively gnutls_record_can_use_length_hiding can be queried.

Note that this interface is not sufficient to completely hide the length of the data. The application code may reveal the data transferred by leaking its data processing time, or by leaking the TLS1.3 record processing time by GnuTLS. That is because under TLS1.3 the padding removal time depends on the padding data for an efficient implementation. To make that processing constant time the gnutls_init function must be called with the flag GNUTLS_SAFE_PADDING_CHECK.

Function: ssize_t gnutls_record_send2 (gnutls_session_t session, const void * data, size_t data_size, size_t pad, unsigned flags) ¶

session: is a gnutls_session_t type.

data: contains the data to send

data_size: is the length of the data

pad: padding to be added to the record

flags: must be zero

This function is identical to gnutls_record_send() except that it takes an extra argument to specify padding to be added the record. To determine the maximum size of padding, use gnutls_record_get_max_size() and gnutls_record_overhead_size() .

Note that in order for GnuTLS to provide constant time processing of padding and data in TLS1.3, the flag GNUTLS_SAFE_PADDING_CHECK must be used in gnutls_init() .

Returns: The number of bytes sent, or a negative error code. The number of bytes sent might be less than data_size . The maximum number of bytes this function can send in a single call depends on the negotiated maximum record size.

Since: 3.6.3

Older GnuTLS versions provided an API suitable for cases where the sender sends data that are always within a given range. That API is still available, and consists of the following functions.

unsigned gnutls_record_can_use_length_hiding (gnutls_session_t session)

ssize_t gnutls_record_send_range (gnutls_session_t session, const void * data, size_t data_size, const gnutls_range_st * range)

3.5.1 TLS ciphersuites ¶

The TLS cipher suites have slightly different meaning under different protocols. Under TLS 1.3, a cipher suite indicates the symmetric encryption algorithm in use, as well as the pseudo-random function (PRF) used in the TLS session.

Under TLS 1.2 or early the handshake protocol negotiates cipher suites of a special form illustrated by the TLS_DHE_RSA_WITH_3DES_CBC_SHA cipher suite name. A typical cipher suite contains these parameters:

• The key exchange algorithm. DHE_RSA in the example.
• The Symmetric encryption algorithm and mode 3DES_CBC in this example.
• The MAC⁵ algorithm used for authentication. MAC_SHA is used in the above example.

The cipher suite negotiated in the handshake protocol will affect the record protocol, by enabling encryption and data authentication. Note that you should not over rely on TLS to negotiate the strongest available cipher suite. Do not enable ciphers and algorithms that you consider weak.

All the supported ciphersuites are listed in ciphersuites.

3.5.2 Authentication ¶

The key exchange algorithms of the TLS protocol offer authentication, which is a prerequisite for a secure connection. The available authentication methods in GnuTLS, under TLS 1.3 or earlier versions, follow.

• Certificate authentication: Authenticated key exchange using public key infrastructure and X.509 certificates.
• PSK authentication: Authenticated key exchange using a pre-shared key.

Under TLS 1.2 or earlier versions, the following authentication methods are also available.

• SRP authentication: Authenticated key exchange using a password.
• Anonymous authentication: Key exchange without peer authentication.

3.5.3 Client authentication ¶

In the case of ciphersuites that use certificate authentication, the authentication of the client is optional in TLS. A server may request a certificate from the client using the gnutls_certificate_server_set_request function. We elaborate in Certificates.

3.5.4 Resuming sessions ¶

The TLS handshake process performs expensive calculations and a busy server might easily be put under load. To reduce the load, session resumption may be used. This is a feature of the TLS protocol which allows a client to connect to a server after a successful handshake, without the expensive calculations. This is achieved by re-using the previously established keys, meaning the server needs to store the state of established connections (unless session tickets are used – Session tickets).

Session resumption is an integral part of GnuTLS, and Session resumption, ex-resume-client illustrate typical uses of it.

3.6.1 Maximum fragment length negotiation ¶

This extension allows a TLS implementation to negotiate a smaller value for record packet maximum length. This extension may be useful to clients with constrained capabilities. The functions shown below can be used to control this extension.

size_t gnutls_record_get_max_size (gnutls_session_t session)

ssize_t gnutls_record_set_max_size (gnutls_session_t session, size_t size)

3.6.2 Server name indication ¶

A common problem in HTTPS servers is the fact that the TLS protocol is not aware of the hostname that a client connects to, when the handshake procedure begins. For that reason the TLS server has no way to know which certificate to send.

This extension solves that problem within the TLS protocol, and allows a client to send the HTTP hostname before the handshake begins within the first handshake packet. The functions gnutls_server_name_set and gnutls_server_name_get can be used to enable this extension, or to retrieve the name sent by a client.

int gnutls_server_name_set (gnutls_session_t session, gnutls_server_name_type_t type, const void * name, size_t name_length)

int gnutls_server_name_get (gnutls_session_t session, void * data, size_t * data_length, unsigned int * type, unsigned int indx)

3.6.3 Session tickets ¶

To resume a TLS session, the server normally stores session parameters. This complicates deployment, and can be avoided by delegating the storage to the client. Because session parameters are sensitive they are encrypted and authenticated with a key only known to the server and then sent to the client. The Session Tickets extension is described in RFC 5077 [TLSTKT].

A disadvantage of session tickets is that they eliminate the effects of forward secrecy when a server uses the same key for long time. That is, the secrecy of all sessions on a server using tickets depends on the ticket key being kept secret. For that reason server keys should be rotated and discarded regularly.

Since version 3.1.3 GnuTLS clients transparently support session tickets, unless forward secrecy is explicitly requested (with the PFS priority string).

Under TLS 1.3 session tickets are mandatory for session resumption, and they do not share the forward secrecy concerns as with TLS 1.2 or earlier.

3.6.4 HeartBeat ¶

This is a TLS extension that allows to ping and receive confirmation from the peer, and is described in [RFC6520]. The extension is disabled by default and gnutls_heartbeat_enable can be used to enable it. A policy may be negotiated to only allow sending heartbeat messages or sending and receiving. The current session policy can be checked with gnutls_heartbeat_allowed. The requests coming from the peer result to GNUTLS_E_HEARTBEAT_PING_RECEIVED being returned from the receive function. Ping requests to peer can be send via gnutls_heartbeat_ping.

unsigned gnutls_heartbeat_allowed (gnutls_session_t session, unsigned int type)

void gnutls_heartbeat_enable (gnutls_session_t session, unsigned int type)

int gnutls_heartbeat_ping (gnutls_session_t session, size_t data_size, unsigned int max_tries, unsigned int flags)

int gnutls_heartbeat_pong (gnutls_session_t session, unsigned int flags)

void gnutls_heartbeat_set_timeouts (gnutls_session_t session, unsigned int retrans_timeout, unsigned int total_timeout)

unsigned int gnutls_heartbeat_get_timeout (gnutls_session_t session)

3.6.5 Safe renegotiation ¶

TLS gives the option to two communicating parties to renegotiate and update their security parameters. One useful example of this feature was for a client to initially connect using anonymous negotiation to a server, and the renegotiate using some authenticated ciphersuite. This occurred to avoid having the client sending its credentials in the clear.

However this renegotiation, as initially designed would not ensure that the party one is renegotiating is the same as the one in the initial negotiation. For example one server could forward all renegotiation traffic to an other server who will see this traffic as an initial negotiation attempt.

This might be seen as a valid design decision, but it seems it was not widely known or understood, thus today some application protocols use the TLS renegotiation feature in a manner that enables a malicious server to insert content of his choice in the beginning of a TLS session.

The most prominent vulnerability was with HTTPS. There servers request a renegotiation to enforce an anonymous user to use a certificate in order to access certain parts of a web site. The attack works by having the attacker simulate a client and connect to a server, with server-only authentication, and send some data intended to cause harm. The server will then require renegotiation from him in order to perform the request. When the proper client attempts to contact the server, the attacker hijacks that connection and forwards traffic to the initial server that requested renegotiation. The attacker will not be able to read the data exchanged between the client and the server. However, the server will (incorrectly) assume that the initial request sent by the attacker was sent by the now authenticated client. The result is a prefix plain-text injection attack.

The above is just one example. Other vulnerabilities exists that do not rely on the TLS renegotiation to change the client’s authenticated status (either TLS or application layer).

While fixing these application protocols and implementations would be one natural reaction, an extension to TLS has been designed that cryptographically binds together any renegotiated handshakes with the initial negotiation. When the extension is used, the attack is detected and the session can be terminated. The extension is specified in [RFC5746].

GnuTLS supports the safe renegotiation extension. The default behavior is as follows. Clients will attempt to negotiate the safe renegotiation extension when talking to servers. Servers will accept the extension when presented by clients. Clients and servers will permit an initial handshake to complete even when the other side does not support the safe renegotiation extension. Clients and servers will refuse renegotiation attempts when the extension has not been negotiated.

Note that permitting clients to connect to servers when the safe renegotiation extension is not enabled, is open up for attacks. Changing this default behavior would prevent interoperability against the majority of deployed servers out there. We will reconsider this default behavior in the future when more servers have been upgraded. Note that it is easy to configure clients to always require the safe renegotiation extension from servers.

To modify the default behavior, we have introduced some new priority strings (see Priority strings). The %UNSAFE_RENEGOTIATION priority string permits (re-)handshakes even when the safe renegotiation extension was not negotiated. The default behavior is %PARTIAL_RENEGOTIATION that will prevent renegotiation with clients and servers not supporting the extension. This is secure for servers but leaves clients vulnerable to some attacks, but this is a trade-off between security and compatibility with old servers. The %SAFE_RENEGOTIATION priority string makes clients and servers require the extension for every handshake. The latter is the most secure option for clients, at the cost of not being able to connect to legacy servers. Servers will also deny clients that do not support the extension from connecting.

It is possible to disable use of the extension completely, in both clients and servers, by using the %DISABLE_SAFE_RENEGOTIATION priority string however we strongly recommend you to only do this for debugging and test purposes.

The default values if the flags above are not specified are:

Server:

%PARTIAL_RENEGOTIATION

Client:

%PARTIAL_RENEGOTIATION

For applications we have introduced a new API related to safe renegotiation. The gnutls_safe_renegotiation_status function is used to check if the extension has been negotiated on a session, and can be used both by clients and servers.

3.6.6 OCSP status request ¶

The Online Certificate Status Protocol (OCSP) is a protocol that allows the client to verify the server certificate for revocation without messing with certificate revocation lists. Its drawback is that it requires the client to connect to the server’s CA OCSP server and request the status of the certificate. This extension however, enables a TLS server to include its CA OCSP server response in the handshake. That is an HTTPS server may periodically run ocsptool (see Invoking ocsptool) to obtain its certificate revocation status and serve it to the clients. That way a client avoids an additional connection to the OCSP server.

See OCSP stapling for further information.

Since version 3.1.3 GnuTLS clients transparently support the certificate status request.

3.6.7 SRTP ¶

The TLS protocol was extended in [RFC5764] to provide keying material to the Secure RTP (SRTP) protocol. The SRTP protocol provides an encapsulation of encrypted data that is optimized for voice data. With the SRTP TLS extension two peers can negotiate keys using TLS or DTLS and obtain keying material for use with SRTP. The available SRTP profiles are listed below.

To enable use the following functions.

int gnutls_srtp_set_profile (gnutls_session_t session, gnutls_srtp_profile_t profile)

int gnutls_srtp_set_profile_direct (gnutls_session_t session, const char * profiles, const char ** err_pos)

To obtain the negotiated keys use the function below.

Function: int gnutls_srtp_get_keys (gnutls_session_t session, void * key_material, unsigned int key_material_size, gnutls_datum_t * client_key, gnutls_datum_t * client_salt, gnutls_datum_t * server_key, gnutls_datum_t * server_salt) ¶

session: is a gnutls_session_t type.

key_material: Space to hold the generated key material

key_material_size: The maximum size of the key material

client_key: The master client write key, pointing inside the key material

client_salt: The master client write salt, pointing inside the key material

server_key: The master server write key, pointing inside the key material

server_salt: The master server write salt, pointing inside the key material

This is a helper function to generate the keying material for SRTP. It requires the space of the key material to be pre-allocated (should be at least 2x the maximum key size and salt size). The client_key , client_salt , server_key and server_salt are convenience datums that point inside the key material. They may be NULL .

Returns: On success the size of the key material is returned, otherwise, GNUTLS_E_SHORT_MEMORY_BUFFER if the buffer given is not sufficient, or a negative error code.

Since 3.1.4

Other helper functions are listed below.

int gnutls_srtp_get_selected_profile (gnutls_session_t session, gnutls_srtp_profile_t * profile)

const char * gnutls_srtp_get_profile_name (gnutls_srtp_profile_t profile)

int gnutls_srtp_get_profile_id (const char * name, gnutls_srtp_profile_t * profile)

3.6.8 False Start ¶

The TLS protocol was extended in [RFC7918] to allow the client to send data to server in a single round trip. This change however operates on the borderline of the TLS protocol security guarantees and should be used for the cases where the reduced latency outperforms the risk of an adversary intercepting the transferred data. In GnuTLS applications can use the GNUTLS_ENABLE_FALSE_START as option to gnutls_init to request an early return of the gnutls_handshake function. After that early return the application is expected to transfer any data to be piggybacked on the last handshake message.

After handshake’s early termination, the application is expected to transmit data using gnutls_record_send, and call gnutls_record_recv on any received data as soon, to ensure that handshake completes timely. That is, especially relevant for applications which set an explicit time limit for the handshake process via gnutls_handshake_set_timeout.

Note however, that the API ensures that the early return will not happen if the false start requirements are not satisfied. That is, on ciphersuites which are not enabled for false start or on insufficient key sizes, the handshake process will complete properly (i.e., no early return). To verify that false start was used you may use gnutls_session_get_flags and check for the GNUTLS_SFLAGS_FALSE_START flag. For GnuTLS the false start is enabled for the following key exchange methods (see [RFC7918] for rationale)

• DHE
• ECDHE

but only when the negotiated parameters exceed GNUTLS_SEC_PARAM_HIGH –see Table 6.7, and when under (D)TLS 1.2 or later.

3.6.9 Application Layer Protocol Negotiation (ALPN) ¶

The TLS protocol was extended in RFC7301 to provide the application layer a method of negotiating the application protocol version. This allows for negotiation of the application protocol during the TLS handshake, thus reducing round-trips. The application protocol is described by an opaque string. To enable, use the following functions.

int gnutls_alpn_set_protocols (gnutls_session_t session, const gnutls_datum_t * protocols, unsigned protocols_size, unsigned int flags)

int gnutls_alpn_get_selected_protocol (gnutls_session_t session, gnutls_datum_t * protocol)

Note that these functions are intended to be used with protocols that are registered in the Application Layer Protocol Negotiation IANA registry. While you can use them for other protocols (at the risk of collisions), it is preferable to register them.

3.6.10 Extensions and Supplemental Data ¶

It is possible to transfer supplemental data during the TLS handshake, following [RFC4680]. This is for "custom" protocol modifications for applications which may want to transfer additional data (e.g. additional authentication messages). Such an exchange requires a custom extension to be registered. The provided API for this functionality is low-level and described in TLS Extension Handling.

3.7.1 Separate ports ¶

Traditionally SSL was used in application protocols by assigning a new port number for the secure services. By doing this two separate ports were assigned, one for the non-secure sessions, and one for the secure sessions. This method ensures that if a user requests a secure session then the client will attempt to connect to the secure port and fail otherwise. The only possible attack with this method is to perform a denial of service attack. The most famous example of this method is “HTTP over TLS” or HTTPS protocol [RFC2818].

Despite its wide use, this method has several issues. This approach starts the TLS Handshake procedure just after the client connects on the —so called— secure port. That way the TLS protocol does not know anything about the client, and popular methods like the host advertising in HTTP do not work⁶. There is no way for the client to say “I connected to YYY server” before the Handshake starts, so the server cannot possibly know which certificate to use.

Other than that it requires two separate ports to run a single service, which is unnecessary complication. Due to the fact that there is a limitation on the available privileged ports, this approach was soon deprecated in favor of upward negotiation.

3.7.2 Upward negotiation ¶

Other application protocols⁷ use a different approach to enable the secure layer. They use something often called as the “TLS upgrade” method. This method is quite tricky but it is more flexible. The idea is to extend the application protocol to have a “STARTTLS” request, whose purpose it to start the TLS protocols just after the client requests it. This approach does not require any extra port to be reserved. There is even an extension to HTTP protocol to support this method [RFC2817].

The tricky part, in this method, is that the “STARTTLS” request is sent in the clear, thus is vulnerable to modifications. A typical attack is to modify the messages in a way that the client is fooled and thinks that the server does not have the “STARTTLS” capability. See a typical conversation of a hypothetical protocol:

(client connects to the server)

CLIENT: HELLO I’M MR. XXX

SERVER: NICE TO MEET YOU XXX

CLIENT: PLEASE START TLS

SERVER: OK

*** TLS STARTS

CLIENT: HERE ARE SOME CONFIDENTIAL DATA

And an example of a conversation where someone is acting in between:

(client connects to the server)

CLIENT: HELLO I’M MR. XXX

SERVER: NICE TO MEET YOU XXX

CLIENT: PLEASE START TLS

(here someone inserts this message)

SERVER: SORRY I DON’T HAVE THIS CAPABILITY

CLIENT: HERE ARE SOME CONFIDENTIAL DATA

As you can see above the client was fooled, and was naïve enough to send the confidential data in the clear, despite the server telling the client that it does not support “STARTTLS”.

How do we avoid the above attack? As you may have already noticed this situation is easy to avoid. The client has to ask the user before it connects whether the user requests TLS or not. If the user answered that he certainly wants the secure layer the last conversation should be:

(client connects to the server)

CLIENT: HELLO I’M MR. XXX

SERVER: NICE TO MEET YOU XXX

CLIENT: PLEASE START TLS

(here someone inserts this message)

SERVER: SORRY I DON’T HAVE THIS CAPABILITY

CLIENT: BYE

(the client notifies the user that the secure connection was not possible)

This method, if implemented properly, is far better than the traditional method, and the security properties remain the same, since only denial of service is possible. The benefit is that the server may request additional data before the TLS Handshake protocol starts, in order to send the correct certificate, use the correct password file, or anything else!

4.1.1 X.509 certificates ¶

The X.509 protocols rely on a hierarchical trust model. In this trust model Certification Authorities (CAs) are used to certify entities. Usually more than one certification authorities exist, and certification authorities may certify other authorities to issue certificates as well, following a hierarchical model.

Figure 4.1: An example of the X.509 hierarchical trust model.

One needs to trust one or more CAs for his secure communications. In that case only the certificates issued by the trusted authorities are acceptable. The framework is illustrated on Figure 4.1.

• X.509 certificate structure
• Importing an X.509 certificate
• X.509 certificate names
• X.509 distinguished names
• X.509 extensions
• Accessing public and private keys
• Verifying X.509 certificate paths
• Verifying a certificate in the context of TLS session
• Verifying a certificate using PKCS #11

4.1.2 OpenPGP certificates ¶

Previous versions of GnuTLS supported limited OpenPGP key authentication. That functionality has been deprecated and is no longer made available. The reason is that, supporting alternative authentication methods, when X.509 and PKIX were new on the Internet and not well established, seemed like a good idea, in today’s Internet X.509 is unquestionably the main container for certificates. As such supporting more options with no clear use-cases, is a distraction that consumes considerable resources for improving and testing the library. For that we have decided to drop this functionality completely in 3.6.0.

4.1.3 Raw public-keys ¶

There are situations in which a rather large certificate / certificate chain is undesirable or impractical. An example could be a resource constrained sensor network in which you do want to use authentication of and encryption between your devices but where your devices lack loads of memory or processing power. Furthermore, there are situations in which you don’t want to or can’t rely on a PKIX. TLS is, next to a PKIX environment, also commonly used with self-signed certificates in smaller deployments where the self-signed certificates are distributed to all involved protocol endpoints out-of-band. This practice does, however, still require the overhead of the certificate generation even though none of the information found in the certificate is actually used.

With raw public-keys, only a subset of the information found in typical certificates is utilized: namely, the SubjectPublicKeyInfo structure (in ASN.1 format) of a PKIX certificate that carries the parameters necessary to describe the public-key. Other parameters found in PKIX certificates are omitted. By omitting various certificate-related structures, the resulting raw public-key is kept fairly small in comparison to the original certificate, and the code to process the keys can be simpler.

It should be noted however, that the authenticity of these raw keys must be verified by an out-of-band mechanism or something like TOFU.

• Importing raw public-keys

4.1.4 Advanced certificate verification ¶

The verification of X.509 certificates in the HTTPS and other Internet protocols is typically done by loading a trusted list of commercial Certificate Authorities (see gnutls_certificate_set_x509_system_trust), and using them as trusted anchors. However, there are several examples (eg. the Diginotar incident) where one of these authorities was compromised. This risk can be mitigated by using in addition to CA certificate verification, other verification methods. In this section we list the available in GnuTLS methods.

• Verifying a certificate using trust on first use authentication
• Verifying a certificate using DANE (DNSSEC)

4.1.5 Digital signatures ¶

In this section we will provide some information about digital signatures, how they work, and give the rationale for disabling some of the algorithms used.

Digital signatures work by using somebody’s secret key to sign some arbitrary data. Then anybody else could use the public key of that person to verify the signature. Since the data may be arbitrary it is not suitable input to a cryptographic digital signature algorithm. For this reason and also for performance cryptographic hash algorithms are used to preprocess the input to the signature algorithm. This works as long as it is difficult enough to generate two different messages with the same hash algorithm output. In that case the same signature could be used as a proof for both messages. Nobody wants to sign an innocent message of donating 1 euro to Greenpeace and find out that they donated 1.000.000 euros to Bad Inc.

For a hash algorithm to be called cryptographic the following three requirements must hold:

1. Preimage resistance. That means the algorithm must be one way and given the output of the hash function H(x), it is impossible to calculate x.
2. 2nd preimage resistance. That means that given a pair x,y with y=H(x) it is impossible to calculate an x' such that y=H(x').
3. Collision resistance. That means that it is impossible to calculate random x and x' such H(x')=H(x).

The last two requirements in the list are the most important in digital signatures. These protect against somebody who would like to generate two messages with the same hash output. When an algorithm is considered broken usually it means that the Collision resistance of the algorithm is less than brute force. Using the birthday paradox the brute force attack takes 2^{((hash size) / 2)} operations. Today colliding certificates using the MD5 hash algorithm have been generated as shown in [WEGER].

There has been cryptographic results for the SHA-1 hash algorithms as well, although they are not yet critical. Before 2004, MD5 had a presumed collision strength of 2^{64}, but it has been showed to have a collision strength well under 2^{50}. As of November 2005, it is believed that SHA-1’s collision strength is around 2^{63}. We consider this sufficiently hard so that we still support SHA-1. We anticipate that SHA-256/386/512 will be used in publicly-distributed certificates in the future. When 2^{63} can be considered too weak compared to the computer power available sometime in the future, SHA-1 will be disabled as well. The collision attacks on SHA-1 may also get better, given the new interest in tools for creating them.

• Trading security for interoperability

  gnutls_certificate_set_verify_flags (x509cred,
                                       GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5);

4.2.1 PKCS #10 certificate requests ¶

A certificate request is a structure, which contain information about an applicant of a certificate service. It typically contains a public key, a distinguished name and secondary data such as a challenge password. GnuTLS supports the requests defined in PKCS #10 [RFC2986]. Other formats of certificate requests are not currently supported by GnuTLS.

A certificate request can be generated by associating it with a private key, setting the subject’s information and finally self signing it. The last step ensures that the requester is in possession of the private key.

int gnutls_x509_crq_set_version (gnutls_x509_crq_t crq, unsigned int version)

int gnutls_x509_crq_set_dn (gnutls_x509_crq_t crq, const char * dn, const char ** err)

int gnutls_x509_crq_set_dn_by_oid (gnutls_x509_crq_t crq, const char * oid, unsigned int raw_flag, const void * data, unsigned int sizeof_data)

int gnutls_x509_crq_set_key_usage (gnutls_x509_crq_t crq, unsigned int usage)

int gnutls_x509_crq_set_key_purpose_oid (gnutls_x509_crq_t crq, const void * oid, unsigned int critical)

int gnutls_x509_crq_set_basic_constraints (gnutls_x509_crq_t crq, unsigned int ca, int pathLenConstraint)

The gnutls_x509_crq_set_key and gnutls_x509_crq_sign2 functions associate the request with a private key and sign it. If a request is to be signed with a key residing in a PKCS #11 token it is recommended to use the signing functions shown in Abstract key types.

Function: int gnutls_x509_crq_set_key (gnutls_x509_crq_t crq, gnutls_x509_privkey_t key) ¶

crq: should contain a gnutls_x509_crq_t type

key: holds a private key

This function will set the public parameters from the given private key to the request.

Returns: On success, GNUTLS_E_SUCCESS (0) is returned, otherwise a negative error value.

Function: int gnutls_x509_crq_sign2 (gnutls_x509_crq_t crq, gnutls_x509_privkey_t key, gnutls_digest_algorithm_t dig, unsigned int flags) ¶

crq: should contain a gnutls_x509_crq_t type

key: holds a private key

dig: The message digest to use, i.e., GNUTLS_DIG_SHA256

flags: must be 0

This function will sign the certificate request with a private key. This must be the same key as the one used in gnutls_x509_crt_set_key() since a certificate request is self signed.

This must be the last step in a certificate request generation since all the previously set parameters are now signed.

A known limitation of this function is, that a newly-signed request will not be fully functional (e.g., for signature verification), until it is exported an re-imported.

After GnuTLS 3.6.1 the value of dig may be GNUTLS_DIG_UNKNOWN , and in that case, a suitable but reasonable for the key algorithm will be selected.

Returns: GNUTLS_E_SUCCESS on success, otherwise a negative error code. GNUTLS_E_ASN1_VALUE_NOT_FOUND is returned if you didn’t set all information in the certificate request (e.g., the version using gnutls_x509_crq_set_version() ).

The following example is about generating a certificate request, and a private key. A certificate request can be later be processed by a CA which should return a signed certificate.

/* This example code is placed in the public domain. */

#ifdef HAVE_CONFIG_H
#include <config.h>
#endif

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <gnutls/gnutls.h>
#include <gnutls/x509.h>
#include <gnutls/abstract.h>
#include <time.h>

/* This example will generate a private key and a certificate
 * request.
 */

int main(void)
{
	gnutls_x509_crq_t crq;
	gnutls_x509_privkey_t key;
	unsigned char buffer[10 * 1024];
	size_t buffer_size = sizeof(buffer);
	unsigned int bits;

	gnutls_global_init();

	/* Initialize an empty certificate request, and
	 * an empty private key.
	 */
	gnutls_x509_crq_init(&crq);

	gnutls_x509_privkey_init(&key);

	/* Generate an RSA key of moderate security.
	 */
	bits = gnutls_sec_param_to_pk_bits(GNUTLS_PK_RSA,
					   GNUTLS_SEC_PARAM_MEDIUM);
	gnutls_x509_privkey_generate(key, GNUTLS_PK_RSA, bits, 0);

	/* Add stuff to the distinguished name
	 */
	gnutls_x509_crq_set_dn_by_oid(crq, GNUTLS_OID_X520_COUNTRY_NAME, 0,
				      "GR", 2);

	gnutls_x509_crq_set_dn_by_oid(crq, GNUTLS_OID_X520_COMMON_NAME, 0,
				      "Nikos", strlen("Nikos"));

	/* Set the request version.
	 */
	gnutls_x509_crq_set_version(crq, 1);

	/* Set a challenge password.
	 */
	gnutls_x509_crq_set_challenge_password(crq,
					       "something to remember here");

	/* Associate the request with the private key
	 */
	gnutls_x509_crq_set_key(crq, key);

	/* Self sign the certificate request.
	 */
	gnutls_x509_crq_sign2(crq, key, GNUTLS_DIG_SHA1, 0);

	/* Export the PEM encoded certificate request, and
	 * display it.
	 */
	gnutls_x509_crq_export(crq, GNUTLS_X509_FMT_PEM, buffer, &buffer_size);

	printf("Certificate Request: \n%s", buffer);

	/* Export the PEM encoded private key, and
	 * display it.
	 */
	buffer_size = sizeof(buffer);
	gnutls_x509_privkey_export(key, GNUTLS_X509_FMT_PEM, buffer,
				   &buffer_size);

	printf("\n\nPrivate key: \n%s", buffer);

	gnutls_x509_crq_deinit(crq);
	gnutls_x509_privkey_deinit(key);

	return 0;
}

4.2.2 PKIX certificate revocation lists ¶

A certificate revocation list (CRL) is a structure issued by an authority periodically containing a list of revoked certificates serial numbers. The CRL structure is signed with the issuing authorities’ keys. A typical CRL contains the fields as shown in Table 4.5. Certificate revocation lists are used to complement the expiration date of a certificate, in order to account for other reasons of revocation, such as compromised keys, etc.

Each CRL is valid for limited amount of time and is required to provide, except for the current issuing time, also the issuing time of the next update.

The basic CRL structure functions follow.

int gnutls_x509_crl_init (gnutls_x509_crl_t * crl)

int gnutls_x509_crl_import (gnutls_x509_crl_t crl, const gnutls_datum_t * data, gnutls_x509_crt_fmt_t format)

int gnutls_x509_crl_export (gnutls_x509_crl_t crl, gnutls_x509_crt_fmt_t format, void * output_data, size_t * output_data_size)

int gnutls_x509_crl_export (gnutls_x509_crl_t crl, gnutls_x509_crt_fmt_t format, void * output_data, size_t * output_data_size)

Reading a CRL ¶

The most important function that extracts the certificate revocation information from a CRL is gnutls_x509_crl_get_crt_serial. Other functions that return other fields of the CRL structure are also provided.

Function: int gnutls_x509_crl_get_crt_serial (gnutls_x509_crl_t crl, unsigned indx, unsigned char * serial, size_t * serial_size, time_t * t) ¶

crl: should contain a gnutls_x509_crl_t type

indx: the index of the certificate to extract (starting from 0)

serial: where the serial number will be copied

serial_size: initially holds the size of serial

t: if non null, will hold the time this certificate was revoked

This function will retrieve the serial number of the specified, by the index, revoked certificate.

Note that this function will have performance issues in large sequences of revoked certificates. In that case use gnutls_x509_crl_iter_crt_serial() .

Returns: On success, GNUTLS_E_SUCCESS (0) is returned, otherwise a negative error value.

int gnutls_x509_crl_get_version (gnutls_x509_crl_t crl)

int gnutls_x509_crl_get_issuer_dn (gnutls_x509_crl_t crl, char * buf, size_t * sizeof_buf)

int gnutls_x509_crl_get_issuer_dn2 (gnutls_x509_crl_t crl, gnutls_datum_t * dn)

time_t gnutls_x509_crl_get_this_update (gnutls_x509_crl_t crl)

time_t gnutls_x509_crl_get_next_update (gnutls_x509_crl_t crl)

int gnutls_x509_crl_get_crt_count (gnutls_x509_crl_t crl)

Generation of a CRL ¶

The following functions can be used to generate a CRL.

int gnutls_x509_crl_set_version (gnutls_x509_crl_t crl, unsigned int version)

int gnutls_x509_crl_set_crt_serial (gnutls_x509_crl_t crl, const void * serial, size_t serial_size, time_t revocation_time)

int gnutls_x509_crl_set_crt (gnutls_x509_crl_t crl, gnutls_x509_crt_t crt, time_t revocation_time)

int gnutls_x509_crl_set_next_update (gnutls_x509_crl_t crl, time_t exp_time)

int gnutls_x509_crl_set_this_update (gnutls_x509_crl_t crl, time_t act_time)

The gnutls_x509_crl_sign2 and gnutls_x509_crl_privkey_sign functions sign the revocation list with a private key. The latter function can be used to sign with a key residing in a PKCS #11 token.

Function: int gnutls_x509_crl_sign2 (gnutls_x509_crl_t crl, gnutls_x509_crt_t issuer, gnutls_x509_privkey_t issuer_key, gnutls_digest_algorithm_t dig, unsigned int flags) ¶

crl: should contain a gnutls_x509_crl_t type

issuer: is the certificate of the certificate issuer

issuer_key: holds the issuer’s private key

dig: The message digest to use. GNUTLS_DIG_SHA256 is the safe choice unless you know what you’re doing.

flags: must be 0

This function will sign the CRL with the issuer’s private key, and will copy the issuer’s information into the CRL.

This must be the last step in a certificate CRL since all the previously set parameters are now signed.

A known limitation of this function is, that a newly-signed CRL will not be fully functional (e.g., for signature verification), until it is exported an re-imported.

After GnuTLS 3.6.1 the value of dig may be GNUTLS_DIG_UNKNOWN , and in that case, a suitable but reasonable for the key algorithm will be selected.

Returns: On success, GNUTLS_E_SUCCESS (0) is returned, otherwise a negative error value.

Function: int gnutls_x509_crl_privkey_sign (gnutls_x509_crl_t crl, gnutls_x509_crt_t issuer, gnutls_privkey_t issuer_key, gnutls_digest_algorithm_t dig, unsigned int flags) ¶

crl: should contain a gnutls_x509_crl_t type

issuer: is the certificate of the certificate issuer

issuer_key: holds the issuer’s private key

dig: The message digest to use. GNUTLS_DIG_SHA256 is the safe choice unless you know what you’re doing.

flags: must be 0

This function will sign the CRL with the issuer’s private key, and will copy the issuer’s information into the CRL.

This must be the last step in a certificate CRL since all the previously set parameters are now signed.

A known limitation of this function is, that a newly-signed CRL will not be fully functional (e.g., for signature verification), until it is exported an re-imported.

After GnuTLS 3.6.1 the value of dig may be GNUTLS_DIG_UNKNOWN , and in that case, a suitable but reasonable for the key algorithm will be selected.

Returns: On success, GNUTLS_E_SUCCESS (0) is returned, otherwise a negative error value.

Since 2.12.0

Few extensions on the CRL structure are supported, including the CRL number extension and the authority key identifier.

int gnutls_x509_crl_set_number (gnutls_x509_crl_t crl, const void * nr, size_t nr_size)

int gnutls_x509_crl_set_authority_key_id (gnutls_x509_crl_t crl, const void * id, size_t id_size)

4.2.3 OCSP certificate status checking ¶

Certificates may be revoked before their expiration time has been reached. There are several reasons for revoking certificates, but a typical situation is when the private key associated with a certificate has been compromised. Traditionally, Certificate Revocation Lists (CRLs) have been used by application to implement revocation checking, however, several problems with CRLs have been identified [RIVESTCRL].

The Online Certificate Status Protocol, or OCSP [RFC2560], is a widely implemented protocol which performs certificate revocation status checking. An application that wish to verify the identity of a peer will verify the certificate against a set of trusted certificates and then check whether the certificate is listed in a CRL and/or perform an OCSP check for the certificate.

Applications are typically expected to contact the OCSP server in order to request the certificate validity status. The OCSP server replies with an OCSP response. This section describes this online communication (which can be avoided when using OCSP stapled responses, for that, see OCSP stapling).

Before performing the OCSP query, the application will need to figure out the address of the OCSP server. The OCSP server address can be provided by the local user in manual configuration or may be stored in the certificate that is being checked. When stored in a certificate the OCSP server is in the extension field called the Authority Information Access (AIA). The following function extracts this information from a certificate.

int gnutls_x509_crt_get_authority_info_access (gnutls_x509_crt_t crt, unsigned int seq, int what, gnutls_datum_t * data, unsigned int * critical)

There are several functions in GnuTLS for creating and manipulating OCSP requests and responses. The general idea is that a client application creates an OCSP request object, stores some information about the certificate to check in the request, and then exports the request in DER format. The request will then need to be sent to the OCSP responder, which needs to be done by the application (GnuTLS does not send and receive OCSP packets). Normally an OCSP response is received that the application will need to import into an OCSP response object. The digital signature in the OCSP response needs to be verified against a set of trust anchors before the information in the response can be trusted.

The ASN.1 structure of OCSP requests are briefly as follows. It is useful to review the structures to get an understanding of which fields are modified by GnuTLS functions.

OCSPRequest     ::=     SEQUENCE {
    tbsRequest                  TBSRequest,
    optionalSignature   [0]     EXPLICIT Signature OPTIONAL }

TBSRequest      ::=     SEQUENCE {
    version             [0]     EXPLICIT Version DEFAULT v1,
    requestorName       [1]     EXPLICIT GeneralName OPTIONAL,
    requestList                 SEQUENCE OF Request,
    requestExtensions   [2]     EXPLICIT Extensions OPTIONAL }

Request         ::=     SEQUENCE {
    reqCert                     CertID,
    singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

CertID          ::=     SEQUENCE {
    hashAlgorithm       AlgorithmIdentifier,
    issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
    issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
    serialNumber        CertificateSerialNumber }

The basic functions to initialize, import, export and deallocate OCSP requests are the following.

int gnutls_ocsp_req_init (gnutls_ocsp_req_t * req)

void gnutls_ocsp_req_deinit (gnutls_ocsp_req_t req)

int gnutls_ocsp_req_import (gnutls_ocsp_req_t req, const gnutls_datum_t * data)

int gnutls_ocsp_req_export (gnutls_ocsp_req_const_t req, gnutls_datum_t * data)

int gnutls_ocsp_req_print (gnutls_ocsp_req_const_t req, gnutls_ocsp_print_formats_t format, gnutls_datum_t * out)

To generate an OCSP request the issuer name hash, issuer key hash, and the checked certificate’s serial number are required. There are two interfaces available for setting those in an OCSP request. The is a low-level function when you have the issuer name hash, issuer key hash, and certificate serial number in binary form. The second is more useful if you have the certificate (and its issuer) in a gnutls_x509_crt_t type. There is also a function to extract this information from existing an OCSP request.

int gnutls_ocsp_req_add_cert_id (gnutls_ocsp_req_t req, gnutls_digest_algorithm_t digest, const gnutls_datum_t * issuer_name_hash, const gnutls_datum_t * issuer_key_hash, const gnutls_datum_t * serial_number)

int gnutls_ocsp_req_add_cert (gnutls_ocsp_req_t req, gnutls_digest_algorithm_t digest, gnutls_x509_crt_t issuer, gnutls_x509_crt_t cert)

int gnutls_ocsp_req_get_cert_id (gnutls_ocsp_req_const_t req, unsigned indx, gnutls_digest_algorithm_t * digest, gnutls_datum_t * issuer_name_hash, gnutls_datum_t * issuer_key_hash, gnutls_datum_t * serial_number)

Each OCSP request may contain a number of extensions. Extensions are identified by an Object Identifier (OID) and an opaque data buffer whose syntax and semantics is implied by the OID. You can extract or set those extensions using the following functions.

int gnutls_ocsp_req_get_extension (gnutls_ocsp_req_const_t req, unsigned indx, gnutls_datum_t * oid, unsigned int * critical, gnutls_datum_t * data)

int gnutls_ocsp_req_set_extension (gnutls_ocsp_req_t req, const char * oid, unsigned int critical, const gnutls_datum_t * data)

A common OCSP Request extension is the nonce extension (OID 1.3.6.1.5.5.7.48.1.2), which is used to avoid replay attacks of earlier recorded OCSP responses. The nonce extension carries a value that is intended to be sufficiently random and unique so that an attacker will not be able to give a stale response for the same nonce.

int gnutls_ocsp_req_get_nonce (gnutls_ocsp_req_const_t req, unsigned int * critical, gnutls_datum_t * nonce)

int gnutls_ocsp_req_set_nonce (gnutls_ocsp_req_t req, unsigned int critical, const gnutls_datum_t * nonce)

int gnutls_ocsp_req_randomize_nonce (gnutls_ocsp_req_t req)

The OCSP response structures is a complex structure. A simplified overview of it is in Table 4.6. Note that a response may contain information on multiple certificates.

We provide basic functions for initialization, importing, exporting and deallocating OCSP responses.

int gnutls_ocsp_resp_init (gnutls_ocsp_resp_t * resp)

void gnutls_ocsp_resp_deinit (gnutls_ocsp_resp_t resp)

int gnutls_ocsp_resp_import (gnutls_ocsp_resp_t resp, const gnutls_datum_t * data)

int gnutls_ocsp_resp_export (gnutls_ocsp_resp_const_t resp, gnutls_datum_t * data)

int gnutls_ocsp_resp_print (gnutls_ocsp_resp_const_t resp, gnutls_ocsp_print_formats_t format, gnutls_datum_t * out)

The utility function that extracts the revocation as well as other information from a response is shown below.

Function: int gnutls_ocsp_resp_get_single (gnutls_ocsp_resp_const_t resp, unsigned indx, gnutls_digest_algorithm_t * digest, gnutls_datum_t * issuer_name_hash, gnutls_datum_t * issuer_key_hash, gnutls_datum_t * serial_number, unsigned int * cert_status, time_t * this_update, time_t * next_update, time_t * revocation_time, unsigned int * revocation_reason) ¶

resp: should contain a gnutls_ocsp_resp_t type

indx: Specifies response number to get. Use (0) to get the first one.

digest: output variable with gnutls_digest_algorithm_t hash algorithm

issuer_name_hash: output buffer with hash of issuer’s DN

issuer_key_hash: output buffer with hash of issuer’s public key

serial_number: output buffer with serial number of certificate to check

cert_status: a certificate status, a gnutls_ocsp_cert_status_t enum.

this_update: time at which the status is known to be correct.

next_update: when newer information will be available, or (time_t)-1 if unspecified

revocation_time: when cert_status is GNUTLS_OCSP_CERT_REVOKED , holds time of revocation.

revocation_reason: revocation reason, a gnutls_x509_crl_reason_t enum.

This function will return the certificate information of the indx ’ed response in the Basic OCSP Response resp . The information returned corresponds to the OCSP SingleResponse structure except the final singleExtensions.

Each of the pointers to output variables may be NULL to indicate that the caller is not interested in that value.

Returns: On success, GNUTLS_E_SUCCESS (0) is returned, otherwise a negative error code is returned. If you have reached the last CertID available GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE will be returned.

The possible revocation reasons available in an OCSP response are shown below.

Note, that the OCSP response needs to be verified against some set of trust anchors before it can be relied upon. It is also important to check whether the received OCSP response corresponds to the certificate being checked.

int gnutls_ocsp_resp_verify (gnutls_ocsp_resp_const_t resp, gnutls_x509_trust_list_t trustlist, unsigned int * verify, unsigned int flags)

int gnutls_ocsp_resp_verify_direct (gnutls_ocsp_resp_const_t resp, gnutls_x509_crt_t issuer, unsigned int * verify, unsigned int flags)

int gnutls_ocsp_resp_check_crt (gnutls_ocsp_resp_const_t resp, unsigned int indx, gnutls_x509_crt_t crt)

4.2.4 OCSP stapling ¶

To avoid applications contacting the OCSP server directly, TLS servers can provide a "stapled" OCSP response in the TLS handshake. That way the client application needs to do nothing more. GnuTLS will automatically consider the stapled OCSP response during the TLS certificate verification (see gnutls_certificate_verify_peers2). To disable the automatic OCSP verification the flag GNUTLS_VERIFY_DISABLE_CRL_CHECKS should be specified to gnutls_certificate_set_verify_flags.

Since GnuTLS 3.5.1 the client certificate verification will consider the [RFC7633] OCSP-Must-staple certificate extension, and will consider it while checking for stapled OCSP responses. If the extension is present and no OCSP staple is found, the certificate verification will fail and the status code GNUTLS_CERT_MISSING_OCSP_STATUS will returned from the verification function.

Under TLS 1.2 only one stapled response can be sent by a server, the OCSP response associated with the end-certificate. Under TLS 1.3 a server can send multiple OCSP responses, typically one for each certificate in the certificate chain. The following functions can be used by a client application to retrieve the OCSP responses as sent by the server.

int gnutls_ocsp_status_request_get (gnutls_session_t session, gnutls_datum_t * response)

int gnutls_ocsp_status_request_get2 (gnutls_session_t session, unsigned idx, gnutls_datum_t * response)

GnuTLS servers can provide OCSP responses to their clients using the following functions.

void gnutls_certificate_set_retrieve_function3 (gnutls_certificate_credentials_t cred, gnutls_certificate_retrieve_function3 * func)

int gnutls_certificate_set_ocsp_status_request_file2 (gnutls_certificate_credentials_t sc, const char * response_file, unsigned idx, gnutls_x509_crt_fmt_t fmt)

unsigned gnutls_ocsp_status_request_is_checked (gnutls_session_t session, unsigned int flags)

A server is expected to provide the relevant certificate’s OCSP responses using gnutls_certificate_set_ocsp_status_request_file2, and ensure a periodic reload/renew of the credentials. An estimation of the OCSP responses expiration can be obtained using the gnutls_certificate_get_ocsp_expiration function.

Function: time_t gnutls_certificate_get_ocsp_expiration (gnutls_certificate_credentials_t sc, unsigned idx, int oidx, unsigned flags) ¶

sc: is a credentials structure.

idx: is a certificate chain index as returned by gnutls_certificate_set_key() and friends

oidx: is an OCSP response index

flags: should be zero

This function returns the validity of the loaded OCSP responses, to provide information on when to reload/refresh them.

Note that the credentials structure should be read-only when in use, thus when reloading, either the credentials structure must not be in use by any sessions, or a new credentials structure should be allocated for new sessions.

When oidx is (-1) then the minimum refresh time for all responses is returned. Otherwise the index specifies the response corresponding to the odix certificate in the certificate chain.

Returns: On success, the expiration time of the OCSP response. Otherwise (time_t)(-1) on error, or (time_t)-2 on out of bounds.

Since: 3.6.3

Prior to GnuTLS 3.6.4, the functions gnutls_certificate_set_ocsp_status_request_function2 gnutls_certificate_set_ocsp_status_request_file were provided to set OCSP responses. These functions are still functional, but cannot be used to set multiple OCSP responses as allowed by TLS1.3.

The responses can be updated periodically using the ’ocsptool’ command (see also Invoking ocsptool).

ocsptool --ask --load-cert server_cert.pem --load-issuer the_issuer.pem
         --load-signer the_issuer.pem --outfile ocsp.resp

In order to allow multiple OCSP responses to be concatenated, GnuTLS supports PEM-encoded OCSP responses. These can be generated using ’ocsptool’ with the ’–no-outder’ parameter.

4.2.5 Managing encrypted keys ¶

Transferring or storing private keys in plain may not be a good idea, since any compromise is irreparable. Storing the keys in hardware security modules (see Smart cards and HSMs) could solve the storage problem but it is not always practical or efficient enough. This section describes ways to store and transfer encrypted private keys.

There are methods for key encryption, namely the PKCS #8, PKCS #12 and OpenSSL’s custom encrypted private key formats. The PKCS #8 and the OpenSSL’s method allow encryption of the private key, while the PKCS #12 method allows, in addition, the bundling of accompanying data into the structure. That is typically the corresponding certificate, as well as a trusted CA certificate.

High level functionality ¶

Generic and higher level private key import functions are available, that import plain or encrypted keys and will auto-detect the encrypted key format.

Function: int gnutls_privkey_import_x509_raw (gnutls_privkey_t pkey, const gnutls_datum_t * data, gnutls_x509_crt_fmt_t format, const char * password, unsigned int flags) ¶

pkey: The private key

data: The private key data to be imported

format: The format of the private key

password: A password (optional)

flags: an ORed sequence of gnutls_pkcs_encrypt_flags_t

This function will import the given private key to the abstract gnutls_privkey_t type.

The supported formats are basic unencrypted key, PKCS8, PKCS12, TSS2, and the openssl format.

Returns: On success, GNUTLS_E_SUCCESS (0) is returned, otherwise a negative error value.

Since: 3.1.0

Function: int gnutls_x509_privkey_import2 (gnutls_x509_privkey_t key, const gnutls_datum_t * data, gnutls_x509_crt_fmt_t format, const char * password, unsigned int flags) ¶

key: The data to store the parsed key

data: The DER or PEM encoded key.

format: One of DER or PEM

password: A password (optional)

flags: an ORed sequence of gnutls_pkcs_encrypt_flags_t

This function will import the given DER or PEM encoded key, to the native gnutls_x509_privkey_t format, irrespective of the input format. The input format is auto-detected.

The supported formats are basic unencrypted key, PKCS8, PKCS12, and the openssl format.

If the provided key is encrypted but no password was given, then GNUTLS_E_DECRYPTION_FAILED is returned. Since GnuTLS 3.4.0 this function will utilize the PIN callbacks if any.

Returns: On success, GNUTLS_E_SUCCESS (0) is returned, otherwise a negative error value.

Any keys imported using those functions can be imported to a certificate credentials structure using gnutls_certificate_set_key, or alternatively they can be directly imported using gnutls_certificate_set_x509_key_file2.

PKCS #8 structures ¶

PKCS #8 keys can be imported and exported as normal private keys using the functions below. An addition to the normal import functions, are a password and a flags argument. The flags can be any element of the gnutls_pkcs_encrypt_flags_t enumeration. Note however, that GnuTLS only supports the PKCS #5 PBES2 encryption scheme. Keys encrypted with the obsolete PBES1 scheme cannot be decrypted.

int gnutls_x509_privkey_import_pkcs8 (gnutls_x509_privkey_t key, const gnutls_datum_t * data, gnutls_x509_crt_fmt_t format, const char * password, unsigned int flags)

int gnutls_x509_privkey_export_pkcs8 (gnutls_x509_privkey_t key, gnutls_x509_crt_fmt_t format, const char * password, unsigned int flags, void * output_data, size_t * output_data_size)

int gnutls_x509_privkey_export2_pkcs8 (gnutls_x509_privkey_t key, gnutls_x509_crt_fmt_t format, const char * password, unsigned int flags, gnutls_datum_t * out)

PKCS #12 structures ¶

A PKCS #12 structure [PKCS12] usually contains a user’s private keys and certificates. It is commonly used in browsers to export and import the user’s identities. A file containing such a key can be directly imported to a certificate credentials structure by using gnutls_certificate_set_x509_simple_pkcs12_file.

In GnuTLS the PKCS #12 structures are handled using the gnutls_pkcs12_t type. This is an abstract type that may hold several gnutls_pkcs12_bag_t types. The bag types are the holders of the actual data, which may be certificates, private keys or encrypted data. A bag of type encrypted should be decrypted in order for its data to be accessed.

To reduce the complexity in parsing the structures the simple helper function gnutls_pkcs12_simple_parse is provided. For more advanced uses, manual parsing of the structure is required using the functions below.

int gnutls_pkcs12_get_bag (gnutls_pkcs12_t pkcs12, int indx, gnutls_pkcs12_bag_t bag)

int gnutls_pkcs12_verify_mac (gnutls_pkcs12_t pkcs12, const char * pass)

int gnutls_pkcs12_bag_decrypt (gnutls_pkcs12_bag_t bag, const char * pass)

int gnutls_pkcs12_bag_get_count (gnutls_pkcs12_bag_t bag)

Function: int gnutls_pkcs12_simple_parse (gnutls_pkcs12_t p12, const char * password, gnutls_x509_privkey_t * key, gnutls_x509_crt_t ** chain, unsigned int * chain_len, gnutls_x509_crt_t ** extra_certs, unsigned int * extra_certs_len, gnutls_x509_crl_t * crl, unsigned int flags) ¶

p12: A pkcs12 type

password: optional password used to decrypt the structure, bags and keys.

key: a structure to store the parsed private key.

chain: the corresponding to key certificate chain (may be NULL )

chain_len: will be updated with the number of additional (may be NULL )

extra_certs: optional pointer to receive an array of additional certificates found in the PKCS12 structure (may be NULL ).

extra_certs_len: will be updated with the number of additional certs (may be NULL ).

crl: an optional structure to store the parsed CRL (may be NULL ).

flags: should be zero or one of GNUTLS_PKCS12_SP_*

This function parses a PKCS12 structure in pkcs12 and extracts the private key, the corresponding certificate chain, any additional certificates and a CRL. The structures in key , chain crl , and extra_certs must not be initialized.

The extra_certs and extra_certs_len parameters are optional and both may be set to NULL . If either is non-NULL , then both must be set. The value for extra_certs is allocated using gnutls_malloc() .

Encrypted PKCS12 bags and PKCS8 private keys are supported, but only with password based security and the same password for all operations.

Note that a PKCS12 structure may contain many keys and/or certificates, and there is no way to identify which key/certificate pair you want. For this reason this function is useful for PKCS12 files that contain only one key/certificate pair and/or one CRL.

If the provided structure has encrypted fields but no password is provided then this function returns GNUTLS_E_DECRYPTION_FAILED .

Note that normally the chain constructed does not include self signed certificates, to comply with TLS’ requirements. If, however, the flag GNUTLS_PKCS12_SP_INCLUDE_SELF_SIGNED is specified then self signed certificates will be included in the chain.

Prior to using this function the PKCS 12 structure integrity must be verified using gnutls_pkcs12_verify_mac() .

Returns: On success, GNUTLS_E_SUCCESS (0) is returned, otherwise a negative error value.

Since: 3.1.0

int gnutls_pkcs12_bag_get_data (gnutls_pkcs12_bag_t bag, unsigned indx, gnutls_datum_t * data)

int gnutls_pkcs12_bag_get_key_id (gnutls_pkcs12_bag_t bag, unsigned indx, gnutls_datum_t * id)

int gnutls_pkcs12_bag_get_friendly_name (gnutls_pkcs12_bag_t bag, unsigned indx, char ** name)

The functions below are used to generate a PKCS #12 structure. An example of their usage is shown at PKCS #12 structure generation example.

int gnutls_pkcs12_set_bag (gnutls_pkcs12_t pkcs12, gnutls_pkcs12_bag_t bag)

int gnutls_pkcs12_bag_encrypt (gnutls_pkcs12_bag_t bag, const char * pass, unsigned int flags)

int gnutls_pkcs12_generate_mac (gnutls_pkcs12_t pkcs12, const char * pass)

int gnutls_pkcs12_bag_set_data (gnutls_pkcs12_bag_t bag, gnutls_pkcs12_bag_type_t type, const gnutls_datum_t * data)

int gnutls_pkcs12_bag_set_crl (gnutls_pkcs12_bag_t bag, gnutls_x509_crl_t crl)

int gnutls_pkcs12_bag_set_crt (gnutls_pkcs12_bag_t bag, gnutls_x509_crt_t crt)

int gnutls_pkcs12_bag_set_key_id (gnutls_pkcs12_bag_t bag, unsigned indx, const gnutls_datum_t * id)

int gnutls_pkcs12_bag_set_friendly_name (gnutls_pkcs12_bag_t bag, unsigned indx, const char * name)

OpenSSL encrypted keys ¶

Unfortunately the structures discussed in the previous sections are not the only structures that may hold an encrypted private key. For example the OpenSSL library offers a custom key encryption method. Those structures are also supported in GnuTLS with gnutls_x509_privkey_import_openssl.

Function: int gnutls_x509_privkey_import_openssl (gnutls_x509_privkey_t key, const gnutls_datum_t * data, const char * password) ¶

key: The data to store the parsed key

data: The DER or PEM encoded key.

password: the password to decrypt the key (if it is encrypted).

This function will convert the given PEM encrypted to the native gnutls_x509_privkey_t format. The output will be stored in key .

The password should be in ASCII. If the password is not provided or wrong then GNUTLS_E_DECRYPTION_FAILED will be returned.

If the Certificate is PEM encoded it should have a header of "PRIVATE KEY" and the "DEK-Info" header.

Returns: On success, GNUTLS_E_SUCCESS (0) is returned, otherwise a negative error value.

4.2.6 Invoking certtool ¶

Tool to parse and generate X.509 certificates, requests and private keys. It can be used interactively or non interactively by specifying the template command line option.

The tool accepts files or supported URIs via the –infile option. In case PIN is required for URI access you can provide it using the environment variables GNUTLS_PIN and GNUTLS_SO_PIN.

certtool help/usage (-?) ¶

The text printed is the same whether selected with the help option (--help) or the more-help option (--more-help). more-help will print the usage text by passing it through a pager program. more-help is disabled on platforms without a working fork(2) function. The PAGER environment variable is used to select the program, defaulting to more. Both will exit with a status code of 0.

certtool - GnuTLS certificate tool
Usage:  certtool [ -<flag> [<val>] | --<name>[{=| }<val>] ]... 

None:

   -d, --debug=num            Enable debugging
				- it must be in the range:
				  0 to 9999
   -V, --verbose              More verbose output
       --infile=file          Input file
				- file must pre-exist
       --outfile=str          Output file
       --attime=str           Perform validation at the timestamp instead of the system time

Certificate related options:

   -i, --certificate-info     Print information on the given certificate
       --pubkey-info          Print information on a public key
   -s, --generate-self-signed Generate a self-signed certificate
   -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
       --key-id               Print the key ID of the given certificate
       --v1                   Generate an X.509 version 1 certificate (with no extensions)
       --sign-params=str      Sign a certificate with a specific signature algorithm

Certificate request related options:

       --crq-info             Print information on the given certificate request
   -q, --generate-request     Generate a PKCS #10 certificate request
				- prohibits the option 'infile'
       --no-crq-extensions    Do not use extensions in certificate requests

PKCS#12 file related options:

       --p12-info             Print information on a PKCS #12 structure
       --p12-name=str         The PKCS #12 friendly name to use
       --to-p12               Generate a PKCS #12 structure
       --pbmac1               Use PBMAC1 in a PKCS #12 structure

Private key related options:

   -k, --key-info             Print information on a private key
       --p8-info              Print information on a PKCS #8 structure
       --to-rsa               Convert an RSA-PSS key to raw RSA format
   -p, --generate-privkey     Generate a private key
       --key-type=str         Specify the key type to use on key generation
       --bits=num             Specify the number of bits for key generation
       --curve=str            Specify the curve used for EC key generation
       --sec-param=str        Specify the security level [low, legacy, medium, high, ultra]
       --to-p8                Convert a given key to a PKCS #8 structure
   -8, --pkcs8                Use PKCS #8 format for private keys
       --provable             Generate a private key or parameters from a seed using a provable method
       --verify-provable-privkey  Verify a private key generated from a seed using a provable method
       --seed=str             When generating a private key use the given hex-encoded seed

CRL related options:

   -l, --crl-info             Print information on the given CRL structure
       --generate-crl         Generate a CRL
       --verify-crl           Verify a Certificate Revocation List using a trusted list
				- requires the option 'load-ca-certificate'

Certificate verification related options:

   -e, --verify-chain         Verify a PEM encoded certificate chain
       --verify               Verify a PEM encoded certificate (chain) against a trusted set
       --verify-hostname=str  Specify a hostname to be used for certificate chain verification
       --verify-email=str     Specify a email to be used for certificate chain verification
				- prohibits the option 'verify-hostname'
       --verify-purpose=str   Specify a purpose OID to be used for certificate chain verification
       --verify-allow-broken  Allow broken algorithms, such as MD5 for verification
       --verify-profile=str   Specify a security level profile to be used for verification

PKCS#7 structure options:

       --p7-generate          Generate a PKCS #7 structure
       --p7-sign              Signs using a PKCS #7 structure
       --p7-detached-sign     Signs using a detached PKCS #7 structure
       --p7-include-cert      The signer's certificate will be included in the cert list
				- enabled by default
				- disabled as '--no-p7-include-cert'
       --p7-time              Will include a timestamp in the PKCS #7 structure
       --p7-show-data         Will show the embedded data in the PKCS #7 structure
       --p7-info              Print information on a PKCS #7 structure
       --p7-verify            Verify the provided PKCS #7 structure
       --smime-to-p7          Convert S/MIME to PKCS #7 structure

Other options:

       --get-dh-params        List the included PKCS #3 encoded Diffie-Hellman parameters
       --dh-info              Print information PKCS #3 encoded Diffie-Hellman parameters
       --load-privkey=str     Loads a private key file
       --load-pubkey=str      Loads a public key file
       --load-request=str     Loads a certificate request file
       --load-certificate=str Loads a certificate file
       --load-ca-privkey=str  Loads the certificate authority's private key file
       --load-ca-certificate=str Loads the certificate authority's certificate file
       --load-crl=str         Loads the provided CRL
       --load-data=str        Loads auxiliary data
       --password=str         Password to use
       --null-password        Enforce a NULL password
       --empty-password       Enforce an empty password
       --hex-numbers          Print big number in an easier format to parse
       --cprint               In certain operations it prints the information in C-friendly format
       --hash=str             Hash algorithm to use for signing
       --salt-size=num        Specify the RSA-PSS key default salt size
       --label=str            Specify the RSA-OAEP label, encoded in hexadecimal
       --inder                Use DER format for input certificates, private keys, and DH parameters 
       --inraw                an alias for the 'inder' option
       --outder               Use DER format for output certificates, private keys, and DH parameters
       --outraw               an alias for the 'outder' option
       --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
       --pkcs-cipher=str      Cipher to use for PKCS #8 and #12 operations
       --provider=str         Specify the PKCS #11 provider library
       --text                 Output textual information before PEM-encoded certificates, private keys, etc
				- enabled by default
				- disabled as '--no-text'

Version, usage and configuration options:

   -v, --version[=arg]        output version information and exit
   -h, --help                 display extended usage information and exit
   -!, --more-help            extended usage information passed thru pager

Options are specified by doubled hyphens and their name or by a single
hyphen and the flag character.

Tool to parse and generate X.509 certificates, requests and private keys.
It can be used interactively or non interactively by
specifying the template command line option.

The tool accepts files or supported URIs via the --infile option. In case PIN
is required for URI access you can provide it using the environment variables GNUTLS_PIN 
and GNUTLS_SO_PIN.


Please send bug reports to:  <bugs@gnutls.org>

debug option (-d). ¶

This is the “enable debugging” option. This option takes a ArgumentType.NUMBER argument. Specifies the debug level.

attime option. ¶

This is the “perform validation at the timestamp instead of the system time” option. This option takes a ArgumentType.STRING argument timestamp. 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 available at <https://www.gnu.org/software/coreutils/manual/html_node/Date-input-formats.html> or locally via info ’(coreutils) date invocation’.

cert-options options ¶

Certificate related options.

pubkey-info option. ¶

This is the “print information on a public key” option. The option combined with –load-request, –load-pubkey, –load-privkey and –load-certificate will extract the public key of the object in question.

fingerprint option. ¶

This is the “print the fingerprint of the given certificate” option. This is a simple hash of the DER encoding of the certificate. It can be combined with the –hash parameter. However, it is recommended for identification to use the key-id which depends only on the certificate’s key.

key-id option. ¶

This is the “print the key id of the given certificate” option. 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.

certificate-pubkey option. ¶

This is the “print certificate’s public key” option. This option is deprecated as a duplicate of –pubkey-info

NOTE: THIS OPTION IS DEPRECATED

sign-params option. ¶

This is the “sign a certificate with a specific signature algorithm” option. This option takes a ArgumentType.STRING argument. 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-options options ¶

Certificate request related options.

generate-request option (-q). ¶

This is the “generate a pkcs #10 certificate request” option.

This option has some usage constraints. It:

• 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.

pkcs12-options options ¶

PKCS#12 file related options.

p12-info option. ¶

This is the “print information on a pkcs #12 structure” option. This option will dump the contents and print the metadata of the provided PKCS #12 structure.

p12-name option. ¶

This is the “the pkcs #12 friendly name to use” option. This option takes a ArgumentType.STRING argument. The name to be used for the primary certificate and private key in a PKCS #12 file.

to-p12 option. ¶

This is the “generate a pkcs #12 structure” option. It requires a certificate, a private key and possibly a CA certificate to be specified.

key-options options ¶

Private key related options.

p8-info option. ¶

This is the “print information on a pkcs #8 structure” option. This option will print information about encrypted PKCS #8 structures. That option does not require the decryption of the structure.

to-rsa option. ¶

This is the “convert an rsa-pss key to raw rsa format” option. 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.

generate-privkey option (-p). ¶

This is the “generate a private key” option. 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 option. ¶

This is the “specify the key type to use on key generation” option. This option takes a ArgumentType.STRING argument. 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.

curve option. ¶

This is the “specify the curve used for ec key generation” option. This option takes a ArgumentType.STRING argument. Supported values are secp192r1, secp224r1, secp256r1, secp384r1 and secp521r1.

sec-param option. ¶

This is the “specify the security level [low, legacy, medium, high, ultra]” option. This option takes a ArgumentType.STRING argument Security parameter. This is alternative to the bits option.

to-p8 option. ¶

This is the “convert a given key to a pkcs #8 structure” option. This needs to be combined with –load-privkey.

provable option. ¶

This is the “generate a private key or parameters from a seed using a provable method” option. 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 option. ¶

This is the “verify a private key generated from a seed using a provable method” option. 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 option. ¶

This is the “when generating a private key use the given hex-encoded seed” option. This option takes a ArgumentType.STRING argument. 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).

crl-options options ¶

CRL related options.

generate-crl option. ¶

This is the “generate a crl” option. 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 option. ¶

This is the “verify a certificate revocation list using a trusted list” option.

This option has some usage constraints. It:

• must appear in combination with the following options: load-ca-certificate.

The trusted certificate list must be loaded with –load-ca-certificate.

cert-verify-options options ¶

Certificate verification related options.

verify-chain option (-e). ¶

This is the “verify a pem encoded certificate chain” option. 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 option. ¶

This is the “verify a pem encoded certificate (chain) against a trusted set” option. 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 option. ¶

This is the “specify a hostname to be used for certificate chain verification” option. This option takes a ArgumentType.STRING argument. This is to be combined with one of the verify certificate options.

verify-email option. ¶

This is the “specify a email to be used for certificate chain verification” option. This option takes a ArgumentType.STRING argument.

This option has some usage constraints. It:

• 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 option. ¶

This is the “specify a purpose oid to be used for certificate chain verification” option. This option takes a ArgumentType.STRING argument. 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 option. ¶

This is the “allow broken algorithms, such as md5 for verification” option. This can be combined with –p7-verify, –verify or –verify-chain.

verify-profile option. ¶

This is the “specify a security level profile to be used for verification” option. This option takes a ArgumentType.STRING argument. 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.

pkcs7-options options ¶

PKCS#7 structure options.

p7-generate option. ¶

This is the “generate a pkcs #7 structure” option. This option generates a PKCS #7 certificate container structure. To add certificates in the structure use –load-certificate and –load-crl.

p7-sign option. ¶

This is the “signs using a pkcs #7 structure” option. 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 option. ¶

This is the “signs using a detached pkcs #7 structure” option. This option generates a PKCS #7 structure containing a signature for the provided data from infile. 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-include-cert option. ¶

This is the “the signer’s certificate will be included in the cert list” option.

This option has some usage constraints. It:

• can be disabled with –no-p7-include-cert.
• It is enabled by default.

This options works with –p7-sign or –p7-detached-sign and will include or exclude the signer’s certificate into the generated signature.

p7-time option. ¶

This is the “will include a timestamp in the pkcs #7 structure” option. This option will include a timestamp in the generated signature

p7-show-data option. ¶

This is the “will show the embedded data in the pkcs #7 structure” option. This option can be combined with –p7-verify or –p7-info and will display the embedded signed data in the PKCS #7 structure.

p7-verify option. ¶

This is the “verify the provided pkcs #7 structure” option. This option verifies the signed PKCS #7 structure. The certificate list to use 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.

other-options options ¶

Other options.

generate-dh-params option. ¶

This is the “generate pkcs #3 encoded diffie-hellman parameters” option. The 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 option. ¶

This is the “list the included pkcs #3 encoded diffie-hellman parameters” option. 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.

load-privkey option. ¶

This is the “loads a private key file” option. This option takes a ArgumentType.STRING argument. This can be either a file or a PKCS #11 URL

load-pubkey option. ¶

This is the “loads a public key file” option. This option takes a ArgumentType.STRING argument. This can be either a file or a PKCS #11 URL

load-request option. ¶

This is the “loads a certificate request file” option. This option takes a ArgumentType.STRING argument. This option can be used with a file

load-certificate option. ¶

This is the “loads a certificate file” option. This option takes a ArgumentType.STRING argument. This option can be used with a file

load-ca-privkey option. ¶

This is the “loads the certificate authority’s private key file” option. This option takes a ArgumentType.STRING argument. This can be either a file or a PKCS #11 URL

load-ca-certificate option. ¶

This is the “loads the certificate authority’s certificate file” option. This option takes a ArgumentType.STRING argument. This can be either a file or a PKCS #11 URL

load-crl option. ¶

This is the “loads the provided crl” option. This option takes a ArgumentType.STRING argument. This option can be used with a file

load-data option. ¶

This is the “loads auxiliary data” option. This option takes a ArgumentType.STRING argument. This option can be used with a file

password option. ¶

This is the “password to use” option. This option takes a ArgumentType.STRING argument. You can use this option to specify the password in the command line instead of reading it from the tty. Note, that the command line arguments are available for view in others in the system. Specifying password as ” is the same as specifying no password.

null-password option. ¶

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

empty-password option. ¶

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

cprint option. ¶

This is the “in certain operations it prints the information in c-friendly format” option. In certain operations it prints the information in C-friendly format, suitable for including into C programs.

rsa option. ¶

This is the “generate rsa key” option. When combined with –generate-privkey generates an RSA private key.

NOTE: THIS OPTION IS DEPRECATED

dsa option. ¶

This is the “generate dsa key” option. When combined with –generate-privkey generates a DSA private key.

NOTE: THIS OPTION IS DEPRECATED

ecc option. ¶

This is the “generate ecc (ecdsa) key” option. When combined with –generate-privkey generates an elliptic curve private key to be used with ECDSA.

NOTE: THIS OPTION IS DEPRECATED

ecdsa option. ¶

This is an alias for the ecc option, see the ecc option documentation.

hash option. ¶

This is the “hash algorithm to use for signing” option. This option takes a ArgumentType.STRING argument. Available hash functions are SHA1, RMD160, SHA256, SHA384, SHA512, SHA3-224, SHA3-256, SHA3-384, SHA3-512.

salt-size option. ¶

This is the “specify the rsa-pss key default salt size” option. This option takes a ArgumentType.NUMBER argument. Typical keys shouldn’t set or restrict this option.

label option. ¶

This is the “specify the rsa-oaep label, encoded in hexadecimal” option. This option takes a ArgumentType.STRING argument. Typical keys shouldn’t set or restrict this option.

inder option. ¶

This is the “use der format for input certificates, private keys, and dh parameters ” option. 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 option. ¶

This is an alias for the inder option, see the inder option documentation.

outder option. ¶

This is the “use der format for output certificates, private keys, and dh parameters” option. The output will be in DER or RAW format.

outraw option. ¶

This is an alias for the outder option, see the outder option documentation.

ask-pass option. ¶

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

pkcs-cipher option. ¶

This is the “cipher to use for pkcs #8 and #12 operations” option. This option takes a ArgumentType.STRING argument Cipher. Cipher may be one of 3des, 3des-pkcs12, aes-128, aes-192, aes-256, rc2-40, arcfour.

provider option. ¶

This is the “specify the pkcs #11 provider library” option. This option takes a ArgumentType.STRING argument. This will override the default options in /etc/gnutls/pkcs11.conf

text option. ¶

This is the “output textual information before pem-encoded certificates, private keys, etc” option.

This option has some usage constraints. It:

• can be disabled with –no-text.
• It is enabled by default.

Output textual information before PEM-encoded data

version option (-v). ¶

This is the “output version information and exit” option. This option takes a ArgumentType.KEYWORD argument. 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.

help option (-h). ¶

This is the “display extended usage information and exit” option. Display usage information and exit.

more-help option (-!). ¶

This is the “extended usage information passed thru pager” option. Pass the extended usage information through a pager.

certtool exit status ¶

One of the following exit values will be returned:

‘0 (EXIT_SUCCESS)’

Successful program execution.

‘1 (EXIT_FAILURE)’

The operation failed or the command syntax was not valid.

certtool See Also ¶

p11tool (1), psktool (1), srptool (1)

certtool Examples ¶

Generating private keys ¶

To create an RSA private key, run:

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

To create a DSA or elliptic curves (ECDSA) private key use the above command combined with ’dsa’ or ’ecc’ options.

Generating certificate requests ¶

To create a certificate request (needed when the certificate is issued by another party), run:

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

If the private key is stored in a smart card you can generate a request by specifying the private key object URL.

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

Generating a self-signed certificate ¶

To create a self signed certificate, use the command:

$ certtool --generate-privkey --outfile ca-key.pem
$ certtool --generate-self-signed --load-privkey ca-key.pem \
   --outfile ca-cert.pem

Note that a self-signed certificate usually belongs to a certificate authority, that signs other certificates.

Generating a certificate ¶

To generate a certificate using the previous request, use the command:

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

To generate a certificate using the private key only, use the command:

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

Certificate information ¶

To view the certificate information, use:

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

Changing the certificate format ¶

To convert the certificate from PEM to DER format, use:

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

PKCS #12 structure generation ¶

To generate a PKCS #12 structure using the previous key and certificate, use the command:

$ certtool --load-certificate cert.pem --load-privkey key.pem \
   --to-p12 --outder --outfile key.p12

Some tools (reportedly web browsers) have problems with that file because it does not contain the CA certificate for the certificate. To work around that problem in the tool, you can use the –load-ca-certificate parameter as follows:

$ certtool --load-ca-certificate ca.pem \
  --load-certificate cert.pem --load-privkey key.pem \
  --to-p12 --outder --outfile key.p12

Obtaining Diffie-Hellman parameters ¶

To obtain the RFC7919 parameters for Diffie-Hellman key exchange, use the command:

$ 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 use the following command:

$ certtool --verify --infile cert.pem

It is also possible to simulate hostname verification with the following options:

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

Proxy certificate generation ¶

Proxy certificate can be used to delegate your credential to a temporary, typically short-lived, certificate. To create one from the previously created certificate, first create a temporary key and then generate a proxy certificate for it, using the commands:

$ 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

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

To create a CRL that contains some revoked certificates, place the certificates in a file and use --load-certificate as follows:

$ 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

certtool 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"

4.2.7 Invoking ocsptool ¶

On verification ¶

Responses are typically signed/issued by designated certificates or certificate authorities and thus this tool requires on verification the certificate of the issuer or the full certificate chain in order to determine the appropriate signing authority. The specified certificate of the issuer is assumed trusted.

ocsptool help/usage (-?) ¶

The text printed is the same whether selected with the help option (--help) or the more-help option (--more-help). more-help will print the usage text by passing it through a pager program. more-help is disabled on platforms without a working fork(2) function. The PAGER environment variable is used to select the program, defaulting to more. Both will exit with a status code of 0.

ocsptool - GnuTLS OCSP tool
Usage:  ocsptool [ -<flag> [<val>] | --<name>[{=| }<val>] ]... 

None:

   -d, --debug=num            Enable debugging
				- it must be in the range:
				  0 to 9999
   -V, --verbose              More verbose output
       --infile=file          Input file
				- file must pre-exist
       --outfile=str          Output file
       --ask[=str]            Ask an OCSP/HTTP server on a certificate validity
   -e, --verify-response      Verify response
   -i, --request-info         Print information on a OCSP request
   -j, --response-info        Print information on a OCSP response
   -q, --generate-request     Generates an OCSP request
       --nonce                Use (or not) a nonce to OCSP request
       --load-chain=file      Reads a set of certificates forming a chain from file
				- file must pre-exist
       --load-issuer=file     Reads issuer's certificate from file
				- file must pre-exist
       --load-cert=file       Reads the certificate to check from file
				- file must pre-exist
       --load-trust=file      Read OCSP trust anchors from file
				- prohibits the option 'load-signer'
				- file must pre-exist
       --load-signer=file     Reads the OCSP response signer from file
				- prohibits the option 'load-trust'
				- file must pre-exist
       --inder                Use DER format for input certificates and private keys
       --outder               Use DER format for output of responses (this is the default)
       --outpem               Use PEM format for output of responses
   -Q, --load-request=file    Reads the DER encoded OCSP request from file
				- file must pre-exist
   -S, --load-response=file   Reads the DER encoded OCSP response from file
				- file must pre-exist
       --ignore-errors        Ignore any verification errors
       --verify-allow-broken  Allow broken algorithms, such as MD5 for verification
       --attime=str           Perform validation at the timestamp instead of the system time

Version, usage and configuration options:

   -v, --version[=arg]        output version information and exit
   -h, --help                 display extended usage information and exit
   -!, --more-help            extended usage information passed thru pager

Options are specified by doubled hyphens and their name or by a single
hyphen and the flag character.

ocsptool is a program that can parse and print information about
OCSP requests/responses, generate requests and verify responses. Unlike
other GnuTLS applications it outputs DER encoded structures by default
unless the '--outpem' option is specified.

Please send bug reports to:  <bugs@gnutls.org>

debug option (-d). ¶

This is the “enable debugging” option. This option takes a ArgumentType.NUMBER argument. Specifies the debug level.

ask option. ¶

This is the “ask an ocsp/http server on a certificate validity” option. This option takes a ArgumentType.STRING argument server name|url. Connects to the specified HTTP OCSP server and queries on the validity of the loaded certificate. Its argument can be a URL or a plain server name. It can be combined with –load-chain, where it checks all certificates in the provided chain, or with –load-cert and –load-issuer options. The latter checks the provided certificate against its specified issuer certificate.

verify-response option (-e). ¶

This is the “verify response” option. Verifies the provided OCSP response against the system trust anchors (unless –load-trust is provided). It requires the –load-signer or –load-chain options to obtain the signer of the OCSP response.

request-info option (-i). ¶

This is the “print information on a ocsp request” option. Display detailed information on the provided OCSP request.

response-info option (-j). ¶

This is the “print information on a ocsp response” option. Display detailed information on the provided OCSP response.

load-trust option. ¶

This is the “read ocsp trust anchors from file” option. This option takes a ArgumentType.FILE argument.

This option has some usage constraints. It:

• must not appear in combination with any of the following options: load-signer.

When verifying an OCSP response read the trust anchors from the provided file. When this is not provided, the system’s trust anchors will be used.

outder option. ¶

This is the “use der format for output of responses (this is the default)” option. The output will be in DER encoded format. Unlike other GnuTLS tools, this is the default for this tool

outpem option. ¶

This is the “use pem format for output of responses” option. The output will be in PEM format.

verify-allow-broken option. ¶

This is the “allow broken algorithms, such as md5 for verification” option. This can be combined with –verify-response.

attime option. ¶

This is the “perform validation at the timestamp instead of the system time” option. This option takes a ArgumentType.STRING argument timestamp. 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 available at <https://www.gnu.org/software/coreutils/manual/html_node/Date-input-formats.html> or locally via info ’(coreutils) date invocation’.

version option (-v). ¶

This is the “output version information and exit” option. This option takes a ArgumentType.KEYWORD argument. 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.

help option (-h). ¶

This is the “display extended usage information and exit” option. Display usage information and exit.

more-help option (-!). ¶

This is the “extended usage information passed thru pager” option. Pass the extended usage information through a pager.

ocsptool exit status ¶

One of the following exit values will be returned:

‘0 (EXIT_SUCCESS)’

Successful program execution.

‘1 (EXIT_FAILURE)’

The operation failed or the command syntax was not valid.

ocsptool See Also ¶

certtool (1)

ocsptool Examples ¶

Print information about an OCSP request ¶

To parse an OCSP request and print information about the content, the -i or --request-info parameter may be used as follows. The -Q parameter specify the name of the file containing the OCSP request, and it should contain the OCSP request in binary DER format.

$ ocsptool -i -Q ocsp-request.der

The input file may also be sent to standard input like this:

$ cat ocsp-request.der | ocsptool --request-info

Print information about an OCSP response ¶

Similar to parsing OCSP requests, OCSP responses can be parsed using the -j or --response-info as follows.

$ ocsptool -j -Q ocsp-response.der
$ cat ocsp-response.der | ocsptool --response-info

Generate an OCSP request ¶

The -q or --generate-request parameters are used to generate an OCSP request. By default the OCSP request is written to standard output in binary DER format, but can be stored in a file using --outfile. To generate an OCSP request the issuer of the certificate to check needs to be specified with --load-issuer and the certificate to check with --load-cert. By default PEM format is used for these files, although --inder can be used to specify that the input files are in DER format.

$ ocsptool -q --load-issuer issuer.pem --load-cert client.pem \
           --outfile ocsp-request.der

When generating OCSP requests, the tool will add an OCSP extension containing a nonce. This behaviour can be disabled by specifying --no-nonce.

Verify signature in OCSP response ¶

To verify the signature in an OCSP response the -e or --verify-response parameter is used. The tool will read an OCSP response in DER format from standard input, or from the file specified by --load-response. The OCSP response is verified against a set of trust anchors, which are specified using --load-trust. The trust anchors are concatenated certificates in PEM format. The certificate that signed the OCSP response needs to be in the set of trust anchors, or the issuer of the signer certificate needs to be in the set of trust anchors and the OCSP Extended Key Usage bit has to be asserted in the signer certificate.

$ ocsptool -e --load-trust issuer.pem \
           --load-response ocsp-response.der

The tool will print status of verification.

Verify signature in OCSP response against given certificate ¶

It is possible to override the normal trust logic if you know that a certain certificate is supposed to have signed the OCSP response, and you want to use it to check the signature. This is achieved using --load-signer instead of --load-trust. This will load one certificate and it will be used to verify the signature in the OCSP response. It will not check the Extended Key Usage bit.

$ ocsptool -e --load-signer ocsp-signer.pem \
           --load-response ocsp-response.der

This approach is normally only relevant in two situations. The first is when the OCSP response does not contain a copy of the signer certificate, so the --load-trust code would fail. The second is if you want to avoid the indirect mode where the OCSP response signer certificate is signed by a trust anchor.

Real-world example ¶

Here is an example of how to generate an OCSP request for a certificate and to verify the response. For illustration we’ll use the blog.josefsson.org host, which (as of writing) uses a certificate from CACert. First we’ll use gnutls-cli to get a copy of the server certificate chain. The server is not required to send this information, but this particular one is configured to do so.

$ echo | gnutls-cli -p 443 blog.josefsson.org --save-cert chain.pem

The saved certificates normally contain a pointer to where the OCSP responder is located, in the Authority Information Access Information extension. For example, from certtool -i < chain.pem there is this information:

		Authority Information Access Information (not critical):
			Access Method: 1.3.6.1.5.5.7.48.1 (id-ad-ocsp)
			Access Location URI: https://ocsp.CAcert.org/

This means that ocsptool can discover the servers to contact over HTTP. We can now request information on the chain certificates.

$ ocsptool --ask --load-chain chain.pem

The request is sent via HTTP to the OCSP server address found in the certificates. It is possible to override the address of the OCSP server as well as ask information on a particular certificate using –load-cert and –load-issuer.

$ ocsptool --ask https://ocsp.CAcert.org/ --load-chain chain.pem

4.2.8 Invoking danetool ¶

Tool to generate and check DNS resource records for the DANE protocol.

danetool help/usage (-?) ¶

The text printed is the same whether selected with the help option (--help) or the more-help option (--more-help). more-help will print the usage text by passing it through a pager program. more-help is disabled on platforms without a working fork(2) function. The PAGER environment variable is used to select the program, defaulting to more. Both will exit with a status code of 0.

danetool - GnuTLS DANE tool
Usage:  danetool [ -<flag> [<val>] | --<name>[{=| }<val>] ]... 

None:

   -d, --debug=num            Enable debugging
				- it must be in the range:
				  0 to 9999
   -V, --verbose              More verbose output
       --outfile=str          Output file
       --load-pubkey=str      Loads a public key file
       --load-certificate=str Loads a certificate file
       --dlv=str              Sets a DLV file
       --hash=str             Hash algorithm to use for signing
       --check=str            Check a host's DANE TLSA entry
       --check-ee             Check only the end-entity's certificate
       --check-ca             Check only the CA's certificate
       --tlsa-rr              Print the DANE RR data on a certificate or public key
				- requires the option 'host'
       --host=str             Specify the hostname to be used in the DANE RR
       --proto=str            The protocol set for DANE data (tcp, udp etc.)
       --port=str             The port or service to connect to, for DANE data
       --app-proto            an alias for the 'starttls-proto' option
       --starttls-proto=str   The application protocol to be used to obtain the server's certificate (https, ftp, smtp, imap, ldap, xmpp, lmtp, pop3, nntp, sieve, postgres)
       --ca                   Whether the provided certificate or public key is a Certificate Authority
       --x509                 Use the hash of the X.509 certificate, rather than the public key
       --local                an alias for the 'domain' option
       --domain               The provided certificate or public key is issued by the local domain
				- enabled by default
				- disabled as '--no-domain'
       --local-dns            Use the local DNS server for DNSSEC resolving
       --insecure             Do not verify any DNSSEC signature
       --inder                Use DER format for input certificates and private keys
       --inraw                an alias for the 'inder' option
       --print-raw            Print the received DANE data in raw format
       --quiet                Suppress several informational messages

Version, usage and configuration options:

   -v, --version[=arg]        output version information and exit
   -h, --help                 display extended usage information and exit
   -!, --more-help            extended usage information passed thru pager

Options are specified by doubled hyphens and their name or by a single
hyphen and the flag character.

Tool to generate and check DNS resource records for the DANE protocol.

Please send bug reports to:  <bugs@gnutls.org>

debug option (-d). ¶

This is the “enable debugging” option. This option takes a ArgumentType.NUMBER argument. Specifies the debug level.

load-pubkey option. ¶

This is the “loads a public key file” option. This option takes a ArgumentType.STRING argument. This can be either a file or a PKCS #11 URL

load-certificate option. ¶

This is the “loads a certificate file” option. This option takes a ArgumentType.STRING argument. This can be either a file or a PKCS #11 URL

dlv option. ¶

This is the “sets a dlv file” option. This option takes a ArgumentType.STRING argument. This sets a DLV file to be used for DNSSEC verification.

hash option. ¶

This is the “hash algorithm to use for signing” option. This option takes a ArgumentType.STRING argument. Available hash functions are SHA1, RMD160, SHA256, SHA384, SHA512.

check option. ¶

This is the “check a host’s dane tlsa entry” option. This option takes a ArgumentType.STRING argument. Obtains the DANE TLSA entry from the given hostname and prints information. Note that the actual certificate of the host can be provided using –load-certificate, otherwise danetool will connect to the server to obtain it. The exit code on verification success will be zero.

check-ee option. ¶

This is the “check only the end-entity’s certificate” option. Checks the end-entity’s certificate only. Trust anchors or CAs are not considered.

check-ca option. ¶

This is the “check only the ca’s certificate” option. Checks the trust anchor’s and CA’s certificate only. End-entities are not considered.

tlsa-rr option. ¶

This is the “print the dane rr data on a certificate or public key” option.

This option has some usage constraints. It:

• must appear in combination with the following options: host.

This command prints the DANE RR data needed to enable DANE on a DNS server.

host option. ¶

This is the “specify the hostname to be used in the dane rr” option. This option takes a ArgumentType.STRING argument Hostname. This command sets the hostname for the DANE RR.

proto option. ¶

This is the “the protocol set for dane data (tcp, udp etc.)” option. This option takes a ArgumentType.STRING argument Protocol. This command specifies the protocol for the service set in the DANE data.

app-proto option. ¶

This is an alias for the starttls-proto option, see the starttls-proto option documentation.

starttls-proto option. ¶

This is the “the application protocol to be used to obtain the server’s certificate (https, ftp, smtp, imap, ldap, xmpp, lmtp, pop3, nntp, sieve, postgres)” option. This option takes a ArgumentType.STRING argument. When the server’s certificate isn’t provided danetool will connect to the server to obtain the certificate. In that case it is required to know the protocol to talk with the server prior to initiating the TLS handshake.

ca option. ¶

This is the “whether the provided certificate or public key is a certificate authority” option. Marks the DANE RR as a CA certificate if specified.

x509 option. ¶

This is the “use the hash of the x.509 certificate, rather than the public key” option. This option forces the generated record to contain the hash of the full X.509 certificate. By default only the hash of the public key is used.

local option. ¶

This is an alias for the domain option, see the domain option documentation.

domain option. ¶

This is the “the provided certificate or public key is issued by the local domain” option.

This option has some usage constraints. It:

• can be disabled with –no-domain.
• It is enabled by default.

DANE distinguishes certificates and public keys offered via the DNSSEC to trusted and local entities. This flag indicates that this is a domain-issued certificate, meaning that there could be no CA involved.

local-dns option. ¶

This is the “use the local dns server for dnssec resolving” option. This option will use the local DNS server for DNSSEC. This is disabled by default due to many servers not allowing DNSSEC.

insecure option. ¶

This is the “do not verify any dnssec signature” option. Ignores any DNSSEC signature verification results.

inder option. ¶

This is the “use der format for input certificates and private keys” option. 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 option. ¶

This is an alias for the inder option, see the inder option documentation.

print-raw option. ¶

This is the “print the received dane data in raw format” option. This option will print the received DANE data.

quiet option. ¶

This is the “suppress several informational messages” option. In that case on the exit code can be used as an indication of verification success

version option (-v). ¶

This is the “output version information and exit” option. This option takes a ArgumentType.KEYWORD argument. 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.

help option (-h). ¶

This is the “display extended usage information and exit” option. Display usage information and exit.

more-help option (-!). ¶

This is the “extended usage information passed thru pager” option. Pass the extended usage information through a pager.

danetool exit status ¶

One of the following exit values will be returned:

‘0 (EXIT_SUCCESS)’

Successful program execution.

‘1 (EXIT_FAILURE)’

The operation failed or the command syntax was not valid.

danetool See Also ¶

certtool (1)

danetool Examples ¶

DANE TLSA RR generation ¶

To create a DANE TLSA resource record for a certificate (or public key) that was issued locally and may or may not be signed by a CA use the following command.

$ danetool --tlsa-rr --host www.example.com --load-certificate cert.pem

To create a DANE TLSA resource record for a CA signed certificate, which will be marked as such use the following command.

$ danetool --tlsa-rr --host www.example.com --load-certificate cert.pem \
  --no-domain

The former is useful to add in your DNS entry even if your certificate is signed by a CA. That way even users who do not trust your CA will be able to verify your certificate using DANE.

In order to create a record for the CA signer of your certificate use the following.

$ danetool --tlsa-rr --host www.example.com --load-certificate cert.pem \
  --ca --no-domain

To read a server’s DANE TLSA entry, use:

$ danetool --check www.example.com --proto tcp --port 443

To verify an HTTPS server’s DANE TLSA entry, use:

$ danetool --check www.example.com --proto tcp --port 443 --load-certificate chain.pem

To verify an SMTP server’s DANE TLSA entry, use:

$ danetool --check www.example.com --proto tcp --starttls-proto=smtp --load-certificate chain.pem

4.3.1 PSK authentication ¶

• Authentication using PSK
• Invoking psktool

psktool - GnuTLS PSK tool
Usage:  psktool [ -<flag> [<val>] | --<name>[{=| }<val>] ]... 

None:

   -d, --debug=num            Enable debugging
				- it must be in the range:
				  0 to 9999
   -s, --keysize=num          Specify the key size in bytes (default is 32-bytes or 256-bits)
				- it must be in the range:
				  0 to 512
   -u, --username=str         Specify the username to use
   -p, --pskfile=str          Specify a pre-shared key file

Version, usage and configuration options:

   -v, --version[=arg]        output version information and exit
   -h, --help                 display extended usage information and exit
   -!, --more-help            extended usage information passed thru pager

Options are specified by doubled hyphens and their name or by a single
hyphen and the flag character.

Program  that generates random keys for use with TLS-PSK. The
keys are stored in hexadecimal format in a key file.

Please send bug reports to:  <bugs@gnutls.org>

$ ./psktool -u psk_identity -p keys.psk
Generating a random key for user 'psk_identity'
Key stored to keys.psk
$ cat keys.psk
psk_identity:88f3824b3e5659f52d00e959bacab954b6540344
$

4.3.2 SRP authentication ¶

• Authentication using SRP
• Invoking srptool

srptool - GnuTLS SRP tool
Usage:  srptool [ -<flag> [<val>] | --<name>[{=| }<val>] ]... 

None:

   -d, --debug=num            Enable debugging
				- it must be in the range:
				  0 to 9999
   -i, --index=num            specify the index of the group parameters in tpasswd.conf to use
   -u, --username=str         specify a username
   -p, --passwd=str           specify a password file
   -s, --salt=num             specify salt size
       --verify               just verify the password
   -v, --passwd-conf=str      specify a password conf file
       --create-conf=str      Generate a password configuration file

Version, usage and configuration options:

   -v, --version[=arg]        output version information and exit
   -h, --help                 display extended usage information and exit
   -!, --more-help            extended usage information passed thru pager

Options are specified by doubled hyphens and their name or by a single
hyphen and the flag character.

Simple program that emulates the programs in the Stanford SRP (Secure
Remote Password) libraries using GnuTLS.  It is intended for use in  places
where you don't expect SRP authentication to be the used for system users.

In  brief,  to use SRP you need to create two files. These are the password
file that holds the users and the verifiers associated with  them  and  the
configuration file to hold the group parameters (called tpasswd.conf).

Please send bug reports to:  <bugs@gnutls.org>

$ srptool --create-conf /etc/tpasswd.conf

$ srptool --passwd /etc/tpasswd --passwd-conf /etc/tpasswd.conf -u test

$ srptool --passwd /etc/tpasswd --passwd\-conf /etc/tpasswd.conf --verify -u test

4.3.3 Anonymous authentication ¶

The anonymous key exchange offers encryption without any indication of the peer’s identity. This kind of authentication is vulnerable to a man in the middle attack, but can be used even if there is no prior communication or shared trusted parties with the peer. It is useful to establish a session over which certificate authentication will occur in order to hide the identities of the participants from passive eavesdroppers. It is only available under TLS 1.2 or earlier versions.

Unless in the above case, it is not recommended to use anonymous authentication. In the cases where there is no prior communication with the peers, an alternative with better properties, such as key continuity, is trust on first use (see Verifying a certificate using trust on first use authentication).

The available key exchange algorithms for anonymous authentication are shown below, but note that few public servers support them, and they have to be explicitly enabled. These ciphersuites are negotiated only under TLS 1.2.

ANON_DH:

This algorithm exchanges Diffie-Hellman parameters.

ANON_ECDH:

This algorithm exchanges elliptic curve Diffie-Hellman parameters. It is more efficient than ANON_DH on equivalent security levels.

4.4.1 Two peers with an out-of-band channel ¶

Let’s consider two peers who need to communicate over an untrusted channel (the Internet), but have an out-of-band channel available. The latter channel is considered safe from eavesdropping and message modification and thus can be used for an initial bootstrapping of the protocol. The options available are:

• Pre-shared keys (see PSK authentication). The server and a client communicate a shared randomly generated key over the trusted channel and use it to negotiate further sessions over the untrusted channel.
• Passwords (see SRP authentication). The client communicates to the server its username and password of choice and uses it to negotiate further sessions over the untrusted channel.
• Public keys (see Certificate authentication). The client and the server exchange their public keys (or fingerprints of them) over the trusted channel. On future sessions over the untrusted channel they verify the key being the same (similar to Verifying a certificate using trust on first use authentication).

Provided that the out-of-band channel is trusted all of the above provide a similar level of protection. An out-of-band channel may be the initial bootstrapping of a user’s PC in a corporate environment, in-person communication, communication over an alternative network (e.g. the phone network), etc.

4.4.2 Two peers without an out-of-band channel ¶

When an out-of-band channel is not available a peer cannot be reliably authenticated. What can be done, however, is to allow some form of registration of users connecting for the first time and ensure that their keys remain the same after that initial connection. This is termed key continuity or trust on first use (TOFU).

The available option is to use public key authentication (see Certificate authentication). The client and the server store each other’s public keys (or fingerprints of them) and associate them with their identity. On future sessions over the untrusted channel they verify the keys being the same (see Verifying a certificate using trust on first use authentication).

To mitigate the uncertainty of the information exchanged in the first connection other channels over the Internet may be used, e.g., DNSSEC (see Verifying a certificate using DANE (DNSSEC)).

4.4.3 Two peers and a trusted third party ¶

When a trusted third party is available (or a certificate authority) the most suitable option is to use certificate authentication (see Certificate authentication). The client and the server obtain certificates that associate their identity and public keys using a digital signature by the trusted party and use them to on the subsequent communications with each other. Each party verifies the peer’s certificate using the trusted third party’s signature. The parameters of the third party’s signature are present in its certificate which must be available to all communicating parties.

While the above is the typical authentication method for servers in the Internet by using the commercial CAs, the users that act as clients in the protocol rarely possess such certificates. In that case a hybrid method can be used where the server is authenticated by the client using the commercial CAs and the client is authenticated based on some information the client provided over the initial server-authenticated channel. The available options are:

• Passwords (see SRP authentication). The client communicates to the server its username and password of choice on the initial server-authenticated connection and uses it to negotiate further sessions. This is possible because the SRP protocol allows for the server to be authenticated using a certificate and the client using the password.
• Public keys (see Certificate authentication). The client sends its public key to the server (or a fingerprint of it) over the initial server-authenticated connection. On future sessions the client verifies the server using the third party certificate and the server verifies that the client’s public key remained the same (see Verifying a certificate using trust on first use authentication).

5.1.1 Public keys ¶

An abstract gnutls_pubkey_t can be initialized and freed by using the functions below.

int gnutls_pubkey_init (gnutls_pubkey_t * key)

void gnutls_pubkey_deinit (gnutls_pubkey_t key)

After initialization its values can be imported from an existing structure like gnutls_x509_crt_t, or through an ASN.1 encoding of the X.509 SubjectPublicKeyInfo sequence.

int gnutls_pubkey_import_x509 (gnutls_pubkey_t key, gnutls_x509_crt_t crt, unsigned int flags)

int gnutls_pubkey_import_pkcs11 (gnutls_pubkey_t key, gnutls_pkcs11_obj_t obj, unsigned int flags)

int gnutls_pubkey_import_url (gnutls_pubkey_t key, const char * url, unsigned int flags)

int gnutls_pubkey_import_privkey (gnutls_pubkey_t key, gnutls_privkey_t pkey, unsigned int usage, unsigned int flags)

int gnutls_pubkey_import (gnutls_pubkey_t key, const gnutls_datum_t * data, gnutls_x509_crt_fmt_t format)

int gnutls_pubkey_export (gnutls_pubkey_t key, gnutls_x509_crt_fmt_t format, void * output_data, size_t * output_data_size)

Function: int gnutls_pubkey_export2 (gnutls_pubkey_t key, gnutls_x509_crt_fmt_t format, gnutls_datum_t * out) ¶

key: Holds the certificate

format: the format of output params. One of PEM or DER.

out: will contain a certificate PEM or DER encoded

This function will export the public key to DER or PEM format. The contents of the exported data is the SubjectPublicKeyInfo X.509 structure.

The output buffer will be allocated using gnutls_malloc() .

If the structure is PEM encoded, it will have a header of "BEGIN CERTIFICATE".

Returns: In case of failure a negative error code will be returned, and 0 on success.

Since: 3.1.3

Other helper functions that allow directly importing from raw X.509 structures are shown below.

int gnutls_pubkey_import_x509_raw (gnutls_pubkey_t pkey, const gnutls_datum_t * data, gnutls_x509_crt_fmt_t format, unsigned int flags)

An important function is gnutls_pubkey_import_url which will import public keys from URLs that identify objects stored in tokens (see Smart cards and HSMs and Trusted Platform Module (TPM)). A function to check for a supported by GnuTLS URL is gnutls_url_is_supported.

Function: unsigned gnutls_url_is_supported (const char * url) ¶

url: A URI to be tested

Check whether the provided url is supported. Depending on the system libraries GnuTLS may support pkcs11, tpmkey or other URLs.

Returns: return non-zero if the given URL is supported, and zero if it is not known.

Since: 3.1.0

Additional functions are available that will return information over a public key, such as a unique key ID, as well as a function that given a public key fingerprint would provide a memorable sketch.

Note that gnutls_pubkey_get_key_id calculates a SHA1 digest of the public key as a DER-formatted, subjectPublicKeyInfo object. Other implementations use different approaches, e.g., some use the “common method” described in section 4.2.1.2 of [RFC5280] which calculates a digest on a part of the subjectPublicKeyInfo object.

int gnutls_pubkey_get_pk_algorithm (gnutls_pubkey_t key, unsigned int * bits)

int gnutls_pubkey_get_preferred_hash_algorithm (gnutls_pubkey_t key, gnutls_digest_algorithm_t * hash, unsigned int * mand)

int gnutls_pubkey_get_key_id (gnutls_pubkey_t key, unsigned int flags, unsigned char * output_data, size_t * output_data_size)

int gnutls_random_art (gnutls_random_art_t type, const char * key_type, unsigned int key_size, void * fpr, size_t fpr_size, gnutls_datum_t * art)

To export the key-specific parameters, or obtain a unique key ID the following functions are provided.

int gnutls_pubkey_export_rsa_raw2 (gnutls_pubkey_t key, gnutls_datum_t * m, gnutls_datum_t * e, unsigned flags)

int gnutls_pubkey_export_dsa_raw2 (gnutls_pubkey_t key, gnutls_datum_t * p, gnutls_datum_t * q, gnutls_datum_t * g, gnutls_datum_t * y, unsigned flags)

int gnutls_pubkey_export_ecc_raw2 (gnutls_pubkey_t key, gnutls_ecc_curve_t * curve, gnutls_datum_t * x, gnutls_datum_t * y, unsigned int flags)

int gnutls_pubkey_export_ecc_x962 (gnutls_pubkey_t key, gnutls_datum_t * parameters, gnutls_datum_t * ecpoint)

5.1.2 Private keys ¶

An abstract gnutls_privkey_t can be initialized and freed by using the functions below.

int gnutls_privkey_init (gnutls_privkey_t * key)

void gnutls_privkey_deinit (gnutls_privkey_t key)

After initialization its values can be imported from an existing structure like gnutls_x509_privkey_t, but unlike public keys it cannot be exported. That is to allow abstraction over keys stored in hardware that makes available only operations.

int gnutls_privkey_import_x509 (gnutls_privkey_t pkey, gnutls_x509_privkey_t key, unsigned int flags)

int gnutls_privkey_import_pkcs11 (gnutls_privkey_t pkey, gnutls_pkcs11_privkey_t key, unsigned int flags)

Other helper functions that allow directly importing from raw X.509 structures are shown below. Again, as with public keys, private keys can be imported from a hardware module using URLs.

Function: int gnutls_privkey_import_url (gnutls_privkey_t key, const char * url, unsigned int flags) ¶

key: A key of type gnutls_privkey_t

url: A PKCS 11 url

flags: should be zero

This function will import a PKCS11 or TPM URL as a private key. The supported URL types can be checked using gnutls_url_is_supported() .

Returns: On success, GNUTLS_E_SUCCESS (0) is returned, otherwise a negative error value.

Since: 3.1.0

int gnutls_privkey_import_x509_raw (gnutls_privkey_t pkey, const gnutls_datum_t * data, gnutls_x509_crt_fmt_t format, const char * password, unsigned int flags)

int gnutls_privkey_get_pk_algorithm (gnutls_privkey_t key, unsigned int * bits)

gnutls_privkey_type_t gnutls_privkey_get_type (gnutls_privkey_t key)

int gnutls_privkey_status (gnutls_privkey_t key)

In order to support cryptographic operations using an external API, the following function is provided. This allows for a simple extensibility API without resorting to PKCS #11.

Function: int gnutls_privkey_import_ext4 (gnutls_privkey_t pkey, void * userdata, gnutls_privkey_sign_data_func sign_data_fn, gnutls_privkey_sign_hash_func sign_hash_fn, gnutls_privkey_decrypt_func decrypt_fn, gnutls_privkey_deinit_func deinit_fn, gnutls_privkey_info_func info_fn, unsigned int flags) ¶

pkey: The private key

userdata: private data to be provided to the callbacks

sign_data_fn: callback for signature operations (may be NULL )

sign_hash_fn: callback for signature operations (may be NULL )

decrypt_fn: callback for decryption operations (may be NULL )

deinit_fn: a deinitialization function

info_fn: returns info about the public key algorithm (should not be NULL )

flags: Flags for the import

This function will associate the given callbacks with the gnutls_privkey_t type. At least one of the callbacks must be non-null. If a deinitialization function is provided then flags is assumed to contain GNUTLS_PRIVKEY_IMPORT_AUTO_RELEASE .

Note that in contrast with the signing function of gnutls_privkey_import_ext3() , the signing functions provided to this function take explicitly the signature algorithm as parameter and different functions are provided to sign the data and hashes.

The sign_hash_fn is to be called to sign pre-hashed data. The input to the callback is the output of the hash (such as SHA256) corresponding to the signature algorithm. For RSA PKCS1 signatures, the signature algorithm can be set to GNUTLS_SIGN_RSA_RAW , and in that case the data should be handled as if they were an RSA PKCS1 DigestInfo structure.

The sign_data_fn is to be called to sign data. The input data will be he data to be signed (and hashed), with the provided signature algorithm. This function is to be used for signature algorithms like Ed25519 which cannot take pre-hashed data as input.

When both sign_data_fn and sign_hash_fn functions are provided they must be able to operate on all the supported signature algorithms, unless prohibited by the type of the algorithm (e.g., as with Ed25519).

The info_fn must provide information on the signature algorithms supported by this private key, and should support the flags GNUTLS_PRIVKEY_INFO_PK_ALGO , GNUTLS_PRIVKEY_INFO_HAVE_SIGN_ALGO and GNUTLS_PRIVKEY_INFO_PK_ALGO_BITS . It must return -1 on unknown flags.

Returns: On success, GNUTLS_E_SUCCESS (0) is returned, otherwise a negative error value.

Since: 3.6.0

On the private keys where exporting of parameters is possible (i.e., software keys), the following functions are also available.

int gnutls_privkey_export_rsa_raw2 (gnutls_privkey_t key, gnutls_datum_t * m, gnutls_datum_t * e, gnutls_datum_t * d, gnutls_datum_t * p, gnutls_datum_t * q, gnutls_datum_t * u, gnutls_datum_t * e1, gnutls_datum_t * e2, unsigned int flags)

int gnutls_privkey_export_dsa_raw2 (gnutls_privkey_t key, gnutls_datum_t * p, gnutls_datum_t * q, gnutls_datum_t * g, gnutls_datum_t * y, gnutls_datum_t * x, unsigned int flags)

int gnutls_privkey_export_ecc_raw2 (gnutls_privkey_t key, gnutls_ecc_curve_t * curve, gnutls_datum_t * x, gnutls_datum_t * y, gnutls_datum_t * k, unsigned int flags)

5.1.3 Operations ¶

The abstract key types can be used to access signing and signature verification operations with the underlying keys.

Function: int gnutls_pubkey_verify_data2 (gnutls_pubkey_t pubkey, gnutls_sign_algorithm_t algo, unsigned int flags, const gnutls_datum_t * data, const gnutls_datum_t * signature) ¶

pubkey: Holds the public key

algo: The signature algorithm used

flags: Zero or an OR list of gnutls_certificate_verify_flags

data: holds the signed data

signature: contains the signature

This function will verify the given signed data, using the parameters from the certificate.

Returns: In case of a verification failure GNUTLS_E_PK_SIG_VERIFY_FAILED is returned, and zero or positive code on success. For known to be insecure signatures this function will return GNUTLS_E_INSUFFICIENT_SECURITY unless the flag GNUTLS_VERIFY_ALLOW_BROKEN is specified.

Since: 3.0

Function: int gnutls_pubkey_verify_hash2 (gnutls_pubkey_t key, gnutls_sign_algorithm_t algo, unsigned int flags, const gnutls_datum_t * hash, const gnutls_datum_t * signature) ¶

key: Holds the public key

algo: The signature algorithm used

flags: Zero or an OR list of gnutls_certificate_verify_flags

hash: holds the hash digest to be verified

signature: contains the signature

This function will verify the given signed digest, using the parameters from the public key. Note that unlike gnutls_privkey_sign_hash() , this function accepts a signature algorithm instead of a digest algorithm. You can use gnutls_pk_to_sign() to get the appropriate value.

Returns: In case of a verification failure GNUTLS_E_PK_SIG_VERIFY_FAILED is returned, and zero or positive code on success. For known to be insecure signatures this function will return GNUTLS_E_INSUFFICIENT_SECURITY unless the flag GNUTLS_VERIFY_ALLOW_BROKEN is specified.

Since: 3.0

Function: int gnutls_pubkey_encrypt_data (gnutls_pubkey_t key, unsigned int flags, const gnutls_datum_t * plaintext, gnutls_datum_t * ciphertext) ¶

key: Holds the public key

flags: should be 0 for now

plaintext: The data to be encrypted

ciphertext: contains the encrypted data

This function will encrypt the given data, using the public key. On success the ciphertext will be allocated using gnutls_malloc() .

Returns: On success, GNUTLS_E_SUCCESS (0) is returned, otherwise a negative error value.

Since: 3.0

Function: int gnutls_privkey_sign_data (gnutls_privkey_t signer, gnutls_digest_algorithm_t hash, unsigned int flags, const gnutls_datum_t * data, gnutls_datum_t * signature) ¶

signer: Holds the key

hash: should be a digest algorithm

flags: Zero or one of gnutls_privkey_flags_t

data: holds the data to be signed

signature: will contain the signature allocated with gnutls_malloc()

This function will sign the given data using a signature algorithm supported by the private key. Signature algorithms are always used together with a hash functions. Different hash functions may be used for the RSA algorithm, but only the SHA family for the DSA keys.

You may use gnutls_pubkey_get_preferred_hash_algorithm() to determine the hash algorithm.

Returns: On success, GNUTLS_E_SUCCESS (0) is returned, otherwise a negative error value.

Since: 2.12.0

Function: int gnutls_privkey_sign_hash (gnutls_privkey_t signer, gnutls_digest_algorithm_t hash_algo, unsigned int flags, const gnutls_datum_t * hash_data, gnutls_datum_t * signature) ¶

signer: Holds the signer’s key

hash_algo: The hash algorithm used

flags: Zero or one of gnutls_privkey_flags_t

hash_data: holds the data to be signed

signature: will contain newly allocated signature

This function will sign the given hashed data using a signature algorithm supported by the private key. Signature algorithms are always used together with a hash functions. Different hash functions may be used for the RSA algorithm, but only SHA-XXX for the DSA keys.

You may use gnutls_pubkey_get_preferred_hash_algorithm() to determine the hash algorithm.

The flags may be GNUTLS_PRIVKEY_SIGN_FLAG_TLS1_RSA or GNUTLS_PRIVKEY_SIGN_FLAG_RSA_PSS . In the former case this function will ignore hash_algo and perform a raw PKCS1 signature, and in the latter an RSA-PSS signature will be generated.

Note that, not all algorithm support signing already hashed data. When signing with Ed25519, gnutls_privkey_sign_data() should be used.

Returns: On success, GNUTLS_E_SUCCESS (0) is returned, otherwise a negative error value.

Since: 2.12.0

Function: int gnutls_privkey_decrypt_data (gnutls_privkey_t key, unsigned int flags, const gnutls_datum_t * ciphertext, gnutls_datum_t * plaintext) ¶

key: Holds the key

flags: zero for now

ciphertext: holds the data to be decrypted

plaintext: will contain the decrypted data, allocated with gnutls_malloc()

This function will decrypt the given data using the algorithm supported by the private key.

Returns: On success, GNUTLS_E_SUCCESS (0) is returned, otherwise a negative error value.

Since: 2.12.0

Signing existing structures, such as certificates, CRLs, or certificate requests, as well as associating public keys with structures is also possible using the key abstractions.

Function: int gnutls_x509_crq_set_pubkey (gnutls_x509_crq_t crq, gnutls_pubkey_t key) ¶

crq: should contain a gnutls_x509_crq_t type

key: holds a public key

This function will set the public parameters from the given public key to the request. The key can be deallocated after that.

Returns: On success, GNUTLS_E_SUCCESS (0) is returned, otherwise a negative error value.

Since: 2.12.0

Function: int gnutls_x509_crt_set_pubkey (gnutls_x509_crt_t crt, gnutls_pubkey_t key) ¶

crt: should contain a gnutls_x509_crt_t type

key: holds a public key

This function will set the public parameters from the given public key to the certificate. The key can be deallocated after that.

Returns: On success, GNUTLS_E_SUCCESS (0) is returned, otherwise a negative error value.

Since: 2.12.0

int gnutls_x509_crt_privkey_sign (gnutls_x509_crt_t crt, gnutls_x509_crt_t issuer, gnutls_privkey_t issuer_key, gnutls_digest_algorithm_t dig, unsigned int flags)

int gnutls_x509_crl_privkey_sign (gnutls_x509_crl_t crl, gnutls_x509_crt_t issuer, gnutls_privkey_t issuer_key, gnutls_digest_algorithm_t dig, unsigned int flags)

int gnutls_x509_crq_privkey_sign (gnutls_x509_crq_t crq, gnutls_privkey_t key, gnutls_digest_algorithm_t dig, unsigned int flags)

5.2.1 System-specific keys ¶

In several systems there are keystores which allow to read, store and use certificates and private keys. For these systems GnuTLS provides the system-key API in gnutls/system-keys.h. That API provides the ability to iterate through all stored keys, add and delete keys as well as use these keys using a URL which starts with "system:". The format of the URLs is system-specific. The systemkey tool is also provided to assist in listing keys and debugging.

The systems supported via this API are the following.

• Windows Cryptography API (CNG)

Function: int gnutls_system_key_iter_get_info (gnutls_system_key_iter_t * iter, unsigned cert_type, char ** cert_url, char ** key_url, char ** label, gnutls_datum_t * der, unsigned int flags) ¶

iter: an iterator of the system keys (must be set to NULL initially)

cert_type: A value of gnutls_certificate_type_t which indicates the type of certificate to look for

cert_url: The certificate URL of the pair (may be NULL )

key_url: The key URL of the pair (may be NULL )

label: The friendly name (if any) of the pair (may be NULL )

der: if non-NULL the DER data of the certificate

flags: should be zero

This function will return on each call a certificate and key pair URLs, as well as a label associated with them, and the DER-encoded certificate. When the iteration is complete it will return GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE .

Typically cert_type should be GNUTLS_CRT_X509 .

All values set are allocated and must be cleared using gnutls_free() ,

Returns: On success, GNUTLS_E_SUCCESS (0) is returned, otherwise a negative error value.

Since: 3.4.0

void gnutls_system_key_iter_deinit (gnutls_system_key_iter_t iter)

int gnutls_system_key_add_x509 (gnutls_x509_crt_t crt, gnutls_x509_privkey_t privkey, const char * label, char ** cert_url, char ** key_url)

int gnutls_system_key_delete (const char * cert_url, const char * key_url)

5.2.2 Application-specific keys ¶

For systems where GnuTLS doesn’t provide a system specific store, it may often be desirable to define a custom class of keys that are identified via URLs and available to GnuTLS calls such as gnutls_certificate_set_x509_key_file2. Such keys can be registered using the API in gnutls/urls.h. The function which registers such keys is gnutls_register_custom_url.

Function: int gnutls_register_custom_url (const gnutls_custom_url_st * st) ¶

st: A gnutls_custom_url_st structure

Register a custom URL. This will affect the following functions: gnutls_url_is_supported() , gnutls_privkey_import_url() , gnutls_pubkey_import_url, gnutls_x509_crt_import_url() and all functions that depend on them, e.g., gnutls_certificate_set_x509_key_file2() .

The provided structure and callback functions must be valid throughout the lifetime of the process. The registration of an existing URL type will fail with GNUTLS_E_INVALID_REQUEST . Since GnuTLS 3.5.0 this function can be used to override the builtin URLs.

This function is not thread safe.

Returns: returns zero if the given structure was imported or a negative value otherwise.

Since: 3.4.0

The input to this function are three callback functions as well as the prefix of the URL, (e.g., "mypkcs11:") and the length of the prefix. The types of the callbacks are shown below, and are expected to use the exported gnutls functions to import the keys and certificates. E.g., a typical import_key callback should use gnutls_privkey_import_ext4.

typedef int (*gnutls_privkey_import_url_func)(gnutls_privkey_t pkey,
                                              const char *url,
                                              unsigned flags);

typedef int (*gnutls_x509_crt_import_url_func)(gnutls_x509_crt_t pkey,
                                               const char *url,
                                               unsigned flags);

/* The following callbacks are optional */

/* This is to enable gnutls_pubkey_import_url() */
typedef int (*gnutls_pubkey_import_url_func)(gnutls_pubkey_t pkey,
					     const char *url, unsigned flags);

/* This is to allow constructing a certificate chain. It will be provided
 * the initial certificate URL and the certificate to find its issuer, and must
 * return zero and the DER encoding of the issuer's certificate. If not available,
 * it should return GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE. */
typedef int (*gnutls_get_raw_issuer_func)(const char *url, gnutls_x509_crt_t crt,
					  gnutls_datum_t *issuer_der, unsigned flags);

typedef struct custom_url_st {
        const char *name;
        unsigned name_size;
        gnutls_privkey_import_url_func import_key;
        gnutls_x509_crt_import_url_func import_crt;
        gnutls_pubkey_import_url_func import_pubkey;
	gnutls_get_raw_issuer_func get_issuer;
} gnutls_custom_url_st;

5.3.1 Initialization ¶

To allow all GnuTLS applications to transparently access smart cards and tokens, PKCS #11 is automatically initialized during the first call of a PKCS #11 related function, in a thread safe way. The default initialization process, utilizes p11-kit configuration, and loads any appropriate PKCS #11 modules. The p11-kit configuration files¹⁰ are typically stored in /etc/pkcs11/modules/. For example a file that will instruct GnuTLS to load the OpenSC module, could be named /etc/pkcs11/modules/opensc.module and contain the following:

module: /usr/lib/opensc-pkcs11.so

If you use these configuration files, then there is no need for other initialization in GnuTLS, except for the PIN and token callbacks (see next section). In several cases, however, it is desirable to limit badly behaving modules (e.g., modules that add an unacceptable delay on initialization) to single applications. That can be done using the “enable-in:” option followed by the base name of applications that this module should be used.

It is also possible to manually initialize or even disable the PKCS #11 subsystem if the default settings are not desirable or not available (see Manual initialization of user-specific modules for more information).

Note that, PKCS #11 modules behave in a peculiar way after a fork; they require a reinitialization of all the used PKCS #11 resources. While GnuTLS automates that process, there are corner cases where it is not possible to handle it correctly in an automated way¹¹. For that, it is recommended not to mix fork() and PKCS #11 module usage. It is recommended to initialize and use any PKCS #11 resources in a single process.

Older versions of GnuTLS required to call gnutls_pkcs11_reinit after a fork() call; since 3.3.0 this is no longer required.

5.3.2 Manual initialization of user-specific modules ¶

In systems where one cannot rely on a globally available p11-kit configuration to be available, it is still possible to utilize PKCS #11 objects. That can be done by loading directly the PKCS #11 shared module in the application using gnutls_pkcs11_add_provider, after having called gnutls_pkcs11_init specifying the GNUTLS_PKCS11_FLAG_MANUAL flag.

Function: int gnutls_pkcs11_add_provider (const char * name, const char * params) ¶

name: The filename of the module

params: should be NULL or a known string (see description)

This function will load and add a PKCS 11 module to the module list used in gnutls. After this function is called the module will be used for PKCS 11 operations.

When loading a module to be used for certificate verification, use the string ’trusted’ as params .

Note that this function is not thread safe.

Returns: On success, GNUTLS_E_SUCCESS (0) is returned, otherwise a negative error value.

Since: 2.12.0

In that case, the application will only have access to the modules explicitly loaded. If the GNUTLS_PKCS11_FLAG_MANUAL flag is specified and no calls to gnutls_pkcs11_add_provider are made, then the PKCS #11 functionality is effectively disabled.

Function: int gnutls_pkcs11_init (unsigned int flags, const char * deprecated_config_file) ¶

flags: An ORed sequence of GNUTLS_PKCS11_FLAG_ *

deprecated_config_file: either NULL or the location of a deprecated configuration file

This function will initialize the PKCS 11 subsystem in gnutls. It will read configuration files if GNUTLS_PKCS11_FLAG_AUTO is used or allow you to independently load PKCS 11 modules using gnutls_pkcs11_add_provider() if GNUTLS_PKCS11_FLAG_MANUAL is specified.

You don’t need to call this function since GnuTLS 3.3.0 because it is being called during the first request PKCS 11 operation. That call will assume the GNUTLS_PKCS11_FLAG_AUTO flag. If another flags are required then it must be called independently prior to any PKCS 11 operation.

Returns: On success, GNUTLS_E_SUCCESS (0) is returned, otherwise a negative error value.

Since: 2.12.0

5.3.3 Accessing objects that require a PIN ¶

Objects stored in token such as a private keys are typically protected from access by a PIN or password. This PIN may be required to either read the object (if allowed) or to perform operations with it. To allow obtaining the PIN when accessing a protected object, as well as probe the user to insert the token the following functions allow to set a callback.

void gnutls_pkcs11_set_token_function (gnutls_pkcs11_token_callback_t fn, void * userdata)

void gnutls_pkcs11_set_pin_function (gnutls_pin_callback_t fn, void * userdata)

int gnutls_pkcs11_add_provider (const char * name, const char * params)

gnutls_pin_callback_t gnutls_pkcs11_get_pin_function (void ** userdata)

The callback is of type gnutls_pin_callback_t and will have as input the provided userdata, the PIN attempt number, a URL describing the token, a label describing the object and flags. The PIN must be at most of pin_max size and must be copied to pin variable. The function must return 0 on success or a negative error code otherwise.

typedef int (*gnutls_pin_callback_t) (void *userdata, int attempt,
                                      const char *token_url,
                                      const char *token_label,
                                      unsigned int flags,
                                      char *pin, size_t pin_max);

The flags are of gnutls_pin_flag_t type and are explained below.

Note that due to limitations of PKCS #11 there are issues when multiple libraries are sharing a module. To avoid this problem GnuTLS uses p11-kit that provides a middleware to control access to resources over the multiple users.

To avoid conflicts with multiple registered callbacks for PIN functions, gnutls_pkcs11_get_pin_function may be used to check for any previously set functions. In addition context specific PIN functions are allowed, e.g., by using functions below.

void gnutls_certificate_set_pin_function (gnutls_certificate_credentials_t cred, gnutls_pin_callback_t fn, void * userdata)

void gnutls_pubkey_set_pin_function (gnutls_pubkey_t key, gnutls_pin_callback_t fn, void * userdata)

void gnutls_privkey_set_pin_function (gnutls_privkey_t key, gnutls_pin_callback_t fn, void * userdata)

void gnutls_pkcs11_obj_set_pin_function (gnutls_pkcs11_obj_t obj, gnutls_pin_callback_t fn, void * userdata)

void gnutls_x509_crt_set_pin_function (gnutls_x509_crt_t crt, gnutls_pin_callback_t fn, void * userdata)

5.3.4 Reading objects ¶

All PKCS #11 objects are referenced by GnuTLS functions by URLs as described in [PKCS11URI]. This allows for a consistent naming of objects across systems and applications in the same system. For example a public key on a smart card may be referenced as:

pkcs11:token=Nikos;serial=307521161601031;model=PKCS%2315; \
manufacturer=EnterSafe;object=test1;type=public;\
id=32f153f3e37990b08624141077ca5dec2d15faed

while the smart card itself can be referenced as:

pkcs11:token=Nikos;serial=307521161601031;model=PKCS%2315;manufacturer=EnterSafe

Objects stored in a PKCS #11 token can typically be extracted if they are not marked as sensitive. Usually only private keys are marked as sensitive and cannot be extracted, while certificates and other data can be retrieved. The functions that can be used to enumerate and access objects are shown below.

int gnutls_pkcs11_obj_list_import_url4 (gnutls_pkcs11_obj_t ** p_list, unsigned int * n_list, const char * url, unsigned int flags)

int gnutls_pkcs11_obj_import_url (gnutls_pkcs11_obj_t obj, const char * url, unsigned int flags)

int gnutls_pkcs11_obj_export_url (gnutls_pkcs11_obj_t obj, gnutls_pkcs11_url_type_t detailed, char ** url)

Function: int gnutls_pkcs11_obj_get_info (gnutls_pkcs11_obj_t obj, gnutls_pkcs11_obj_info_t itype, void * output, size_t * output_size) ¶

obj: should contain a gnutls_pkcs11_obj_t type

itype: Denotes the type of information requested

output: where output will be stored

output_size: contains the maximum size of the output buffer and will be overwritten with the actual size.

This function will return information about the PKCS11 certificate such as the label, id as well as token information where the key is stored.

When output is text, a null terminated string is written to output and its string length is written to output_size (without null terminator). If the buffer is too small, output_size will contain the expected buffer size (with null terminator for text) and return GNUTLS_E_SHORT_MEMORY_BUFFER .

In versions previously to 3.6.0 this function included the null terminator to output_size . After 3.6.0 the output size doesn’t include the terminator character.

Returns: GNUTLS_E_SUCCESS (0) on success or a negative error code on error.

Since: 2.12.0

int gnutls_x509_crt_import_pkcs11 (gnutls_x509_crt_t crt, gnutls_pkcs11_obj_t pkcs11_crt)

int gnutls_x509_crt_import_url (gnutls_x509_crt_t crt, const char * url, unsigned int flags)

int gnutls_x509_crt_list_import_pkcs11 (gnutls_x509_crt_t * certs, unsigned int cert_max, gnutls_pkcs11_obj_t *const objs, unsigned int flags)

Properties of the physical token can also be accessed and altered with GnuTLS. For example data in a token can be erased (initialized), PIN can be altered, etc.

int gnutls_pkcs11_token_init (const char * token_url, const char * so_pin, const char * label)

int gnutls_pkcs11_token_get_url (unsigned int seq, gnutls_pkcs11_url_type_t detailed, char ** url)

int gnutls_pkcs11_token_get_info (const char * url, gnutls_pkcs11_token_info_t ttype, void * output, size_t * output_size)

int gnutls_pkcs11_token_get_flags (const char * url, unsigned int * flags)

int gnutls_pkcs11_token_set_pin (const char * token_url, const char * oldpin, const char * newpin, unsigned int flags)

The following examples demonstrate the usage of the API. The first example will list all available PKCS #11 tokens in a system and the latter will list all certificates in a token that have a corresponding private key.

int i;
char* url;

gnutls_global_init();

for (i=0;;i++) 
  {
    ret = gnutls_pkcs11_token_get_url(i, &url);
    if (ret == GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE)
      break;

    if (ret < 0)
      exit(1);
		
    fprintf(stdout, "Token[%d]: URL: %s\n", i, url);
    gnutls_free(url);
  }
gnutls_global_deinit();

/* This example code is placed in the public domain. */

#include <config.h>
#include <gnutls/gnutls.h>
#include <gnutls/pkcs11.h>
#include <stdio.h>
#include <stdlib.h>

#define URL "pkcs11:URL"

int main(int argc, char **argv)
{
	gnutls_pkcs11_obj_t *obj_list;
	gnutls_x509_crt_t xcrt;
	unsigned int obj_list_size = 0;
	gnutls_datum_t cinfo;
	int ret;
	unsigned int i;

	ret = gnutls_pkcs11_obj_list_import_url4(
		&obj_list, &obj_list_size, URL,
		GNUTLS_PKCS11_OBJ_FLAG_CRT |
			GNUTLS_PKCS11_OBJ_FLAG_WITH_PRIVKEY);
	if (ret < 0)
		return -1;

	/* now all certificates are in obj_list */
	for (i = 0; i < obj_list_size; i++) {
		gnutls_x509_crt_init(&xcrt);

		gnutls_x509_crt_import_pkcs11(xcrt, obj_list[i]);

		gnutls_x509_crt_print(xcrt, GNUTLS_CRT_PRINT_FULL, &cinfo);

		fprintf(stdout, "cert[%d]:\n %s\n\n", i, cinfo.data);

		gnutls_free(cinfo.data);
		gnutls_x509_crt_deinit(xcrt);
	}

	for (i = 0; i < obj_list_size; i++)
		gnutls_pkcs11_obj_deinit(obj_list[i]);
	gnutls_free(obj_list);

	return 0;
}

5.3.5 Writing objects ¶

With GnuTLS you can copy existing private keys and certificates to a token. Note that when copying private keys it is recommended to mark them as sensitive using the GNUTLS_PKCS11_OBJ_FLAG_MARK_SENSITIVE to prevent its extraction. An object can be marked as private using the flag GNUTLS_PKCS11_OBJ_FLAG_MARK_PRIVATE, to require PIN to be entered before accessing the object (for operations or otherwise).

Function: int gnutls_pkcs11_copy_x509_privkey2 (const char * token_url, gnutls_x509_privkey_t key, const char * label, const gnutls_datum_t * cid, unsigned int key_usage, unsigned int flags) ¶

token_url: A PKCS 11 URL specifying a token

key: A private key

label: A name to be used for the stored data

cid: The CKA_ID to set for the object -if NULL, the ID will be derived from the public key

key_usage: One of GNUTLS_KEY_*

flags: One of GNUTLS_PKCS11_OBJ_* flags

This function will copy a private key into a PKCS 11 token specified by a URL.

Since 3.6.3 the objects are marked as sensitive by default unless GNUTLS_PKCS11_OBJ_FLAG_MARK_NOT_SENSITIVE is specified.

Returns: On success, GNUTLS_E_SUCCESS (0) is returned, otherwise a negative error value.

Since: 3.4.0

Function: int gnutls_pkcs11_copy_x509_crt2 (const char * token_url, gnutls_x509_crt_t crt, const char * label, const gnutls_datum_t * cid, unsigned int flags) ¶

token_url: A PKCS 11 URL specifying a token

crt: The certificate to copy

label: The name to be used for the stored data

cid: The CKA_ID to set for the object -if NULL, the ID will be derived from the public key

flags: One of GNUTLS_PKCS11_OBJ_FLAG_*

This function will copy a certificate into a PKCS 11 token specified by a URL. Valid flags to mark the certificate: GNUTLS_PKCS11_OBJ_FLAG_MARK_TRUSTED , GNUTLS_PKCS11_OBJ_FLAG_MARK_PRIVATE , GNUTLS_PKCS11_OBJ_FLAG_MARK_CA , GNUTLS_PKCS11_OBJ_FLAG_MARK_ALWAYS_AUTH .

Returns: On success, GNUTLS_E_SUCCESS (0) is returned, otherwise a negative error value.

Since: 3.4.0

Function: int gnutls_pkcs11_delete_url (const char * object_url, unsigned int flags) ¶

object_url: The URL of the object to delete.

flags: One of GNUTLS_PKCS11_OBJ_* flags

This function will delete objects matching the given URL. Note that not all tokens support the delete operation.

Returns: On success, the number of objects deleted is returned, otherwise a negative error value.

Since: 2.12.0

5.3.6 Low Level Access ¶

When it is needed to use PKCS#11 functionality which is not wrapped by GnuTLS, it is possible to extract the PKCS#11 session, object or token pointers. That allows an application to still access the low-level functionality, while at the same time take advantage of the URI addressing scheme supported by GnuTLS.

Function: int gnutls_pkcs11_token_get_ptr (const char * url, void ** ptr, unsigned long * slot_id, unsigned int flags) ¶

url: should contain a PKCS11 URL identifying a token

ptr: will contain the CK_FUNCTION_LIST_PTR pointer

slot_id: will contain the slot_id (may be NULL )

flags: should be zero

This function will return the function pointer of the specified token by the URL. The returned pointers are valid until gnutls is deinitialized, c.f. _global_deinit() .

Returns: GNUTLS_E_SUCCESS (0) on success or a negative error code on error.

Since: 3.6.3

Function: int gnutls_pkcs11_obj_get_ptr (gnutls_pkcs11_obj_t obj, void ** ptr, void ** session, void ** ohandle, unsigned long * slot_id, unsigned int flags) ¶

obj: should contain a gnutls_pkcs11_obj_t type

ptr: will contain the CK_FUNCTION_LIST_PTR pointer (may be NULL )

session: will contain the CK_SESSION_HANDLE of the object

ohandle: will contain the CK_OBJECT_HANDLE of the object

slot_id: the identifier of the slot (may be NULL )

flags: Or sequence of GNUTLS_PKCS11_OBJ_* flags

Obtains the PKCS11 session handles of an object. session and ohandle must be deinitialized by the caller. The returned pointers are independent of the obj lifetime.

Returns: GNUTLS_E_SUCCESS (0) on success or a negative error code on error.

Since: 3.6.3

5.3.7 Using a PKCS #11 token with TLS ¶

It is possible to use a PKCS #11 token to a TLS session, as shown in ex-pkcs11-client. In addition the following functions can be used to load PKCS #11 key and certificates by specifying a PKCS #11 URL instead of a filename.

int gnutls_certificate_set_x509_trust_file (gnutls_certificate_credentials_t cred, const char * cafile, gnutls_x509_crt_fmt_t type)

int gnutls_certificate_set_x509_key_file2 (gnutls_certificate_credentials_t res, const char * certfile, const char * keyfile, gnutls_x509_crt_fmt_t type, const char * pass, unsigned int flags)

5.3.8 Verifying certificates over PKCS #11 ¶

The PKCS #11 API can be used to allow all applications in the same operating system to access shared cryptographic keys and certificates in a uniform way, as in Figure 5.1. That way applications could load their trusted certificate list, as well as user certificates from a common PKCS #11 module. Such a provider is the p11-kit trust storage module¹² and it provides access to the trusted Root CA certificates in a system. That provides a more dynamic list of Root CA certificates, as opposed to a static list in a file or directory.

That store, allows for distrusting of CAs or certificates, as well as categorization of the Root CAs (Web verification, Code signing, etc.), in addition to restricting their purpose via stapled extensions¹³. GnuTLS will utilize the p11-kit trust module as the default trust store if configured to; i.e., if ’–with-default-trust-store-pkcs11=pkcs11:’ is given to the configure script.

5.3.9 Invoking p11tool ¶

Program that allows operations on PKCS #11 smart cards and security modules.

To use PKCS #11 tokens with GnuTLS the p11-kit configuration files need to be setup. That is create a .module file in /etc/pkcs11/modules with the contents ’module: /path/to/pkcs11.so’. Alternatively the configuration file /etc/gnutls/pkcs11.conf has to exist and contain a number of lines of the form ’load=/usr/lib/opensc-pkcs11.so’.

You can provide the PIN to be used for the PKCS #11 operations with the environment variables GNUTLS_PIN and GNUTLS_SO_PIN.

p11tool help/usage (-?) ¶

The text printed is the same whether selected with the help option (--help) or the more-help option (--more-help). more-help will print the usage text by passing it through a pager program. more-help is disabled on platforms without a working fork(2) function. The PAGER environment variable is used to select the program, defaulting to more. Both will exit with a status code of 0.

p11tool - GnuTLS PKCS #11 tool
Usage:  p11tool [ -<flag> [<val>] | --<name>[{=| }<val>] ]... [url]

None:


Tokens:

       --list-tokens          List all available tokens
       --list-token-urls      List the URLs available tokens
       --list-mechanisms      List all available mechanisms in a token
       --initialize           Initializes a PKCS #11 token
       --initialize-pin       Initializes/Resets a PKCS #11 token user PIN
       --initialize-so-pin    Initializes/Resets a PKCS #11 token security officer PIN
       --set-pin=str          Specify the PIN to use on token operations
       --set-so-pin=str       Specify the Security Officer's PIN to use on token initialization

Object listing:

       --list-all             List all available objects in a token
       --list-all-certs       List all available certificates in a token
       --list-certs           List all certificates that have an associated private key
       --list-all-privkeys    List all available private keys in a token
       --list-privkeys        an alias for the 'list-all-privkeys' option
       --list-keys            an alias for the 'list-all-privkeys' option
       --list-all-trusted     List all available certificates marked as trusted
       --export               Export the object specified by the URL
				- prohibits these options:
				export-stapled
				export-chain
				export-pubkey
       --export-stapled       Export the certificate object specified by the URL
				- prohibits these options:
				export
				export-chain
				export-pubkey
       --export-chain         Export the certificate specified by the URL and its chain of trust
				- prohibits these options:
				export-stapled
				export
				export-pubkey
       --export-pubkey        Export the public key for a private key
				- prohibits these options:
				export-stapled
				export
				export-chain
       --info                 List information on an available object in a token
       --trusted              an alias for the 'mark-trusted' option
       --distrusted           an alias for the 'mark-distrusted' option

Key generation:

       --generate-privkey=str Generate private-public key pair of given type
       --bits=num             Specify the number of bits for the key generate
       --curve=str            Specify the curve used for EC key generation
       --sec-param=str        Specify the security level

Writing objects:

       --set-id=str           Set the CKA_ID (in hex) for the specified by the URL object
				- prohibits the option 'write'
       --set-label=str        Set the CKA_LABEL for the specified by the URL object
				- prohibits these options:
				write
				set-id
       --write                Writes the loaded objects to a PKCS #11 token
       --delete               Deletes the objects matching the given PKCS #11 URL
       --label=str            Sets a label for the write operation
       --id=str               Sets an ID for the write operation
       --mark-wrap            Marks the generated key to be a wrapping key
       --mark-trusted         Marks the object to be written as trusted
				- prohibits the option 'mark-distrusted'
       --mark-distrusted      When retrieving objects, it requires the objects to be distrusted
				- prohibits the option 'mark-trusted'
       --mark-decrypt         Marks the object to be written for decryption
       --mark-sign            Marks the object to be written for signature generation
       --mark-ca              Marks the object to be written as a CA
       --mark-private         Marks the object to be written as private
       --ca                   an alias for the 'mark-ca' option
       --private              an alias for the 'mark-private' option
       --mark-always-authenticate  Marks the object to be written as always authenticate
       --secret-key=str       Provide a hex encoded secret key
       --load-privkey=file    Private key file to use
				- file must pre-exist
       --load-pubkey=file     Public key file to use
				- file must pre-exist
       --load-certificate=file Certificate file to use
				- file must pre-exist

Other options:

   -d, --debug=num            Enable debugging
				- it must be in the range:
				  0 to 9999
       --outfile=str          Output file
       --login                Force (user) login to token
       --so-login             Force security officer login to token
       --admin-login          an alias for the 'so-login' option
       --test-sign            Tests the signature operation of the provided object
       --sign-params=str      Sign with a specific signature algorithm
       --hash=str             Hash algorithm to use for signing
       --generate-random=num  Generate random data
   -8, --pkcs8                Use PKCS #8 format for private keys
       --inder                Use DER/RAW format for input
       --inraw                an alias for the 'inder' option
       --outder               Use DER format for output certificates, private keys, and DH parameters
       --outraw               an alias for the 'outder' option
       --provider=file        Specify the PKCS #11 provider library
       --detailed-url         Print detailed URLs
       --only-urls            Print a compact listing using only the URLs
       --batch                Disable all interaction with the tool

Version, usage and configuration options:

   -v, --version[=arg]        output version information and exit
   -h, --help                 display extended usage information and exit
   -!, --more-help            extended usage information passed thru pager

Options are specified by doubled hyphens and their name or by a single
hyphen and the flag character.
Operands and options may be intermixed.  They will be reordered.

Program that allows operations on PKCS #11 smart cards
and security modules. 

To use PKCS #11 tokens with GnuTLS the p11-kit configuration files need to be setup.
That is create a .module file in /etc/pkcs11/modules with the contents 'module: /path/to/pkcs11.so'.
Alternatively the configuration file /etc/gnutls/pkcs11.conf has to exist and contain a number
of lines of the form 'load=/usr/lib/opensc-pkcs11.so'.

You can provide the PIN to be used for the PKCS #11 operations with the environment variables
GNUTLS_PIN and GNUTLS_SO_PIN.


Please send bug reports to:  <bugs@gnutls.org>

token-related-options options ¶

Tokens.

list-token-urls option. ¶

This is the “list the urls available tokens” option. This is a more compact version of –list-tokens.

initialize-so-pin option. ¶

This is the “initializes/resets a pkcs #11 token security officer pin” option. This initializes the security officer’s PIN. When used non-interactively use the GNUTLS_NEW_SO_PIN environment variables to initialize SO’s PIN.

set-pin option. ¶

This is the “specify the pin to use on token operations” option. This option takes a ArgumentType.STRING argument. Alternatively the GNUTLS_PIN environment variable may be used.

set-so-pin option. ¶

This is the “specify the security officer’s pin to use on token initialization” option. This option takes a ArgumentType.STRING argument. Alternatively the GNUTLS_SO_PIN environment variable may be used.

object-list-related-options options ¶

Object listing.

list-all option. ¶

This is the “list all available objects in a token” option. All objects available in the token will be listed. That includes objects which are potentially unaccessible using this tool.

list-all-certs option. ¶

This is the “list all available certificates in a token” option. That option will also provide more information on the certificates, for example, expand the attached extensions in a trust token (like p11-kit-trust).

list-certs option. ¶

This is the “list all certificates that have an associated private key” option. That option will only display certificates which have a private key associated with them (share the same ID).

list-all-privkeys option. ¶

This is the “list all available private keys in a token” option. Lists all the private keys in a token that match the specified URL.

list-privkeys option. ¶

This is an alias for the list-all-privkeys option, see the list-all-privkeys option documentation.

list-keys option. ¶

This is an alias for the list-all-privkeys option, see the list-all-privkeys option documentation.

export-stapled option. ¶

This is the “export the certificate object specified by the url” option.

This option has some usage constraints. It:

• must not appear in combination with any of the following options: export, export-chain, export-pubkey.

Exports the certificate specified by the URL while including any attached extensions to it. Since attached extensions are a p11-kit extension, this option is only available on p11-kit registered trust modules.

export-chain option. ¶

This is the “export the certificate specified by the url and its chain of trust” option.

This option has some usage constraints. It:

• must not appear in combination with any of the following options: export-stapled, export, export-pubkey.

Exports the certificate specified by the URL and generates its chain of trust based on the stored certificates in the module.

export-pubkey option. ¶