verify_chain

Determines the validity of a certificate chain, outside the context of a TLS session.

chain is a chain of TlsCertificate objects each pointing to the next certificate in the chain by its issuer property.

purpose describes the purpose (or usage) for which the certificate is being used. Typically purpose will be set to g_tls_database_purpose_authenticate_server which means that the certificate is being used to authenticate a server (and we are acting as the client).

The identity is used to ensure the server certificate is valid for the expected peer identity. If the identity does not match the certificate, g_tls_certificate_bad_identity will be set in the return value. If identity is null, that bit will never be set in the return value. The peer identity may also be used to check for pinned certificates (trust exceptions) in the database. These may override the normal verification process on a host-by-host basis.

Currently there are no flags, and g_tls_database_verify_none should be used.

If chain is found to be valid, then the return value will be 0. If chain is found to be invalid, then the return value will indicate at least one problem found. If the function is unable to determine whether chain is valid (for example, because cancellable is triggered before it completes) then the return value will be g_tls_certificate_generic_error and throws will be set accordingly. throws is not set when chain is successfully analyzed but found to be invalid.

GLib guarantees that if certificate verification fails, at least one error will be set in the return value, but it does not guarantee that all possible errors will be set. Accordingly, you may not safely decide to ignore any particular type of error. For example, it would be incorrect to mask g_tls_certificate_expired if you want to allow expired certificates, because this could potentially be the only error flag set even if other problems exist with the certificate.

Prior to GLib 2.48, GLib's default TLS backend modified chain to represent the certification path built by TlsDatabase during certificate verification by adjusting the issuer property of each certificate in chain. Since GLib 2.48, this no longer occurs, so you cannot rely on issuer to represent the actual certification path used during certificate verification.

Because TLS session context is not used, TlsDatabase may not perform as many checks on the certificates as TlsConnection would. For example, certificate constraints may not be honored, and revocation checks may not be performed. The best way to verify TLS certificates used by a TLS connection is to let TlsConnection handle the verification.

The TLS backend may attempt to look up and add missing certificates to the chain. This may involve HTTP requests to download missing certificates.

This function can block. Use verify_chain_async to perform the verification operation asynchronously.

Parameters:

Returns: