Determines the validity of a certificate chain, outside the context of a TLS session.
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).
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
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.
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.
a TlsCertificate chain
the purpose that this certificate chain will be used for.
the expected peer identity
used to interact with the user if necessary
additional verify flags
a Cancellable, or null
the appropriate TlsCertificateFlags which represents the result of verification.