TlsDatabase.verifyChain

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

chain is a chain of #GTlsCertificate objects each pointing to the next certificate in the chain by its #GTlsCertificate: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, gio.types.TlsCertificateFlags.BadIdentity 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 gio.types.TlsDatabaseVerifyFlags.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 gio.types.TlsCertificateFlags.GenericError and error will be set accordingly. error 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 gio.types.TlsCertificateFlags.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 #GTlsDatabase during certificate verification by adjusting the #GTlsCertificate:issuer property of each certificate in chain. Since GLib 2.48, this no longer occurs, so you cannot rely on #GTlsCertificate:issuer to represent the actual certification path used during certificate verification.

Because TLS session context is not used, #GTlsDatabase may not perform as many checks on the certificates as #GTlsConnection 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 #GTlsConnection 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 gio.tls_database.TlsDatabase.verifyChainAsync to perform the verification operation asynchronously.