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