<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html lang="en">
<head>
<meta content="text/html; charset=US-ASCII" http-equiv="Content-Type">
<title>
GitLab
</title>
<style>img {
max-width: 100%; height: auto;
}
</style>
</head>
<body>
<div class="content">
<div style="">
<p dir="auto">I'll try to be more specific:</p>
<ol dir="auto">
<li>First, according to <a href="https://gitlab.com/gnutls/gnutls/blob/master/lib/x509/verify.c#L678">https://gitlab.com/gnutls/gnutls/blob/master/lib/x509/verify.c#L678</a>, verify_crt will not apply name constraints against CA certificates. However, AFAIK, name constraints should only be skipped when it is a self-issued certificate, except when it the final certificate in the path. So it should be checked against intermediate CA, specially against subtrees constraints.</li>
</ol>
<blockquote dir="auto">
<p>Name constraints are not applied to self-issued certificates (unless
the certificate is the final certificate in the path). (This could
prevent CAs that use name constraints from employing self-issued
certificates to implement key rollover.)
<a href="https://tools.ietf.org/html/rfc5280#section-4.2.1.10" rel="nofollow noreferrer noopener" target="_blank">https://tools.ietf.org/html/rfc5280#section-4.2.1.10</a></p>
</blockquote>
<ol start="2" dir="auto">
<li>
<p>If CA certificate should be checked against DNS name constraints, it will try to get SubjAltName.DNS at <a href="https://gitlab.com/gnutls/gnutls/blob/master/lib/x509/name_constraints.c#L1196">https://gitlab.com/gnutls/gnutls/blob/master/lib/x509/name_constraints.c#L1196</a> . Normally, a CA certificate should not have it. Here <a href="https://gitlab.com/gnutls/gnutls/blob/master/lib/x509/name_constraints.c#L1223">https://gitlab.com/gnutls/gnutls/blob/master/lib/x509/name_constraints.c#L1223</a> it is assumed that the certificate being tested is not a CA (but as I mentioned before in 1), it should consider that the cert being tested is a CA). As it assumes that it is not a CA, it only checks key purpose for GNUTLS_KP_TLS_WWW_SERVER. When it did not find Extended key usage (2.5.29.37), it assumes that the certificate can be used as TLS WWW Server. Shouldn't it be better to check CA:true and key usage (2.5.29.15) before? It might avoid testing CN for a certificate that cannot be used for a TLS Service. I don't know exactly what qualifies a certificate to be used in a TLS Service.</p>
</li>
<li>
<p>Finally, it is a certificate suitable for a TLS Service. Considering that there is no SubjectAltName.DNS, it tests CN <a href="https://gitlab.com/gnutls/gnutls/blob/master/lib/x509/name_constraints.c#L1243">https://gitlab.com/gnutls/gnutls/blob/master/lib/x509/name_constraints.c#L1243</a>. Here, it should test if CN is a valid DNS Name (see openssl commit I cited in my last comment) before testing CN against DNS name constraints. It is uncommon but a server certificate can still be usable without SubjAltName.DNS without relying on CN as it can use SubjAltName.IPAddress or SubjAltName.URI. There is no reason to test CN against DNS name constraints if it is not usable as a DNS Name.</p>
</li>
</ol>
<p dir="auto">BTW, I opened a bug for pidgin problem <a href="https://developer.pidgin.im/ticket/17393" rel="nofollow noreferrer noopener" target="_blank">https://developer.pidgin.im/ticket/17393</a></p>
</div>
</div>
<div class="footer" style="margin-top: 10px;">
<p style="font-size: small; color: #777;">
—
<br>
Reply to this email directly or <a href="https://gitlab.com/gnutls/gnutls/issues/776#note_176373861">view it on GitLab</a>.
<br>
You're receiving this email because of your account on gitlab.com.
If you'd like to receive fewer emails, you can
<a href="https://gitlab.com/sent_notifications/821f810bcafd68a5ff42dbd5a84e7b7d/unsubscribe">unsubscribe</a>
from this thread or
adjust your notification settings.
<script type="application/ld+json">{"@context":"http://schema.org","@type":"EmailMessage","action":{"@type":"ViewAction","name":"View Issue","url":"https://gitlab.com/gnutls/gnutls/issues/776#note_176373861"}}</script>
</p>
</div>
</body>
</html>