Thread: "cert" + clientcert=verify-ca in pg_hba.conf?

"cert" + clientcert=verify-ca in pg_hba.conf?

From

Kyotaro Horiguchi

Date:

16 July 2020, 03:30:12

Hello.

The "Certificate Authentication" section in the doc for PG12 and later
describes the relation ship with clientcert as follows.

> In a pg_hba.conf record specifying certificate authentication, the
> authentication option clientcert is assumed to be verify-ca or
> verify-full, and it cannot be turned off since a client certificate
> is necessary for this method. What the cert method adds to the basic
> clientcert certificate validity test is a check that the cn
> attribute matches the database user name.

In reality, cert method is assumed as "vefiry-full" and does not add
anything to verify-full and cannot be degraded or turned off. It seems
to be a mistake on rewriting it when clientcert was changed to accept
verify-ca/full at PG12.

Related to that, pg_hba.conf accepts the combination of "cert" method
and the option clientcert="verify-ca" but it is ignored. We should
reject that combination the same way with "cert"+"no-verify".

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center
From d7e24df379f29e55adc41c6a98602f2434f5b07e Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi <horikyoga.ntt@gmail.com>
Date: Wed, 15 Jul 2020 21:00:20 +0900
Subject: [PATCH] Fix behavior for "cert"+"verify-ca" in pg_hba.conf

"cert" method in a line in pg_hba.conf is assumed as
clientcert="verify_full" and if we set it to "verify-ca", it is just
ignored. Since we explicitly reject "no-verify" in that case so we
should reject verify-ca as well.
---
 doc/src/sgml/client-auth.sgml |  7 ++-----
 src/backend/libpq/hba.c       | 10 ++++++++++
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
index 5cd88b462d..5ea45d5b87 100644
--- a/doc/src/sgml/client-auth.sgml
+++ b/doc/src/sgml/client-auth.sgml
@@ -2044,11 +2044,8 @@ host ... radius radiusservers="server1,server2" radiussecrets="""secret one"",""
    <para>
     In a <filename>pg_hba.conf</filename> record specifying certificate
     authentication, the authentication option <literal>clientcert</literal> is
-    assumed to be <literal>verify-ca</literal> or <literal>verify-full</literal>,
-    and it cannot be turned off since a client certificate is necessary for this
-    method. What the <literal>cert</literal> method adds to the basic
-    <literal>clientcert</literal> certificate validity test is a check that the
-    <literal>cn</literal> attribute matches the database user name.
+    assumed to be <literal>verify-full</literal>,
+    and it cannot be degradated to verify-ca nor turned off.
    </para>
   </sect1>
 
diff --git a/src/backend/libpq/hba.c b/src/backend/libpq/hba.c
index 9d63830553..18ef385405 100644
--- a/src/backend/libpq/hba.c
+++ b/src/backend/libpq/hba.c
@@ -1711,6 +1711,16 @@ parse_hba_auth_opt(char *name, char *val, HbaLine *hbaline,
         if (strcmp(val, "1") == 0
             || strcmp(val, "verify-ca") == 0)
         {
+            if (hbaline->auth_method == uaCert)
+            {
+                ereport(elevel,
+                        (errcode(ERRCODE_CONFIG_FILE_ERROR),
+                         errmsg("clientcert can not be set to \"verify-ca\" when using \"cert\" authentication"),
+                         errcontext("line %d of configuration file \"%s\"",
+                                    line_num, HbaFileName)));
+                *err_msg = "clientcert can not be set to \"verify-ca\" when using \"cert\" authentication";
+                return false;
+            }
             hbaline->clientcert = clientCertCA;
         }
         else if (strcmp(val, "verify-full") == 0)
-- 
2.18.4

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Bruce Momjian

Date:

25 August 2020, 03:01:26

On Thu, Jul 16, 2020 at 09:30:12AM +0900, Kyotaro Horiguchi wrote:
> Hello.
> 
> The "Certificate Authentication" section in the doc for PG12 and later
> describes the relation ship with clientcert as follows.
> 
> > In a pg_hba.conf record specifying certificate authentication, the
> > authentication option clientcert is assumed to be verify-ca or
> > verify-full, and it cannot be turned off since a client certificate
> > is necessary for this method. What the cert method adds to the basic
> > clientcert certificate validity test is a check that the cn
> > attribute matches the database user name.
> 
> In reality, cert method is assumed as "verify-full" and does not add
> anything to verify-full and cannot be degraded or turned off. It seems
> to be a mistake on rewriting it when clientcert was changed to accept
> verify-ca/full at PG12.

Agreed.  I was able to test this patch and it does what you explained. 
I have slightly adjusted the doc part of the patch, attached.

> Related to that, pg_hba.conf accepts the combination of "cert" method
> and the option clientcert="verify-ca" but it is ignored. We should
> reject that combination the same way with "cert"+"no-verify".

Are you saying we should _require_ clientcert=verify-full when 'cert'
authentication is used?  I don't see the point of that --- I just
updated the docs to say doing so was duplicate behavior.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee

Attachment

cert.diff

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Kyotaro Horiguchi

Date:

25 August 2020, 04:41:26

At Mon, 24 Aug 2020 20:01:26 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> On Thu, Jul 16, 2020 at 09:30:12AM +0900, Kyotaro Horiguchi wrote:
> > Hello.
> > 
> > The "Certificate Authentication" section in the doc for PG12 and later
> > describes the relation ship with clientcert as follows.
> > 
> > > In a pg_hba.conf record specifying certificate authentication, the
> > > authentication option clientcert is assumed to be verify-ca or
> > > verify-full, and it cannot be turned off since a client certificate
> > > is necessary for this method. What the cert method adds to the basic
> > > clientcert certificate validity test is a check that the cn
> > > attribute matches the database user name.
> > 
> > In reality, cert method is assumed as "verify-full" and does not add
> > anything to verify-full and cannot be degraded or turned off. It seems
> > to be a mistake on rewriting it when clientcert was changed to accept
> > verify-ca/full at PG12.
> 
> Agreed.  I was able to test this patch and it does what you explained. 
> I have slightly adjusted the doc part of the patch, attached.

Thanks.

     In a <filename>pg_hba.conf</filename> record specifying certificate
-    authentication, the authentication option <literal>clientcert</literal> is
-    assumed to be <literal>verify-ca</literal> or <literal>verify-full</literal>,
-    and it cannot be turned off since a client certificate is necessary for this
-    method. What the <literal>cert</literal> method adds to the basic
-    <literal>clientcert</literal> certificate validity test is a check that the
-    <literal>cn</literal> attribute matches the database user name.
+    authentication, the only valid value for <literal>clientcert</literal>
+    is <literal>verify-full</literal>, and this has no affect since it
+    just duplicates <literal>client</literal> authentication's behavior.

I read it as "it can be specified (without an error), but actually
does nothing". If it is the correct reading, I prefer to mention that
incompatible values cause an error.

> > Related to that, pg_hba.conf accepts the combination of "cert" method
> > and the option clientcert="verify-ca" but it is ignored. We should
> > reject that combination the same way with "cert"+"no-verify".
> 
> Are you saying we should _require_ clientcert=verify-full when 'cert'
> authentication is used?  I don't see the point of that --- I just
> updated the docs to say doing so was duplicate behavior.

I don't suggest changing the current behavior. I'm saying it is the
way it is working and we should correctly error-out that since it
doesn't work as specified.

auth.c:608
    if ((status == STATUS_OK && port->hba->clientcert == clientCertFull)
        || port->hba->auth_method == uaCert)
    {
        /*
         * Make sure we only check the certificate if we use the cert method
         * or verify-full option.
         */
#ifdef USE_SSL
        status = CheckCertAuth(port);
#else
        Assert(false);
#endif
    }

regard.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Bruce Momjian

Date:

25 August 2020, 04:49:40

On Tue, Aug 25, 2020 at 10:41:26AM +0900, Kyotaro Horiguchi wrote:
> At Mon, 24 Aug 2020 20:01:26 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > I have slightly adjusted the doc part of the patch, attached.
> 
> Thanks.
> 
>      In a <filename>pg_hba.conf</filename> record specifying certificate
> -    authentication, the authentication option <literal>clientcert</literal> is
> -    assumed to be <literal>verify-ca</literal> or <literal>verify-full</literal>,
> -    and it cannot be turned off since a client certificate is necessary for this
> -    method. What the <literal>cert</literal> method adds to the basic
> -    <literal>clientcert</literal> certificate validity test is a check that the
> -    <literal>cn</literal> attribute matches the database user name.
> +    authentication, the only valid value for <literal>clientcert</literal>
> +    is <literal>verify-full</literal>, and this has no affect since it
> +    just duplicates <literal>client</literal> authentication's behavior.
> 
> I read it as "it can be specified (without an error), but actually
> does nothing". If it is the correct reading, I prefer to mention that
> incompatible values cause an error.

Well, when I say "the only valid value", that means any other value is
invalid, and hence will generate an error.

> > > Related to that, pg_hba.conf accepts the combination of "cert" method
> > > and the option clientcert="verify-ca" but it is ignored. We should
> > > reject that combination the same way with "cert"+"no-verify".
> > 
> > Are you saying we should _require_ clientcert=verify-full when 'cert'
> > authentication is used?  I don't see the point of that --- I just
> > updated the docs to say doing so was duplicate behavior.
> 
> I don't suggest changing the current behavior. I'm saying it is the
> way it is working and we should correctly error-out that since it
> doesn't work as specified.

Uh, I don't understand what 'combination the same way with
"cert"+"no-verify"'.  Right now, cert with no clientcert/verify line
works just fine.  Is "no-verify" something special?  Are you saying it
is any random string that would generate an error?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Kyotaro Horiguchi

Date:

25 August 2020, 05:00:49

At Mon, 24 Aug 2020 21:49:40 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > > Are you saying we should _require_ clientcert=verify-full when 'cert'
> > > authentication is used?  I don't see the point of that --- I just
> > > updated the docs to say doing so was duplicate behavior.
> > 
> > I don't suggest changing the current behavior. I'm saying it is the
> > way it is working and we should correctly error-out that since it
> > doesn't work as specified.

Sorry, I mistead you. I don't suggest verify-full is needed for cert
authentication. I said we should just reject the combination
cert+veriry-ca.

> Uh, I don't understand what 'combination the same way with
> "cert"+"no-verify"'.  Right now, cert with no clientcert/verify line
> works just fine.  Is "no-verify" something special?  Are you saying it
> is any random string that would generate an error?

It was delimited as "We should reject (that)" "that combination
(=cert+ferify-ca)" "the same way(=error-out)" "with cert+no-verify".

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Bruce Momjian

Date:

25 August 2020, 05:06:45

On Tue, Aug 25, 2020 at 11:00:49AM +0900, Kyotaro Horiguchi wrote:
> At Mon, 24 Aug 2020 21:49:40 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > > > Are you saying we should _require_ clientcert=verify-full when 'cert'
> > > > authentication is used?  I don't see the point of that --- I just
> > > > updated the docs to say doing so was duplicate behavior.
> > > 
> > > I don't suggest changing the current behavior. I'm saying it is the
> > > way it is working and we should correctly error-out that since it
> > > doesn't work as specified.
> 
> Sorry, I mistead you. I don't suggest verify-full is needed for cert
> authentication. I said we should just reject the combination
> cert+veriry-ca.

OK.

> > Uh, I don't understand what 'combination the same way with
> > "cert"+"no-verify"'.  Right now, cert with no clientcert/verify line
> > works just fine.  Is "no-verify" something special?  Are you saying it
> > is any random string that would generate an error?
> 
> It was delimited as "We should reject (that)" "that combination
> (=cert+ferify-ca)" "the same way(=error-out)" "with cert+no-verify".

OK, and that is what your patch does, right?  And we should error out on
"with cert+no-verify" just like "with cert+XXXXXX", right?  I don't see
"no-verify" mentioned anywhere in our docs.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Kyotaro Horiguchi

Date:

25 August 2020, 05:41:55

Thank you for the patience.

At Mon, 24 Aug 2020 22:06:45 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> On Tue, Aug 25, 2020 at 11:00:49AM +0900, Kyotaro Horiguchi wrote:
> > At Mon, 24 Aug 2020 21:49:40 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > > > > Are you saying we should _require_ clientcert=verify-full when 'cert'
> > > > > authentication is used?  I don't see the point of that --- I just
> > > > > updated the docs to say doing so was duplicate behavior.
> > > > 
> > > > I don't suggest changing the current behavior. I'm saying it is the
> > > > way it is working and we should correctly error-out that since it
> > > > doesn't work as specified.
> > 
> > Sorry, I mistead you. I don't suggest verify-full is needed for cert
> > authentication. I said we should just reject the combination
> > cert+veriry-ca.
> 
> OK.
> 
> > > Uh, I don't understand what 'combination the same way with
> > > "cert"+"no-verify"'.  Right now, cert with no clientcert/verify line
> > > works just fine.  Is "no-verify" something special?  Are you saying it
> > > is any random string that would generate an error?
> > 
> > It was delimited as "We should reject (that)" "that combination
> > (=cert+ferify-ca)" "the same way(=error-out)" "with cert+no-verify".
> 
> OK, and that is what your patch does, right?

Yes, 

> And we should error out on "with cert+no-verify" just like "with
> cert+XXXXXX", right?

Currently only cert+no-verify is rejected. The patch makes "cert+verify-ca" be rejected.

> I don't see "no-verify" mentioned anywhere in our docs.

no-verify itself is mentioned here.

https://www.postgresql.org/docs/13/ssl-tcp.html#SSL-CLIENT-CERTIFICATES

> The clientcert authentication option is available for all
> authentication methods, but only in pg_hba.conf lines specified as
> hostssl. When clientcert is not specified or is set to *no-verify*,
> the server will still verify any presented client certificates
> against its CA file, if one is configured ― but it will not insist
> that a client certificate be presented.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Bruce Momjian

Date:

25 August 2020, 06:04:51

On Tue, Aug 25, 2020 at 11:41:55AM +0900, Kyotaro Horiguchi wrote:
> Thank you for the patience.
> 
> At Mon, 24 Aug 2020 22:06:45 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > On Tue, Aug 25, 2020 at 11:00:49AM +0900, Kyotaro Horiguchi wrote:
> > > At Mon, 24 Aug 2020 21:49:40 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > > > > > Are you saying we should _require_ clientcert=verify-full when 'cert'
> > > > > > authentication is used?  I don't see the point of that --- I just
> > > > > > updated the docs to say doing so was duplicate behavior.
> > > > > 
> > > > > I don't suggest changing the current behavior. I'm saying it is the
> > > > > way it is working and we should correctly error-out that since it
> > > > > doesn't work as specified.
> > > 
> > > Sorry, I mistead you. I don't suggest verify-full is needed for cert
> > > authentication. I said we should just reject the combination
> > > cert+veriry-ca.
> > 
> > OK.
> > 
> > > > Uh, I don't understand what 'combination the same way with
> > > > "cert"+"no-verify"'.  Right now, cert with no clientcert/verify line
> > > > works just fine.  Is "no-verify" something special?  Are you saying it
> > > > is any random string that would generate an error?
> > > 
> > > It was delimited as "We should reject (that)" "that combination
> > > (=cert+ferify-ca)" "the same way(=error-out)" "with cert+no-verify".
> > 
> > OK, and that is what your patch does, right?
> 
> Yes, 
> 
> > And we should error out on "with cert+no-verify" just like "with
> > cert+XXXXXX", right?
> 
> Currently only cert+no-verify is rejected. The patch makes "cert+verify-ca" be rejected.
> 
> > I don't see "no-verify" mentioned anywhere in our docs.
> 
> no-verify itself is mentioned here.
> 
> https://www.postgresql.org/docs/13/ssl-tcp.html#SSL-CLIENT-CERTIFICATES

Oh, I see it now, thanks.  Do you have any idea what this part of the
docs means?

    When <literal>clientcert</literal> is not specified or is set to
    <literal>no-verify</literal>, the server will still verify any presented
    client certificates against its CA file, if one is configured —
    but it will not insist that a client certificate be presented.

Why is this useful?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Kyotaro Horiguchi

Date:

25 August 2020, 09:53:20

At Mon, 24 Aug 2020 23:04:51 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > > I don't see "no-verify" mentioned anywhere in our docs.
> > 
> > no-verify itself is mentioned here.
> > 
> > https://www.postgresql.org/docs/13/ssl-tcp.html#SSL-CLIENT-CERTIFICATES
> 
> Oh, I see it now, thanks.  Do you have any idea what this part of the
> docs means?
> 
>     When <literal>clientcert</literal> is not specified or is set to
>     <literal>no-verify</literal>, the server will still verify any presented
>     client certificates against its CA file, if one is configured —
>     but it will not insist that a client certificate be presented.

Ah.. Indeed.

Even if clientcert is not set or set to no-verify, it checks client
certificate against the CA if any. If verify-ca, client certificate
must be provided. As the result, no-verify actually fails if client
had a certificate that is not backed by the CA.

> Why is this useful?

I agree, but there seems to be an implementation reason for the
behavior. To identify an hba-line, some connection parameters like
user name and others sent over a connection is required.  Thus the
clientcert option in the to-be-identified hba-line is unknown prior to
the time SSL connection is made. So the documentation might need
amendment. Roughly something like the following?

===
When <literal>clientcert</literal> is not specified or is set
to<literal>no-verify</literal>, clients can connect to server without
having a client certificate.

Note: Regardless of the setting of <literal>clientcert</literal>,
connection can end with failure if a client certificate that cannot be
verified by the server is stored in the ~/.postgresql directory.
===

By the way, the following table line might need to be changed?

libpq-ssl.html:

>      <entry><filename>~/.postgresql/postgresql.crt</filename></entry>
>      <entry>client certificate</entry>
-      <entry>requested by server</entry>

The file is actually not requested by server, client just pushes to
server if any, unconditionally.

+      <entry>sent to server</entry>


regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Bruce Momjian

Date:

25 August 2020, 17:04:44

On Tue, Aug 25, 2020 at 03:53:20PM +0900, Kyotaro Horiguchi wrote:
> At Mon, 24 Aug 2020 23:04:51 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > > > I don't see "no-verify" mentioned anywhere in our docs.
> > > 
> > > no-verify itself is mentioned here.
> > > 
> > > https://www.postgresql.org/docs/13/ssl-tcp.html#SSL-CLIENT-CERTIFICATES
> > 
> > Oh, I see it now, thanks.  Do you have any idea what this part of the
> > docs means?
> > 
> >     When <literal>clientcert</literal> is not specified or is set to
> >     <literal>no-verify</literal>, the server will still verify any presented
> >     client certificates against its CA file, if one is configured —
> >     but it will not insist that a client certificate be presented.
> 
> Ah.. Indeed.
> 
> Even if clientcert is not set or set to no-verify, it checks client
> certificate against the CA if any. If verify-ca, client certificate
> must be provided. As the result, no-verify actually fails if client
> had a certificate that is not backed by the CA.

I think there are a few problems here.  In the docs, it says "will still
verify", but it doesn't say if it verifies the CA, or the CA _and_ the
CN/username.

Second, since it is optional, what value does it have?

> > Why is this useful?
> 
> I agree, but there seems to be an implementation reason for the
> behavior. To identify an hba-line, some connection parameters like
> user name and others sent over a connection is required.  Thus the
> clientcert option in the to-be-identified hba-line is unknown prior to
> the time SSL connection is made. So the documentation might need
> amendment. Roughly something like the following?

Well, I realize internally we need a way to indicate clientcert is not
used, but why do we bother exposing that to the user as a named option?

And you are right that the option name 'no-verify' is wrong since it
will verify the CA if it exists, so it more like 'optionally-verify',
which seems useless from a user interface perspective.

I guess the behavior of no-verify matches our client-side
sslmode=prefer, but at least that has the value of using SSL if
available, which prevents user-visible network traffic, but doesn't
force it, but I am not sure what the value of optional certificate
verification is, since verification is all it does.  I guess it should
be called "prefer-verify".

> ===
> When <literal>clientcert</literal> is not specified or is set
> to<literal>no-verify</literal>, clients can connect to server without
> having a client certificate.
> 
> Note: Regardless of the setting of <literal>clientcert</literal>,
> connection can end with failure if a client certificate that cannot be
> verified by the server is stored in the ~/.postgresql directory.
> ===
> 
> By the way, the following table line might need to be changed?
> 
> libpq-ssl.html:
> 
> >      <entry><filename>~/.postgresql/postgresql.crt</filename></entry>
> >      <entry>client certificate</entry>
> -      <entry>requested by server</entry>
> 
> The file is actually not requested by server, client just pushes to
> server if any, unconditionally.
> 
> +      <entry>sent to server</entry>

I have just applied this change to all branches, since it is an
independent fix.  Thanks.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Kyotaro Horiguchi

Date:

26 August 2020, 05:41:39

At Tue, 25 Aug 2020 10:04:44 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> On Tue, Aug 25, 2020 at 03:53:20PM +0900, Kyotaro Horiguchi wrote:
> > At Mon, 24 Aug 2020 23:04:51 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > > > > I don't see "no-verify" mentioned anywhere in our docs.
> > > > 
> > > > no-verify itself is mentioned here.
> > > > 
> > > > https://www.postgresql.org/docs/13/ssl-tcp.html#SSL-CLIENT-CERTIFICATES
> > > 
> > > Oh, I see it now, thanks.  Do you have any idea what this part of the
> > > docs means?
> > > 
> > >     When <literal>clientcert</literal> is not specified or is set to
> > >     <literal>no-verify</literal>, the server will still verify any presented
> > >     client certificates against its CA file, if one is configured —
> > >     but it will not insist that a client certificate be presented.
> > 
> > Ah.. Indeed.
> > 
> > Even if clientcert is not set or set to no-verify, it checks client
> > certificate against the CA if any. If verify-ca, client certificate
> > must be provided. As the result, no-verify actually fails if client
> > had a certificate that is not backed by the CA.
> 
> I think there are a few problems here.  In the docs, it says "will still
> verify", but it doesn't say if it verifies the CA, or the CA _and_ the
> CN/username.

It verifies only CA.

> Second, since it is optional, what value does it have?
> 
> > > Why is this useful?
> > 
> > I agree, but there seems to be an implementation reason for the
> > behavior. To identify an hba-line, some connection parameters like
> > user name and others sent over a connection is required.  Thus the
> > clientcert option in the to-be-identified hba-line is unknown prior to
> > the time SSL connection is made. So the documentation might need
> > amendment. Roughly something like the following?
> 
> Well, I realize internally we need a way to indicate clientcert is not
> used, but why do we bother exposing that to the user as a named option?

Because we think we need any named value for every alternatives
including the default value?

> And you are right that the option name 'no-verify' is wrong since it
> will verify the CA if it exists, so it more like 'optionally-verify',
> which seems useless from a user interface perspective.
> 
> I guess the behavior of no-verify matches our client-side
> sslmode=prefer, but at least that has the value of using SSL if
> available, which prevents user-visible network traffic, but doesn't
> force it, but I am not sure what the value of optional certificate
> verification is, since verification is all it does.  I guess it should
> be called "prefer-verify".

The point of no-verify is to allow the absence of client
certificate. It is similar to "prefer" in a sense that it allows the
absence of availability of an SSL connection. (In a similar way to
"prefer", we could "fall back" to "no client cert" SSL connection
after verification failure but I think it's not worth doing.)

"prefer-verify" seems right in that sense. But I'm not sure we may
break backward compatibility for the reason.

> > ===
> > When <literal>clientcert</literal> is not specified or is set
> > to<literal>no-verify</literal>, clients can connect to server without
> > having a client certificate.
> > 
> > Note: Regardless of the setting of <literal>clientcert</literal>,
> > connection can end with failure if a client certificate that cannot be
> > verified by the server is stored in the ~/.postgresql directory.
> > ===
> > 
> > By the way, the following table line might need to be changed?
> > 
> > libpq-ssl.html:
> > 
> > >      <entry><filename>~/.postgresql/postgresql.crt</filename></entry>
> > >      <entry>client certificate</entry>
> > -      <entry>requested by server</entry>
> > 
> > The file is actually not requested by server, client just pushes to
> > server if any, unconditionally.
> > 
> > +      <entry>sent to server</entry>
> 
> I have just applied this change to all branches, since it is an
> independent fix.  Thanks.

Thanks.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Bruce Momjian

Date:

26 August 2020, 05:52:44

On Wed, Aug 26, 2020 at 11:41:39AM +0900, Kyotaro Horiguchi wrote:
> At Tue, 25 Aug 2020 10:04:44 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > I think there are a few problems here.  In the docs, it says "will still
> > verify", but it doesn't say if it verifies the CA, or the CA _and_ the
> > CN/username.
> 
> It verifies only CA.

OK, that will need to be clarified.

> > Second, since it is optional, what value does it have?
> > 
> > > > Why is this useful?
> > > 
> > > I agree, but there seems to be an implementation reason for the
> > > behavior. To identify an hba-line, some connection parameters like
> > > user name and others sent over a connection is required.  Thus the
> > > clientcert option in the to-be-identified hba-line is unknown prior to
> > > the time SSL connection is made. So the documentation might need
> > > amendment. Roughly something like the following?
> > 
> > Well, I realize internally we need a way to indicate clientcert is not
> > used, but why do we bother exposing that to the user as a named option?
> 
> Because we think we need any named value for every alternatives
> including the default value?

Well, not putting clientcert at all gives the default behavior, so why
have clientcert=no-verify?

> > And you are right that the option name 'no-verify' is wrong since it
> > will verify the CA if it exists, so it more like 'optionally-verify',
> > which seems useless from a user interface perspective.
> > 
> > I guess the behavior of no-verify matches our client-side
> > sslmode=prefer, but at least that has the value of using SSL if
> > available, which prevents user-visible network traffic, but doesn't
> > force it, but I am not sure what the value of optional certificate
> > verification is, since verification is all it does.  I guess it should
> > be called "prefer-verify".
> 
> The point of no-verify is to allow the absence of client
> certificate. It is similar to "prefer" in a sense that it allows the
> absence of availability of an SSL connection. (In a similar way to
> "prefer", we could "fall back" to "no client cert" SSL connection
> after verification failure but I think it's not worth doing.)

Well, sslmode=prefer gives encryption without identification. 
clientcert=no-verify has no value because it is just an optional CA
check that has no value because optional authentication is useless.  It
is like saying you can type in the password if you want, and we will
check it, or you can just not type in the password.

> "prefer-verify" seems right in that sense. But I'm not sure we may
> break backward compatibility for the reason.

True, but right now it is inaccurate so I think it just need to be fixed
or removed and documented in the PG 14 release notes.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Kyotaro Horiguchi

Date:

26 August 2020, 12:13:23

At Tue, 25 Aug 2020 22:52:44 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> On Wed, Aug 26, 2020 at 11:41:39AM +0900, Kyotaro Horiguchi wrote:
> > At Tue, 25 Aug 2020 10:04:44 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > > I think there are a few problems here.  In the docs, it says "will still
> > > verify", but it doesn't say if it verifies the CA, or the CA _and_ the
> > > CN/username.
> > 
> > It verifies only CA.
> 
> OK, that will need to be clarified.
> 
> > > Second, since it is optional, what value does it have?
> > > 
> > > > > Why is this useful?
> > > > 
> > > > I agree, but there seems to be an implementation reason for the
> > > > behavior. To identify an hba-line, some connection parameters like
> > > > user name and others sent over a connection is required.  Thus the
> > > > clientcert option in the to-be-identified hba-line is unknown prior to
> > > > the time SSL connection is made. So the documentation might need
> > > > amendment. Roughly something like the following?
> > > 
> > > Well, I realize internally we need a way to indicate clientcert is not
> > > used, but why do we bother exposing that to the user as a named option?
> > 
> > Because we think we need any named value for every alternatives
> > including the default value?
> 
> Well, not putting clientcert at all gives the default behavior, so why
> have clientcert=no-verify?

clientcert=verify-ca or verify-full don't allow absence of client
certificate. We need an option to allow the absence.

> > > And you are right that the option name 'no-verify' is wrong since it
> > > will verify the CA if it exists, so it more like 'optionally-verify',
> > > which seems useless from a user interface perspective.
> > > 
> > > I guess the behavior of no-verify matches our client-side
> > > sslmode=prefer, but at least that has the value of using SSL if
> > > available, which prevents user-visible network traffic, but doesn't
> > > force it, but I am not sure what the value of optional certificate
> > > verification is, since verification is all it does.  I guess it should
> > > be called "prefer-verify".
> > 
> > The point of no-verify is to allow the absence of client
> > certificate. It is similar to "prefer" in a sense that it allows the
> > absence of availability of an SSL connection. (In a similar way to
> > "prefer", we could "fall back" to "no client cert" SSL connection
> > after verification failure but I think it's not worth doing.)
> 
> Well, sslmode=prefer gives encryption without identification. 
> clientcert=no-verify has no value because it is just an optional CA
> check that has no value because optional authentication is useless.  It

The point of the option is not to do optional CA check if possible,
but to allow absence of client cert. We need to have that mode
regardless of named or not named, and I believe we usually provide a
name for default mode.

> is like saying you can type in the password if you want, and we will
> check it, or you can just not type in the password.

Yes, since the point is the fact that I'm allowed to skip typing a
password. And the reason for the strange-looking behavior is that I
can't help entering a password if I had, but the server has no way
other than checking the password that I provided.

In the correct words, the server cannot ignore the certificate if
client sent it. But the client cannot identify whether the certificate
is needed by the server before sending it.

> > "prefer-verify" seems right in that sense. But I'm not sure we may
> > break backward compatibility for the reason.
> 
> True, but right now it is inaccurate so I think it just need to be fixed
> or removed and documented in the PG 14 release notes.

I'm fine with that.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Bruce Momjian

Date:

27 August 2020, 01:36:50

On Wed, Aug 26, 2020 at 06:13:23PM +0900, Kyotaro Horiguchi wrote:
> At Tue, 25 Aug 2020 22:52:44 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > > Because we think we need any named value for every alternatives
> > > including the default value?
> > 
> > Well, not putting clientcert at all gives the default behavior, so why
> > have clientcert=no-verify?
> 
> clientcert=verify-ca or verify-full don't allow absence of client
> certificate. We need an option to allow the absence.

Isn't the option not specifying clientcert?  Here are some valid
pg_hba.conf lines:

    hostssl    all             all             127.0.0.1/32         trust clientcert=verify-full
    hostssl    all             all             127.0.0.1/32         trust clientcert=verify-ca
    hostssl    all             all             127.0.0.1/32         trust clientcert=no-verify
    hostssl    all             all             127.0.0.1/32         trust

It is my understanding that the last two lines are the same.  Why isn't
it sufficient to just tell users not to specify clientcert if they want
the default behavior?  You can do:

    host    all             all             192.168.0.0/16          ident map=omicron

but there is no way to specify the default map value of 'no map', so why
have one for clientcert?

> > Well, sslmode=prefer gives encryption without identification. 
> > clientcert=no-verify has no value because it is just an optional CA
> > check that has no value because optional authentication is useless.  It
> 
> The point of the option is not to do optional CA check if possible,
> but to allow absence of client cert. We need to have that mode
> regardless of named or not named, and I believe we usually provide a
> name for default mode.

Uh, see above --- not really.  The absense of the option is the default
action.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Kyotaro Horiguchi

Date:

27 August 2020, 10:09:25

At Wed, 26 Aug 2020 18:36:50 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
bruce> On Wed, Aug 26, 2020 at 06:13:23PM +0900, Kyotaro Horiguchi wrote:
> > At Tue, 25 Aug 2020 22:52:44 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > > > Because we think we need any named value for every alternatives
> > > > including the default value?
> > > 
> > > Well, not putting clientcert at all gives the default behavior, so why
> > > have clientcert=no-verify?
> > 
> > clientcert=verify-ca or verify-full don't allow absence of client
> > certificate. We need an option to allow the absence.
> 
> Isn't the option not specifying clientcert?  Here are some valid
> pg_hba.conf lines:

Sorry for the ambiguity. Perhaps I understand that we talked at
different objects.  I was mentioning about the option value that is
stored *internally*, concretely the values for the struct member
port->hba->clientcert. You are talking about the descriptive option in
pg_hba.conf.

Does the following discussion make sense?

We need to use the default value zero (=clientCertOff) for
port->hba->clientcert to tell server to omit checking against CA if
cert is not given.  I suppose that the value clientCertOff is labeled
as "no-verify" since someone who developed this thought that that
choice needs to be explicitly describable in pg_hba.conf. And my
discussion was following that decision.

I understand that the label "no-verify" is not essential to specify
the behavior, so I don't object to removing "no-verify" label itself
if no one oppose to remove it.

My point here is just "are we OK to remove it?"

> It is my understanding that the last two lines are the same.  Why isn't
> it sufficient to just tell users not to specify clientcert if they want
> the default behavior?  You can do:
> 
>     host    all             all             192.168.0.0/16          ident map=omicron
> 
> but there is no way to specify the default map value of 'no map', so why
> have one for clientcert?

The difference from clientcert is that it gives an arbitrary name that
points to a defined mapping, not a choice from an defined
enumeration. 

> > > Well, sslmode=prefer gives encryption without identification.
> > > clientcert=no-verify has no value because it is just an optional CA
> > > check that has no value because optional authentication is useless.  It
> > 
> > The point of the option is not to do optional CA check if possible,
> > but to allow absence of client cert. We need to have that mode
> > regardless of named or not named, and I believe we usually provide a
> > name for default mode.
> 
> Uh, see above --- not really.  The absense of the option is the default
> action.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Bruce Momjian

Date:

27 August 2020, 22:41:40

On Thu, Aug 27, 2020 at 04:09:25PM +0900, Kyotaro Horiguchi wrote:
> At Wed, 26 Aug 2020 18:36:50 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> bruce> On Wed, Aug 26, 2020 at 06:13:23PM +0900, Kyotaro Horiguchi wrote:
> > > At Tue, 25 Aug 2020 22:52:44 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > > > > Because we think we need any named value for every alternatives
> > > > > including the default value?
> > > > 
> > > > Well, not putting clientcert at all gives the default behavior, so why
> > > > have clientcert=no-verify?
> > > 
> > > clientcert=verify-ca or verify-full don't allow absence of client
> > > certificate. We need an option to allow the absence.
> > 
> > Isn't the option not specifying clientcert?  Here are some valid
> > pg_hba.conf lines:
> 
> Sorry for the ambiguity. Perhaps I understand that we talked at
> different objects.  I was mentioning about the option value that is
> stored *internally*, concretely the values for the struct member
> port->hba->clientcert. You are talking about the descriptive option in
> pg_hba.conf.
> 
> Does the following discussion make sense?
> 
> We need to use the default value zero (=clientCertOff) for
> port->hba->clientcert to tell server to omit checking against CA if
> cert is not given.  I suppose that the value clientCertOff is labeled
> as "no-verify" since someone who developed this thought that that
> choice needs to be explicitly describable in pg_hba.conf. And my
> discussion was following that decision.
> 
> I understand that the label "no-verify" is not essential to specify
> the behavior, so I don't object to removing "no-verify" label itself
> if no one oppose to remove it.
> 
> My point here is just "are we OK to remove it?"

Yes, in PG 14.  Security is confusing enough, so having a mis-named
option that doesn't do anything more than just not specifying clientcert
is not useful and should be removed.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Bruce Momjian

Date:

27 August 2020, 22:59:43

On Thu, Aug 27, 2020 at 03:41:40PM -0400, Bruce Momjian wrote:
> On Thu, Aug 27, 2020 at 04:09:25PM +0900, Kyotaro Horiguchi wrote:
> > At Wed, 26 Aug 2020 18:36:50 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > bruce> On Wed, Aug 26, 2020 at 06:13:23PM +0900, Kyotaro Horiguchi wrote:
> > > > At Tue, 25 Aug 2020 22:52:44 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > > > > > Because we think we need any named value for every alternatives
> > > > > > including the default value?
> > > > > 
> > > > > Well, not putting clientcert at all gives the default behavior, so why
> > > > > have clientcert=no-verify?
> > > > 
> > > > clientcert=verify-ca or verify-full don't allow absence of client
> > > > certificate. We need an option to allow the absence.
> > > 
> > > Isn't the option not specifying clientcert?  Here are some valid
> > > pg_hba.conf lines:
> > 
> > Sorry for the ambiguity. Perhaps I understand that we talked at
> > different objects.  I was mentioning about the option value that is
> > stored *internally*, concretely the values for the struct member
> > port->hba->clientcert. You are talking about the descriptive option in
> > pg_hba.conf.

Yes, I realize we need an internal vaue for this, but it doesn't need to
be visible to the user.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Kyotaro Horiguchi

Date:

31 August 2020, 11:56:58

Hello, Bruce.

At Thu, 27 Aug 2020 15:41:40 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > My point here is just "are we OK to remove it?"
> 
> Yes, in PG 14.  Security is confusing enough, so having a mis-named
> option that doesn't do anything more than just not specifying clientcert
> is not useful and should be removed.

Ok, this is that. If we spcify clientcert=no-verify other than for
"cert" authentication, server complains as the following at startup.

> LOG:  no-verify or 0 is the default setting that is discouraged to use explicitly for clientcert option
> HINT:  Consider removing the option instead. This option value is going to be deprecated in later version.
> CONTEXT:  line 90 of configuration file "/home/horiguti/data/data_noverify/pg_hba.conf"

And, cert clientcert=verifry-ca (and no-verify) is correctly rejected.

> LOG:  clientcert accepts only "verify-full" when using "cert" authentication

I once I thought that the deprecation message should e WARNING but
later I changed my mind to change it to LOG unifying to surrounding
setting error messages.

I'm going to register this to the coming CF.

regrds.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center
From 32b2c8fc410c174541141a92897997b6349a9434 Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi <horikyoga.ntt@gmail.com>
Date: Mon, 31 Aug 2020 17:23:18 +0900
Subject: [PATCH] Prepare for deprecating no-verify for clientcert

The option "no-verify" does something that is not intuitively inferred
from its name. It is the alias for the default behavior that lets
server verify the certificate against CA if the both are
available. It's confusing and doesn't offer any advantage, so we are
going to deprecate it. Warn if clientcert is specified with the value
"no-verify".

This also fixes an inconsistent behavior that the "cert"
authentication silently upgrades clientcert="verify-ca" to
"verify-full".
---
 doc/src/sgml/runtime.sgml |  8 ++++----
 src/backend/libpq/hba.c   | 32 ++++++++++++++++++++++----------
 2 files changed, 26 insertions(+), 14 deletions(-)

diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index c8698898f3..6ba2293b68 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -2279,10 +2279,10 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433
   <para>
    The <literal>clientcert</literal> authentication option is available for
    all authentication methods, but only in <filename>pg_hba.conf</filename> lines
-   specified as <literal>hostssl</literal>.  When <literal>clientcert</literal> is
-   not specified or is set to <literal>no-verify</literal>, the server will still
-   verify any presented client certificates against its CA file, if one is
-   configured — but it will not insist that a client certificate be presented.
+   specified as <literal>hostssl</literal>.
+   When <literal>clientcert</literal> is not specified, the server verifies
+   the client certificate against its CA file only if any client certificate
+   is presented and the CA is configured.
   </para>
 
   <para>
diff --git a/src/backend/libpq/hba.c b/src/backend/libpq/hba.c
index 9d63830553..4d0145782b 100644
--- a/src/backend/libpq/hba.c
+++ b/src/backend/libpq/hba.c
@@ -1708,6 +1708,21 @@ parse_hba_auth_opt(char *name, char *val, HbaLine *hbaline,
             *err_msg = "clientcert can only be configured for \"hostssl\" rows";
             return false;
         }
+
+        /* check for incompatible combinations */
+        if (hbaline->auth_method == uaCert &&
+            (strcmp(val, "0") == 0 || strcmp(val, "no-verify") == 0
+             strcmp(val, "1") == 0 || strcmp(val, "verify-ca") == 0)
+            {
+            ereport(elevel,
+                    (errcode(ERRCODE_CONFIG_FILE_ERROR),
+                     errmsg("clientcert accepts only \"verify-full\" when using \"cert\" authentication"),
+                         errcontext("line %d of configuration file \"%s\"",
+                                    line_num, HbaFileName)));
+            *err_msg = "clientcert can not be set to other than \"verify-full\" when using \"cert\" authentication";
+            return false;
+        }
+
         if (strcmp(val, "1") == 0
             || strcmp(val, "verify-ca") == 0)
         {
@@ -1717,19 +1732,16 @@ parse_hba_auth_opt(char *name, char *val, HbaLine *hbaline,
         {
             hbaline->clientcert = clientCertFull;
         }
+        /* XXXX: no-verify is going to be deprecated */
         else if (strcmp(val, "0") == 0
                  || strcmp(val, "no-verify") == 0)
         {
-            if (hbaline->auth_method == uaCert)
-            {
-                ereport(elevel,
-                        (errcode(ERRCODE_CONFIG_FILE_ERROR),
-                         errmsg("clientcert can not be set to \"no-verify\" when using \"cert\" authentication"),
-                         errcontext("line %d of configuration file \"%s\"",
-                                    line_num, HbaFileName)));
-                *err_msg = "clientcert can not be set to \"no-verify\" when using \"cert\" authentication";
-                return false;
-            }
+            ereport(elevel,
+                    (errcode(ERRCODE_CONFIG_FILE_ERROR),
+                     errmsg("no-verify or 0 is the default setting that is discouraged to use explicitly for
clientcertoption"),
 
+                     errhint("Consider removing the option instead. This option value is going to be deprecated in
laterversion."),
 
+                     errcontext("line %d of configuration file \"%s\"",
+                                line_num, HbaFileName)));
             hbaline->clientcert = clientCertOff;
         }
         else
-- 
2.18.4

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Bruce Momjian

Date:

31 August 2020, 18:34:29

On Mon, Aug 31, 2020 at 05:56:58PM +0900, Kyotaro Horiguchi wrote:
> Hello, Bruce.
> 
> At Thu, 27 Aug 2020 15:41:40 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > > My point here is just "are we OK to remove it?"
> > 
> > Yes, in PG 14.  Security is confusing enough, so having a mis-named
> > option that doesn't do anything more than just not specifying clientcert
> > is not useful and should be removed.
> 
> Ok, this is that. If we spcify clientcert=no-verify other than for
> "cert" authentication, server complains as the following at startup.

Why does clientcert=no-verify have any value, even for a
cert-authentication line?

> > LOG:  no-verify or 0 is the default setting that is discouraged to use explicitly for clientcert option
> > HINT:  Consider removing the option instead. This option value is going to be deprecated in later version.
> > CONTEXT:  line 90 of configuration file "/home/horiguti/data/data_noverify/pg_hba.conf"

I think it should just be removed in PG 14.  This is a configuration
setting, not an SQL-level item that needs a deprecation period.

> And, cert clientcert=verifry-ca (and no-verify) is correctly rejected.
> 
> > LOG:  clientcert accepts only "verify-full" when using "cert" authentication
> 
> I once I thought that the deprecation message should e WARNING but
> later I changed my mind to change it to LOG unifying to surrounding
> setting error messages.
> 
> I'm going to register this to the coming CF.

I plan to apply this once we are done discussing it.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Kyotaro Horiguchi

Date:

01 September 2020, 07:59:25

At Mon, 31 Aug 2020 11:34:29 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> On Mon, Aug 31, 2020 at 05:56:58PM +0900, Kyotaro Horiguchi wrote:
> > Ok, this is that. If we spcify clientcert=no-verify other than for
> > "cert" authentication, server complains as the following at startup.
> 
> Why does clientcert=no-verify have any value, even for a
> cert-authentication line?
> 
> > > LOG:  no-verify or 0 is the default setting that is discouraged to use explicitly for clientcert option
> > > HINT:  Consider removing the option instead. This option value is going to be deprecated in later version.
> > > CONTEXT:  line 90 of configuration file "/home/horiguti/data/data_noverify/pg_hba.conf"
> 
> I think it should just be removed in PG 14.  This is a configuration
> setting, not an SQL-level item that needs a deprecation period.

Ok, it is changed to just error out. I tempted to show a suggestion to
removing the option in that case like the following, but *didn't* in
this version of the patch.

 > LOG:  invalid value for clientcert: "no-verify"
?? HINT:  Instead, consider removing the clinetcert option.
 > CONTEXT:  line 90 of configuration file "/h


> > I'm going to register this to the coming CF.
> 
> I plan to apply this once we are done discussing it.

Roger.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center
From 3ef1d3eee86998be934eb67d55d89d965381f5d2 Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi <horikyoga.ntt@gmail.com>
Date: Mon, 31 Aug 2020 17:23:18 +0900
Subject: [PATCH v2] Deprecate no-verify for clientcert

The option "no-verify" does something that is not intuitively inferred
from its name. It is the alias for the default behavior that lets
server verify the certificate against CA only if the both are
available. It's confusing and doesn't offer any advantage, so we
deprecate it. Error out and suggest to remove the option if clientcert
is specified with the value "no-verify". The legacy values "0" and "1"
are also deprecated together.

This also fixes an inconsistent behavior that the "cert"
authentication silently upgrades clientcert="verify-ca" to
"verify-full".
---
 doc/src/sgml/client-auth.sgml | 11 +++++------
 doc/src/sgml/runtime.sgml     |  5 ++---
 src/backend/libpq/hba.c       | 33 ++++++++++++++++-----------------
 3 files changed, 23 insertions(+), 26 deletions(-)

diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
index 5cd88b462d..03248b3d63 100644
--- a/doc/src/sgml/client-auth.sgml
+++ b/doc/src/sgml/client-auth.sgml
@@ -2043,12 +2043,11 @@ host ... radius radiusservers="server1,server2" radiussecrets="""secret one"",""
 
    <para>
     In a <filename>pg_hba.conf</filename> record specifying certificate
-    authentication, the authentication option <literal>clientcert</literal> is
-    assumed to be <literal>verify-ca</literal> or <literal>verify-full</literal>,
-    and it cannot be turned off since a client certificate is necessary for this
-    method. What the <literal>cert</literal> method adds to the basic
-    <literal>clientcert</literal> certificate validity test is a check that the
-    <literal>cn</literal> attribute matches the database user name.
+    authentication is equivalent to the <literal>trust</literal>
+    authentication having the authentication
+    option <literal>clientcert</literal> with the
+    value <literal>verify-full</literal> and it cannot be turned off or
+    downgraded to <literal>verify-ca</literal>.
    </para>
   </sect1>
 
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 6cda39f3ab..0f4190d71c 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -2282,9 +2282,8 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433
    The <literal>clientcert</literal> authentication option is available for
    all authentication methods, but only in <filename>pg_hba.conf</filename> lines
    specified as <literal>hostssl</literal>.  When <literal>clientcert</literal> is
-   not specified or is set to <literal>no-verify</literal>, the server will still
-   verify any presented client certificates against its CA file, if one is
-   configured — but it will not insist that a client certificate be presented.
+   not specified, the server verifies the client certificate against its CA
+   file only if any client certificate is presented and the CA is configured.
   </para>
 
   <para>
diff --git a/src/backend/libpq/hba.c b/src/backend/libpq/hba.c
index 9d63830553..b702c8a419 100644
--- a/src/backend/libpq/hba.c
+++ b/src/backend/libpq/hba.c
@@ -1708,35 +1708,34 @@ parse_hba_auth_opt(char *name, char *val, HbaLine *hbaline,
             *err_msg = "clientcert can only be configured for \"hostssl\" rows";
             return false;
         }
-        if (strcmp(val, "1") == 0
-            || strcmp(val, "verify-ca") == 0)
+
+        if (strcmp(val, "verify-ca") == 0)
         {
+            if (hbaline->auth_method == uaCert)
+            {
+                ereport(elevel,
+                        (errcode(ERRCODE_CONFIG_FILE_ERROR),
+                         errmsg("clientcert accepts only \"verify-full\" when using \"cert\" authentication"),
+                         errcontext("line %d of configuration file \"%s\"",
+                                    line_num, HbaFileName)));
+                *err_msg = "clientcert can not be set to other than \"verify-full\" when using \"cert\"
authentication";
+                return false;
+            }
+
             hbaline->clientcert = clientCertCA;
         }
         else if (strcmp(val, "verify-full") == 0)
         {
             hbaline->clientcert = clientCertFull;
         }
-        else if (strcmp(val, "0") == 0
-                 || strcmp(val, "no-verify") == 0)
-        {
-            if (hbaline->auth_method == uaCert)
-            {
-                ereport(elevel,
-                        (errcode(ERRCODE_CONFIG_FILE_ERROR),
-                         errmsg("clientcert can not be set to \"no-verify\" when using \"cert\" authentication"),
-                         errcontext("line %d of configuration file \"%s\"",
-                                    line_num, HbaFileName)));
-                *err_msg = "clientcert can not be set to \"no-verify\" when using \"cert\" authentication";
-                return false;
-            }
-            hbaline->clientcert = clientCertOff;
-        }
         else
         {
             ereport(elevel,
                     (errcode(ERRCODE_CONFIG_FILE_ERROR),
                      errmsg("invalid value for clientcert: \"%s\"", val),
+                     /* no-verify is an obsolete value */
+                     (strcmp(val, "no-verify") == 0 ?
+                      errhint("Instead, consider removing the clinetcert option."):0),
                      errcontext("line %d of configuration file \"%s\"",
                                 line_num, HbaFileName)));
             return false;
-- 
2.18.4

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Bruce Momjian

Date:

01 September 2020, 18:47:34

On Tue, Sep  1, 2020 at 01:59:25PM +0900, Kyotaro Horiguchi wrote:
> At Mon, 31 Aug 2020 11:34:29 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > On Mon, Aug 31, 2020 at 05:56:58PM +0900, Kyotaro Horiguchi wrote:
> > > Ok, this is that. If we spcify clientcert=no-verify other than for
> > > "cert" authentication, server complains as the following at startup.
> > 
> > Why does clientcert=no-verify have any value, even for a
> > cert-authentication line?
> > 
> > > > LOG:  no-verify or 0 is the default setting that is discouraged to use explicitly for clientcert option
> > > > HINT:  Consider removing the option instead. This option value is going to be deprecated in later version.
> > > > CONTEXT:  line 90 of configuration file "/home/horiguti/data/data_noverify/pg_hba.conf"
> > 
> > I think it should just be removed in PG 14.  This is a configuration
> > setting, not an SQL-level item that needs a deprecation period.
> 
> Ok, it is changed to just error out. I tempted to show a suggestion to
> removing the option in that case like the following, but *didn't* in
> this version of the patch.

OK, I have developed the attached patch based on yours.  I reordered the
tests, simplified the documentation, and removed the hint since they
will already get a good error message, and we will document this change
in the release notes.  It is also good you removed the 0/1 values for
this, since that was also confusing.  We will put that removal in the
release notes too.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee

Attachment

cert.diff

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Kyotaro Horiguchi

Date:

02 September 2020, 04:45:30

Hello.

At Tue, 1 Sep 2020 11:47:34 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> On Tue, Sep  1, 2020 at 01:59:25PM +0900, Kyotaro Horiguchi wrote:
> > At Mon, 31 Aug 2020 11:34:29 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > > On Mon, Aug 31, 2020 at 05:56:58PM +0900, Kyotaro Horiguchi wrote:
> > > > Ok, this is that. If we spcify clientcert=no-verify other than for
> > > > "cert" authentication, server complains as the following at startup.
> > > 
> > > Why does clientcert=no-verify have any value, even for a
> > > cert-authentication line?
> > > 
> > > > > LOG:  no-verify or 0 is the default setting that is discouraged to use explicitly for clientcert option
> > > > > HINT:  Consider removing the option instead. This option value is going to be deprecated in later version.
> > > > > CONTEXT:  line 90 of configuration file "/home/horiguti/data/data_noverify/pg_hba.conf"
> > > 
> > > I think it should just be removed in PG 14.  This is a configuration
> > > setting, not an SQL-level item that needs a deprecation period.
> > 
> > Ok, it is changed to just error out. I tempted to show a suggestion to
> > removing the option in that case like the following, but *didn't* in
> > this version of the patch.
> 
> OK, I have developed the attached patch based on yours.  I reordered the
> tests, simplified the documentation, and removed the hint since they

Looks good to me.

> will already get a good error message, and we will document this change

Oops! I thought I had removed that in the patch. Sorry for the mistake
and that also looks good to me.

> in the release notes.  It is also good you removed the 0/1 values for
> this, since that was also confusing.  We will put that removal in the
> release notes too.

Thank you for your assistance, Bruce!

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Bruce Momjian

Date:

02 September 2020, 05:27:03

On Wed, Sep  2, 2020 at 10:45:30AM +0900, Kyotaro Horiguchi wrote:
> At Tue, 1 Sep 2020 11:47:34 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > OK, I have developed the attached patch based on yours.  I reordered the
> > tests, simplified the documentation, and removed the hint since they
> 
> Looks good to me.
> 
> > will already get a good error message, and we will document this change
> 
> Oops! I thought I had removed that in the patch. Sorry for the mistake
> and that also looks good to me.
> 
> > in the release notes.  It is also good you removed the 0/1 values for
> > this, since that was also confusing.  We will put that removal in the
> > release notes too.
> 
> Thank you for your assistance, Bruce!

OK, good.  Let's wait a few days and I will then apply it for PG 14.
Thanks.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Kyotaro Horiguchi

Date:

25 September 2020, 03:33:48

At Thu, 24 Sep 2020 11:43:40 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> On Thu, Sep 24, 2020 at 12:44:01PM +0900, Michael Paquier wrote:
> > On Tue, Sep 01, 2020 at 10:27:03PM -0400, Bruce Momjian wrote:
> > > OK, good.  Let's wait a few days and I will then apply it for PG 14.
> > 
> > It has been a few days, and nothing has happened here.  I have not
> > looked at the patch in details, so I cannot say if that's fine or not,
> > but please note that the patch fails to apply per the CF bot.
> 
> I will handle it.

Thank you Bruce, Michael. This is a rebased version.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center
From 2978479ada887284eae0ed36c8acf29f1a002feb Mon Sep 17 00:00:00 2001
From: Kyotaro Horiguchi <horikyoga.ntt@gmail.com>
Date: Tue, 21 Jul 2020 23:01:27 +0900
Subject: [PATCH v2] Allow directory name for GUC ssl_crl_file and connection
 option sslcrl

X509_STORE_load_locations accepts a directory, which leads to
on-demand loading method with which method only relevant CRLs are
loaded.
---
 doc/src/sgml/config.sgml                      | 10 ++--
 doc/src/sgml/libpq.sgml                       |  8 ++--
 doc/src/sgml/runtime.sgml                     | 30 ++++++++++++
 src/backend/libpq/be-secure-openssl.c         | 12 ++++-
 src/interfaces/libpq/fe-secure-openssl.c      | 12 ++++-
 src/test/ssl/Makefile                         | 20 +++++++-
 src/test/ssl/ssl/both-cas-1.crt               | 46 +++++++++----------
 src/test/ssl/ssl/both-cas-2.crt               | 46 +++++++++----------
 src/test/ssl/ssl/client+client_ca.crt         | 28 +++++------
 src/test/ssl/ssl/client-crldir/9bb9e3c3.r0    | 11 +++++
 src/test/ssl/ssl/client-revoked.crt           | 14 +++---
 src/test/ssl/ssl/client.crl                   | 16 +++----
 src/test/ssl/ssl/client.crt                   | 14 +++---
 src/test/ssl/ssl/client_ca.crt                | 14 +++---
 .../ssl/ssl/root+client-crldir/9bb9e3c3.r0    | 11 +++++
 .../ssl/ssl/root+client-crldir/a3d11bff.r0    | 11 +++++
 src/test/ssl/ssl/root+client.crl              | 32 ++++++-------
 src/test/ssl/ssl/root+client_ca.crt           | 32 ++++++-------
 .../ssl/ssl/root+server-crldir/a3d11bff.r0    | 11 +++++
 .../ssl/ssl/root+server-crldir/a836cc2d.r0    | 11 +++++
 src/test/ssl/ssl/root+server.crl              | 32 ++++++-------
 src/test/ssl/ssl/root+server_ca.crt           | 32 ++++++-------
 src/test/ssl/ssl/root.crl                     | 16 +++----
 src/test/ssl/ssl/root_ca.crt                  | 18 ++++----
 src/test/ssl/ssl/server-cn-and-alt-names.crt  | 14 +++---
 src/test/ssl/ssl/server-cn-only.crt           | 14 +++---
 src/test/ssl/ssl/server-crldir/a836cc2d.r0    | 11 +++++
 .../ssl/ssl/server-multiple-alt-names.crt     | 14 +++---
 src/test/ssl/ssl/server-no-names.crt          | 16 +++----
 src/test/ssl/ssl/server-revoked.crt           | 14 +++---
 src/test/ssl/ssl/server-single-alt-name.crt   | 16 +++----
 src/test/ssl/ssl/server-ss.crt                | 18 ++++----
 src/test/ssl/ssl/server.crl                   | 16 +++----
 src/test/ssl/ssl/server_ca.crt                | 14 +++---
 src/test/ssl/t/001_ssltests.pl                | 31 ++++++++++++-
 src/test/ssl/t/SSLServer.pm                   |  5 +-
 36 files changed, 418 insertions(+), 252 deletions(-)
 create mode 100644 src/test/ssl/ssl/client-crldir/9bb9e3c3.r0
 create mode 100644 src/test/ssl/ssl/root+client-crldir/9bb9e3c3.r0
 create mode 100644 src/test/ssl/ssl/root+client-crldir/a3d11bff.r0
 create mode 100644 src/test/ssl/ssl/root+server-crldir/a3d11bff.r0
 create mode 100644 src/test/ssl/ssl/root+server-crldir/a836cc2d.r0
 create mode 100644 src/test/ssl/ssl/server-crldir/a836cc2d.r0

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 8eabf93834..1ec4b54fcd 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1182,11 +1182,11 @@ include_dir 'conf.d'
       <listitem>
        <para>
         Specifies the name of the file containing the SSL server certificate
-        revocation list (CRL).
-        Relative paths are relative to the data directory.
-        This parameter can only be set in the <filename>postgresql.conf</filename>
-        file or on the server command line.
-        The default is empty, meaning no CRL file is loaded.
+        revocation list (CRL) or the directory containing CRL files.  Relative
+        paths are relative to the data directory.  This parameter can only be
+        set in the <filename>postgresql.conf</filename> file or on the server
+        command line.  The default is empty, meaning no CRL file is
+        loaded. See <xref linkend="ssl-crl-files"/> for details.
        </para>
       </listitem>
      </varlistentry>
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 3315f1dd05..1de85612f3 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -1711,10 +1711,12 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
       <listitem>
        <para>
         This parameter specifies the file name of the SSL certificate
-        revocation list (CRL).  Certificates listed in this file, if it
-        exists, will be rejected while attempting to authenticate the
+        revocation list (CRL) or the directory name that contains CRL files.
+        Certificates listed in this file or in the files in this directoty, if
+        it exists, will be rejected while attempting to authenticate the
         server's certificate.  The default is
-        <filename>~/.postgresql/root.crl</filename>.
+        <filename>~/.postgresql/root.crl</filename>. See
+        <xref linkend="ssl-crl-files"/> for details.
        </para>
       </listitem>
      </varlistentry>
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index f975406acd..54a968fa3e 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -2551,6 +2551,36 @@ openssl x509 -req -in server.csr -text -days 365 \
    </para>
   </sect2>
 
+  <sect2 id="ssl-crl-files">
+    <title>Certification Revocation List files</title>
+
+    <para> The server setting <xref linkend="guc-ssl-crl-file"/> and the
+    connection option <xref linkend="libpq-connect-sslcrl"/> specify either a
+    file containing one or more CRL, or a directory containing a separate file
+    for every CRL. In the first method, file method, the all CRLs in the file
+    is loaded at server start time or by reloading config file
+    (<command>pg_ctl reload</command>). In the second method, hashed directory
+    method, CRL files are loaded on-demand, that is, only the relevant CRL
+    files are loaded at connection time.
+    </para>
+    <para>
+    The CRL file used for the file method can contain multiple CRLs, like
+    certificates, by just concatenated if it is in PEM format.  In the hashed
+    directory method, every file in the directory has the name
+    with <parameter>hash</parameter>.r<parameter>N</parameter> format,
+    where <parameter>hash</parameter> is the hash value of the issuer of the
+    CRL and <parameter>N</parameter> is a sequence number that starts at
+    zero. The hash value is calculated using openssl command. In both cases
+    the CRLs from all CAs involved in a certificate chain are needed to verify
+    a certificate, even if some or all of them are empty.
+<programlisting>
+$ openssl crl -hash -noout -in foo.crl
+98668507
+$ cp foo.crl $PGDATA/crldir/98668507.r0
+</programlisting>
+    </para>
+  </sect2>
+
  </sect1>
 
  <sect1 id="gssapi-enc">
diff --git a/src/backend/libpq/be-secure-openssl.c b/src/backend/libpq/be-secure-openssl.c
index 8b21ff4065..d85dc710a4 100644
--- a/src/backend/libpq/be-secure-openssl.c
+++ b/src/backend/libpq/be-secure-openssl.c
@@ -289,8 +289,18 @@ be_tls_init(bool isServerStart)
 
         if (cvstore)
         {
+            char *filename = NULL;
+            char *dirname = NULL;
+            struct stat statbuf;
+
+            /* identify whether it is a file or a directoty */
+            if (stat(ssl_crl_file, &statbuf) == 0 && S_ISDIR(statbuf.st_mode))
+                dirname = ssl_crl_file;
+            else
+                filename = ssl_crl_file;
+
             /* Set the flags to check against the complete CRL chain */
-            if (X509_STORE_load_locations(cvstore, ssl_crl_file, NULL) == 1)
+            if (X509_STORE_load_locations(cvstore, filename, dirname) == 1)
             {
                 X509_STORE_set_flags(cvstore,
                                      X509_V_FLAG_CRL_CHECK | X509_V_FLAG_CRL_CHECK_ALL);
diff --git a/src/interfaces/libpq/fe-secure-openssl.c b/src/interfaces/libpq/fe-secure-openssl.c
index d609a38bbe..1ae60226b1 100644
--- a/src/interfaces/libpq/fe-secure-openssl.c
+++ b/src/interfaces/libpq/fe-secure-openssl.c
@@ -936,6 +936,10 @@ initialize_SSL(PGconn *conn)
 
         if ((cvstore = SSL_CTX_get_cert_store(SSL_context)) != NULL)
         {
+            char *filename = NULL;
+            char *dirname = NULL;
+            struct stat statbuf;
+
             if (conn->sslcrl && strlen(conn->sslcrl) > 0)
                 strlcpy(fnbuf, conn->sslcrl, sizeof(fnbuf));
             else if (have_homedir)
@@ -943,9 +947,15 @@ initialize_SSL(PGconn *conn)
             else
                 fnbuf[0] = '\0';
 
+            /* Identify whether it is a file or a directory */
+            if (stat(fnbuf, &statbuf) == 0 && S_ISDIR(statbuf.st_mode))
+                dirname = fnbuf;
+            else
+                filename = fnbuf;
+
             /* Set the flags to check against the complete CRL chain */
             if (fnbuf[0] != '\0' &&
-                X509_STORE_load_locations(cvstore, fnbuf, NULL) == 1)
+                X509_STORE_load_locations(cvstore, filename, dirname) == 1)
             {
                 X509_STORE_set_flags(cvstore,
                                      X509_V_FLAG_CRL_CHECK | X509_V_FLAG_CRL_CHECK_ALL);
diff --git a/src/test/ssl/Makefile b/src/test/ssl/Makefile
index 777ee39413..ccf2951770 100644
--- a/src/test/ssl/Makefile
+++ b/src/test/ssl/Makefile
@@ -30,12 +30,15 @@ SSLFILES := $(CERTIFICATES:%=ssl/%.key) $(CERTIFICATES:%=ssl/%.crt) \
     ssl/client+client_ca.crt ssl/client-der.key \
     ssl/client-encrypted-pem.key ssl/client-encrypted-der.key
 
+SSLDIRS := ssl/client-crldir ssl/server-crldir \
+    ssl/root+client-crldir ssl/root+server-crldir
+
 # This target re-generates all the key and certificate files. Usually we just
 # use the ones that are committed to the tree without rebuilding them.
 #
 # This target will fail unless preceded by sslfiles-clean.
 #
-sslfiles: $(SSLFILES)
+sslfiles: $(SSLFILES) $(SSLDIRS)
 
 # OpenSSL requires a directory to put all generated certificates in. We don't
 # use this for anything, but we need a location.
@@ -146,10 +149,25 @@ ssl/root+server.crl: ssl/root.crl ssl/server.crl
     cat $^ > $@
 ssl/root+client.crl: ssl/root.crl ssl/client.crl
     cat $^ > $@
+ssl/root+server-crldir: ssl/server.crl
+    mkdir ssl/root+server-crldir
+    cp ssl/server.crl ssl/root+server-crldir/`openssl crl -hash -noout -in ssl/server.crl`.r0
+    cp ssl/root.crl ssl/root+server-crldir/`openssl crl -hash -noout -in ssl/root.crl`.r0
+ssl/root+client-crldir: ssl/client.crl
+    mkdir ssl/root+client-crldir
+    cp ssl/client.crl ssl/root+client-crldir/`openssl crl -hash -noout -in ssl/client.crl`.r0
+    cp ssl/root.crl ssl/root+client-crldir/`openssl crl -hash -noout -in ssl/root.crl`.r0
+ssl/server-crldir: ssl/server.crl
+    mkdir ssl/server-crldir
+    cp ssl/server.crl ssl/server-crldir/`openssl crl -hash -noout -in ssl/server.crl`.r0
+ssl/client-crldir: ssl/client.crl
+    mkdir ssl/client-crldir
+    cp ssl/client.crl ssl/client-crldir/`openssl crl -hash -noout -in ssl/client.crl`.r0
 
 .PHONY: sslfiles-clean
 sslfiles-clean:
     rm -f $(SSLFILES) ssl/client_ca.srl ssl/server_ca.srl ssl/client_ca-certindex* ssl/server_ca-certindex*
ssl/root_ca-certindex*ssl/root_ca.srl ssl/temp_ca.crt ssl/temp_ca_signed.crt
 
+    rm -rf $(SSLDIRS)
 
 clean distclean maintainer-clean:
     rm -rf tmp_check
diff --git a/src/test/ssl/ssl/both-cas-1.crt b/src/test/ssl/ssl/both-cas-1.crt
index 37ffa10174..1ab329c8ab 100644
--- a/src/test/ssl/ssl/both-cas-1.crt
+++ b/src/test/ssl/ssl/both-cas-1.crt
@@ -1,8 +1,8 @@
 -----BEGIN CERTIFICATE-----
-MIIDHjCCAgagAwIBAgIUEAgXJ/ibw6TVTUoomlBsPMfVTlMwDQYJKoZIhvcNAQEL
+MIIDHjCCAgagAwIBAgIUbDho+LuL8GrZ/iVFY16vdG6kNo0wDQYJKoZIhvcNAQEL
 BQAwQDE+MDwGA1UEAww1VGVzdCByb290IENBIGZvciBQb3N0Z3JlU1FMIFNTTCBy
-ZWdyZXNzaW9uIHRlc3Qgc3VpdGUwHhcNMTgxMTI3MTM0MDU0WhcNNDYwNDE0MTM0
-MDU0WjBAMT4wPAYDVQQDDDVUZXN0IHJvb3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NM
+ZWdyZXNzaW9uIHRlc3Qgc3VpdGUwHhcNMjAwODMxMDYwNzIyWhcNNDgwMTE3MDYw
+NzIyWjBAMT4wPAYDVQQDDDVUZXN0IHJvb3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NM
 IHJlZ3Jlc3Npb24gdGVzdCBzdWl0ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
 AQoCggEBALZ81vKKBJlxgjwuNoK67I4IE9zfSLb0eHbgZwZxDVzdmFejARrHlWk3
 +MK7Nav7RLSJ990am33zb58CTHc7YYVlBp07+PwLXzypqWkhYfok1OYYjyjCrFDs
@@ -10,17 +10,17 @@ sjcJI3hRCZNEz+wYsG+tdYWJ+gRPQOWfh0YfO2rFgXAIMLiF6lyWzf1eOM+OjYrF
 /eyzwbMaJkkGa/AyZKz3wZiPq0jTuYLVmH4MK7MBOsUfSmsBsn/ohyRCQzM+ol0v
 Qlsrulj8usponRPDh9ng4PB5OSgR79YimQZnASQzJxiUvMADrKL5L6KwLxJlzbqY
 R0b5mLh8KBzBQmSh3Aj2e2I7Z17hdaMCAwEAAaMQMA4wDAYDVR0TBAUwAwEB/zAN
-BgkqhkiG9w0BAQsFAAOCAQEASzA7ApbuKn8lkC706gRL37a33yTZZ8rjZ4dnvCtq
-6OltlYDJ8IndotKbLH0SUEAxrvcaFnMt7AX9pRf2sGBKbY8zcxqPfsvzVehgx4Ea
-1RYksFW4h97jj1a1RKukTKuEOEEipbxwo0rLxfjvdaf2izqchJsLGtbocIZf0bD8
-djbE9jOLkx7saL08qC8ECrf9utsee+LJCsUYbNgYyIItEy6yVnmF/ICz93Utn1cI
-RfqZr1lM2Ia2LP9eDTmiuR9m+/MzkeRvvJHonNrRJHlcggtYHICvYioh9/jALBcm
-wZ+hTUePVqy4hOCBJ975CXjfKFN4MKQAdeB3EO5eBYAD3Q==
+BgkqhkiG9w0BAQsFAAOCAQEAo5siIstgYy1MjyVaSHpxy6Cq7JT73RhYYudtAy8e
+XwVXqy3xuZtl+i2XaWnsojyHRZ83t+1rVCoesbZefyfz9d6qZJkCkWdKdjiVEu+s
+CJSo+tGyCZQ1ZTb+07WY01P97gfswP+VHN4EjxJmUnLdqJEJsdOckvL1mBfortt6
+CvL7adPwftppNivF64R0QZfOsLIaaOa0oi33DQDDNUdrx5f3xWwYmzw+f95lvbYR
+DXCytT647nc44Gu09erE4sWipIknFBvg3P1D0icFSIoEh44mU9o1lHUFsogXa09g
+8Vkho/rudYrHi/cwwzQlUjZyHPg6k1iU9oZGEaW5gVKxSw==
 -----END CERTIFICATE-----
 -----BEGIN CERTIFICATE-----
 MIIDDTCCAfWgAwIBAgIBAjANBgkqhkiG9w0BAQsFADBAMT4wPAYDVQQDDDVUZXN0
 IHJvb3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NMIHJlZ3Jlc3Npb24gdGVzdCBzdWl0
-ZTAeFw0xODExMjcxMzQwNTVaFw00NjA0MTQxMzQwNTVaMEIxQDA+BgNVBAMMN1Rl
+ZTAeFw0yMDA4MzEwNjA3MjNaFw00ODAxMTcwNjA3MjNaMEIxQDA+BgNVBAMMN1Rl
 c3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NMIHJlZ3Jlc3Npb24gdGVzdCBjbGllbnQg
 Y2VydHMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75x7yuQ1+gK8j
 1aO6D2nGym2x2OFniztlnx4PlWWWivIrYlxy6xAhfrVdjwjc5mMtOCrVKllsdC+S
@@ -29,17 +29,17 @@ B2yipfW1PUxM9a7/p19CRBcDQ+LNW+YFqwARByHGq1wfatJzpM8TXe+XEnRfW9KX
 P3a5PqR6evFQOzjcAf+QBJ0hAEddUDhdYECbs1GrApfsEHBuwXabdCH41j0F/0yc
 kctydWfBl2Vbmd3sfsFMHjde+SJhqxyq6xiSL59jnx4ZKmtn9VSOYbGmBCdBdYK7
 RTcnJQv9AgMBAAGjEDAOMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEB
-AB6zh/Jw+t232100Tztr7wJoKH8DL1hnSm3e7omdj0WlKfuZwTqDuMzB3H4LOSnS
-A00XpyMAGAJC6yRjS8pt+pjY5Jt6ouSqf6wNq0mF0jiIDeg1k/GNEjigx+0ITqbE
-lUJ56AcpoBNhOwBjOCRFh4JuspHZqHXgUNYTEicClbV+lZwoMIIK1e6FYRZDqMtL
-+34GtZACImqvRkP5alqQg7hJUM1zbDVf2qebY4cfSu4OfTu6Og6KrL8Cu6bqR2et
-0a/TbthHYz1QGDYRoVTSP4uWoG9M1ZbsA/bNE2eqcrQj+dJ4AmIIr8Yl8mrwo/FZ
-SvgeLMlQY7UNwLUDtwy9QkI=
+AKsQncM/5JZez/dECPg7xp8T5Sj++mJSiFsFr2Isk3HjJBI+skvZfpWkJnkEUl4a
++BspqoeAD5K+Fad0/Xg/AyZztONpLU+haA4eQCpwYHVY/DSjasjEI5BbCV8mrrYP
+SLcKGIJrPW+beO8pbjdkJNxBiDTeYzMBTbfHvarBYLYAvur8ZvUgKExDWP5kGUe8
+zA9F4FJ/Nig03QzQgxaNjxXoy892fAs6KyWFoGZDqAXlXAFNuz83joTiGNzNTiW4
+qRKpBa6aitnPVeIs8m3z/SUcm5PdMWvXVlsrlA0Gx2EM/B02EWnPk/U+CHtNey7r
+h4LJ4NA9GngE2gewd/gNItc=
 -----END CERTIFICATE-----
 -----BEGIN CERTIFICATE-----
 MIIDDTCCAfWgAwIBAgIBATANBgkqhkiG9w0BAQsFADBAMT4wPAYDVQQDDDVUZXN0
 IHJvb3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NMIHJlZ3Jlc3Npb24gdGVzdCBzdWl0
-ZTAeFw0xODExMjcxMzQwNTRaFw00NjA0MTQxMzQwNTRaMEIxQDA+BgNVBAMMN1Rl
+ZTAeFw0yMDA4MzEwNjA3MjNaFw00ODAxMTcwNjA3MjNaMEIxQDA+BgNVBAMMN1Rl
 c3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NMIHJlZ3Jlc3Npb24gdGVzdCBzZXJ2ZXIg
 Y2VydHMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDiSnYZbmc9vpCt
 Ku1sKV9l663JCceubhMw8Gg16kV0hXEFf/TgGC4zkiYNHN7+G45YD7Nq0kBCq3dH
@@ -48,10 +48,10 @@ t2wPCc6c8pQoI64dfprVqPkvzoe1WBpZNetkUTk20v08jNeRa7XdRbRR6we1s9VG
 QW9YWdH9N5ctaUXMG6lLV2OAjs+W1smpKfpIpMCA1lPGlElu70hynon/nQQvBP77
 SfQpZVc0esM18jkZpr5LEKUCw+x6LaMsqmBHpAULfCffxn2r0uMBW4L4VaGg3W6F
 h6iuJwRfAgMBAAGjEDAOMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEB
-AFlcKTaU/Ug3Q0hr3P1UQ6dWyK4aVn9rs4jvVfFl0a0RnbBowqK2C+zQVUWYTcjo
-KHREVje65goj6VzRB6ko/9mAQ6PZP8jRuRhfCmvmvSQ/mWdgPzSRsUh9MwgEm9c2
-vNbqwaznEU8cYZnLpHiR9O5S7/qWWxehjYtxk5Eb4J006YglYfHnhrRFJvPbiqlf
-IOEivZ7gIVfvaOTbLjmN2kLOnzdlwpXGjxxg4Nu9ZhXOhfrplzUvRfmqvVsDiHXb
-USIdX+OFZZqr64IKG4drT4K4Bt2wupOEyX4ZFsUXXd+Hgq83SWmV4wzflcpmGkLC
-JZ3CEMu8/WA5uQBXdQUozlE=
+AArYO305zkNZc+vdbeXNpgi1/FrOHl2b0DvG4i2gcUVDvvjIHUnVLf2cak+81vER
+CqlCkutXxB+/fyxVXYtLKXQh0D/68QikH+ImEavrUrANXvQRvoixIjrfub/nZB75
+EiOTIR2N0/m6ndjCHJU0W8N7Tt9qob31e3bVJBZOc+9e80y8GDQiMKYACmet9zUR
+hR/yvJhUsH/u5Y7OwrvcyCs+PJXzPnZTSsatSkHI4KY22+7K+ZhscLIaBKjqlIDj
++fHBrutW9jtog1E3JUO9ZHokB1qlRLs4YhpQ8YzHRabEBaX892ZPLNwtmFLOWK1p
+9klR7/RXnu13nStNIYAHk20=
 -----END CERTIFICATE-----
diff --git a/src/test/ssl/ssl/both-cas-2.crt b/src/test/ssl/ssl/both-cas-2.crt
index 2f2723f2b1..6669f42c92 100644
--- a/src/test/ssl/ssl/both-cas-2.crt
+++ b/src/test/ssl/ssl/both-cas-2.crt
@@ -1,8 +1,8 @@
 -----BEGIN CERTIFICATE-----
-MIIDHjCCAgagAwIBAgIUEAgXJ/ibw6TVTUoomlBsPMfVTlMwDQYJKoZIhvcNAQEL
+MIIDHjCCAgagAwIBAgIUbDho+LuL8GrZ/iVFY16vdG6kNo0wDQYJKoZIhvcNAQEL
 BQAwQDE+MDwGA1UEAww1VGVzdCByb290IENBIGZvciBQb3N0Z3JlU1FMIFNTTCBy
-ZWdyZXNzaW9uIHRlc3Qgc3VpdGUwHhcNMTgxMTI3MTM0MDU0WhcNNDYwNDE0MTM0
-MDU0WjBAMT4wPAYDVQQDDDVUZXN0IHJvb3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NM
+ZWdyZXNzaW9uIHRlc3Qgc3VpdGUwHhcNMjAwODMxMDYwNzIyWhcNNDgwMTE3MDYw
+NzIyWjBAMT4wPAYDVQQDDDVUZXN0IHJvb3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NM
 IHJlZ3Jlc3Npb24gdGVzdCBzdWl0ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
 AQoCggEBALZ81vKKBJlxgjwuNoK67I4IE9zfSLb0eHbgZwZxDVzdmFejARrHlWk3
 +MK7Nav7RLSJ990am33zb58CTHc7YYVlBp07+PwLXzypqWkhYfok1OYYjyjCrFDs
@@ -10,17 +10,17 @@ sjcJI3hRCZNEz+wYsG+tdYWJ+gRPQOWfh0YfO2rFgXAIMLiF6lyWzf1eOM+OjYrF
 /eyzwbMaJkkGa/AyZKz3wZiPq0jTuYLVmH4MK7MBOsUfSmsBsn/ohyRCQzM+ol0v
 Qlsrulj8usponRPDh9ng4PB5OSgR79YimQZnASQzJxiUvMADrKL5L6KwLxJlzbqY
 R0b5mLh8KBzBQmSh3Aj2e2I7Z17hdaMCAwEAAaMQMA4wDAYDVR0TBAUwAwEB/zAN
-BgkqhkiG9w0BAQsFAAOCAQEASzA7ApbuKn8lkC706gRL37a33yTZZ8rjZ4dnvCtq
-6OltlYDJ8IndotKbLH0SUEAxrvcaFnMt7AX9pRf2sGBKbY8zcxqPfsvzVehgx4Ea
-1RYksFW4h97jj1a1RKukTKuEOEEipbxwo0rLxfjvdaf2izqchJsLGtbocIZf0bD8
-djbE9jOLkx7saL08qC8ECrf9utsee+LJCsUYbNgYyIItEy6yVnmF/ICz93Utn1cI
-RfqZr1lM2Ia2LP9eDTmiuR9m+/MzkeRvvJHonNrRJHlcggtYHICvYioh9/jALBcm
-wZ+hTUePVqy4hOCBJ975CXjfKFN4MKQAdeB3EO5eBYAD3Q==
+BgkqhkiG9w0BAQsFAAOCAQEAo5siIstgYy1MjyVaSHpxy6Cq7JT73RhYYudtAy8e
+XwVXqy3xuZtl+i2XaWnsojyHRZ83t+1rVCoesbZefyfz9d6qZJkCkWdKdjiVEu+s
+CJSo+tGyCZQ1ZTb+07WY01P97gfswP+VHN4EjxJmUnLdqJEJsdOckvL1mBfortt6
+CvL7adPwftppNivF64R0QZfOsLIaaOa0oi33DQDDNUdrx5f3xWwYmzw+f95lvbYR
+DXCytT647nc44Gu09erE4sWipIknFBvg3P1D0icFSIoEh44mU9o1lHUFsogXa09g
+8Vkho/rudYrHi/cwwzQlUjZyHPg6k1iU9oZGEaW5gVKxSw==
 -----END CERTIFICATE-----
 -----BEGIN CERTIFICATE-----
 MIIDDTCCAfWgAwIBAgIBATANBgkqhkiG9w0BAQsFADBAMT4wPAYDVQQDDDVUZXN0
 IHJvb3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NMIHJlZ3Jlc3Npb24gdGVzdCBzdWl0
-ZTAeFw0xODExMjcxMzQwNTRaFw00NjA0MTQxMzQwNTRaMEIxQDA+BgNVBAMMN1Rl
+ZTAeFw0yMDA4MzEwNjA3MjNaFw00ODAxMTcwNjA3MjNaMEIxQDA+BgNVBAMMN1Rl
 c3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NMIHJlZ3Jlc3Npb24gdGVzdCBzZXJ2ZXIg
 Y2VydHMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDiSnYZbmc9vpCt
 Ku1sKV9l663JCceubhMw8Gg16kV0hXEFf/TgGC4zkiYNHN7+G45YD7Nq0kBCq3dH
@@ -29,17 +29,17 @@ t2wPCc6c8pQoI64dfprVqPkvzoe1WBpZNetkUTk20v08jNeRa7XdRbRR6we1s9VG
 QW9YWdH9N5ctaUXMG6lLV2OAjs+W1smpKfpIpMCA1lPGlElu70hynon/nQQvBP77
 SfQpZVc0esM18jkZpr5LEKUCw+x6LaMsqmBHpAULfCffxn2r0uMBW4L4VaGg3W6F
 h6iuJwRfAgMBAAGjEDAOMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEB
-AFlcKTaU/Ug3Q0hr3P1UQ6dWyK4aVn9rs4jvVfFl0a0RnbBowqK2C+zQVUWYTcjo
-KHREVje65goj6VzRB6ko/9mAQ6PZP8jRuRhfCmvmvSQ/mWdgPzSRsUh9MwgEm9c2
-vNbqwaznEU8cYZnLpHiR9O5S7/qWWxehjYtxk5Eb4J006YglYfHnhrRFJvPbiqlf
-IOEivZ7gIVfvaOTbLjmN2kLOnzdlwpXGjxxg4Nu9ZhXOhfrplzUvRfmqvVsDiHXb
-USIdX+OFZZqr64IKG4drT4K4Bt2wupOEyX4ZFsUXXd+Hgq83SWmV4wzflcpmGkLC
-JZ3CEMu8/WA5uQBXdQUozlE=
+AArYO305zkNZc+vdbeXNpgi1/FrOHl2b0DvG4i2gcUVDvvjIHUnVLf2cak+81vER
+CqlCkutXxB+/fyxVXYtLKXQh0D/68QikH+ImEavrUrANXvQRvoixIjrfub/nZB75
+EiOTIR2N0/m6ndjCHJU0W8N7Tt9qob31e3bVJBZOc+9e80y8GDQiMKYACmet9zUR
+hR/yvJhUsH/u5Y7OwrvcyCs+PJXzPnZTSsatSkHI4KY22+7K+ZhscLIaBKjqlIDj
++fHBrutW9jtog1E3JUO9ZHokB1qlRLs4YhpQ8YzHRabEBaX892ZPLNwtmFLOWK1p
+9klR7/RXnu13nStNIYAHk20=
 -----END CERTIFICATE-----
 -----BEGIN CERTIFICATE-----
 MIIDDTCCAfWgAwIBAgIBAjANBgkqhkiG9w0BAQsFADBAMT4wPAYDVQQDDDVUZXN0
 IHJvb3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NMIHJlZ3Jlc3Npb24gdGVzdCBzdWl0
-ZTAeFw0xODExMjcxMzQwNTVaFw00NjA0MTQxMzQwNTVaMEIxQDA+BgNVBAMMN1Rl
+ZTAeFw0yMDA4MzEwNjA3MjNaFw00ODAxMTcwNjA3MjNaMEIxQDA+BgNVBAMMN1Rl
 c3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NMIHJlZ3Jlc3Npb24gdGVzdCBjbGllbnQg
 Y2VydHMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75x7yuQ1+gK8j
 1aO6D2nGym2x2OFniztlnx4PlWWWivIrYlxy6xAhfrVdjwjc5mMtOCrVKllsdC+S
@@ -48,10 +48,10 @@ B2yipfW1PUxM9a7/p19CRBcDQ+LNW+YFqwARByHGq1wfatJzpM8TXe+XEnRfW9KX
 P3a5PqR6evFQOzjcAf+QBJ0hAEddUDhdYECbs1GrApfsEHBuwXabdCH41j0F/0yc
 kctydWfBl2Vbmd3sfsFMHjde+SJhqxyq6xiSL59jnx4ZKmtn9VSOYbGmBCdBdYK7
 RTcnJQv9AgMBAAGjEDAOMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEB
-AB6zh/Jw+t232100Tztr7wJoKH8DL1hnSm3e7omdj0WlKfuZwTqDuMzB3H4LOSnS
-A00XpyMAGAJC6yRjS8pt+pjY5Jt6ouSqf6wNq0mF0jiIDeg1k/GNEjigx+0ITqbE
-lUJ56AcpoBNhOwBjOCRFh4JuspHZqHXgUNYTEicClbV+lZwoMIIK1e6FYRZDqMtL
-+34GtZACImqvRkP5alqQg7hJUM1zbDVf2qebY4cfSu4OfTu6Og6KrL8Cu6bqR2et
-0a/TbthHYz1QGDYRoVTSP4uWoG9M1ZbsA/bNE2eqcrQj+dJ4AmIIr8Yl8mrwo/FZ
-SvgeLMlQY7UNwLUDtwy9QkI=
+AKsQncM/5JZez/dECPg7xp8T5Sj++mJSiFsFr2Isk3HjJBI+skvZfpWkJnkEUl4a
++BspqoeAD5K+Fad0/Xg/AyZztONpLU+haA4eQCpwYHVY/DSjasjEI5BbCV8mrrYP
+SLcKGIJrPW+beO8pbjdkJNxBiDTeYzMBTbfHvarBYLYAvur8ZvUgKExDWP5kGUe8
+zA9F4FJ/Nig03QzQgxaNjxXoy892fAs6KyWFoGZDqAXlXAFNuz83joTiGNzNTiW4
+qRKpBa6aitnPVeIs8m3z/SUcm5PdMWvXVlsrlA0Gx2EM/B02EWnPk/U+CHtNey7r
+h4LJ4NA9GngE2gewd/gNItc=
 -----END CERTIFICATE-----
diff --git a/src/test/ssl/ssl/client+client_ca.crt b/src/test/ssl/ssl/client+client_ca.crt
index 2804527f3e..154bcd58e7 100644
--- a/src/test/ssl/ssl/client+client_ca.crt
+++ b/src/test/ssl/ssl/client+client_ca.crt
@@ -1,24 +1,24 @@
 -----BEGIN CERTIFICATE-----
 MIICzDCCAbQCAQEwDQYJKoZIhvcNAQELBQAwQjFAMD4GA1UEAww3VGVzdCBDQSBm
 b3IgUG9zdGdyZVNRTCBTU0wgcmVncmVzc2lvbiB0ZXN0IGNsaWVudCBjZXJ0czAe
-Fw0xODExMjcxMzQwNTVaFw00NjA0MTQxMzQwNTVaMBYxFDASBgNVBAMMC3NzbHRl
+Fw0yMDA4MzEwNjA3MjNaFw00ODAxMTcwNjA3MjNaMBYxFDASBgNVBAMMC3NzbHRl
 c3R1c2VyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtIugLqHywEAE
 vyRZGMVAkdk1zCa5FFaPOEFhHiAMpwFOEIEi4Svk9kSSRecmeJcody1sLNoFqtTA
 b5tYaDoGIVZfc8/kxm8sbsTE/3JOsON3CMqjOQkI1ZKjDSF1gtrGSmatgjqsMnlP
 UJkFEsPhFg6NTf1ZUjFiQeWEli0fQJ2/k+7MI4S0t0pDJJJWrqF4l6eSgu8rsBoX
 XHy4OLAz6j23r2k5FZs6H/poII95ia+E8hG8SrJmMa88naRdq7hHW802Z6lEhnRW
 ND+tDGjt0ZaTfxx+CxN4UjgbboOJifTykVHjuzBR1+IzLHcxoZCLP1cjadSqMz5b
-ziJTGtHzYwIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQAcIGps6BnsRxkN5sphg6GK
-tzDvp2IUyOu5oeAHdJLT5JFZhKKzhDD4KiOv+XWzdHcSAl3xMqAqnFdSTCt2vtc+
-rk04eyVWJALyf6oPT60Vn5sFaaxlTg1+tnZMCCycDxM6lc/6onzgp6DUWGozlgSh
-eNgCyaNU73VTuMgd+s/QrZ5HCr0OPAb3aWRQy7hVZeOniNBXWrO/CC2Swfwz7jU3
-dvLAWYENUvZlE2S7HnQGclGIJb38qFCnquuSgmO9yT30Lmmwp33k5/evN9cNQMxU
-c4ChYCaabOGXUaBJNzJAYMEUHh+o+LPgFF2iB0mL7FAUip9XsjOiOwcrbusM/g+2
+ziJTGtHzYwIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQCQonvnvG8wlfoo+J476Kjr
+Jm4i9pPgUTYNyF4lzhXViw24bKZVsNBaeVbu6XXRamzkrLL/qYUrQAm2ZcDqnVxC
+GXLgOYwIvuN7hGyks3Jh+tWQQf5UuhbhyJrOju1Z8nTI2dDgiHjsEHVxbVM9vMYl
+IiwjoU68gR/Gc8tApiIJe/HDMmSbm2W58heXXKG7r5790u5MO0vdBiGTlj0WdktU
+dB/ltpt5sm17SoUvSDIKZkLjHv/cuetCh7tCVrs0Gi0mf2aWdlXhPDh+KnDzEhlf
+/vW2Btlq1LQtYfP0yzkrmGR2dt72pg6bN6e7qc5YDYMXQPXvEZBiQbsgBPMm75Mc
 -----END CERTIFICATE-----
 -----BEGIN CERTIFICATE-----
 MIIDDTCCAfWgAwIBAgIBAjANBgkqhkiG9w0BAQsFADBAMT4wPAYDVQQDDDVUZXN0
 IHJvb3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NMIHJlZ3Jlc3Npb24gdGVzdCBzdWl0
-ZTAeFw0xODExMjcxMzQwNTVaFw00NjA0MTQxMzQwNTVaMEIxQDA+BgNVBAMMN1Rl
+ZTAeFw0yMDA4MzEwNjA3MjNaFw00ODAxMTcwNjA3MjNaMEIxQDA+BgNVBAMMN1Rl
 c3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NMIHJlZ3Jlc3Npb24gdGVzdCBjbGllbnQg
 Y2VydHMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75x7yuQ1+gK8j
 1aO6D2nGym2x2OFniztlnx4PlWWWivIrYlxy6xAhfrVdjwjc5mMtOCrVKllsdC+S
@@ -27,10 +27,10 @@ B2yipfW1PUxM9a7/p19CRBcDQ+LNW+YFqwARByHGq1wfatJzpM8TXe+XEnRfW9KX
 P3a5PqR6evFQOzjcAf+QBJ0hAEddUDhdYECbs1GrApfsEHBuwXabdCH41j0F/0yc
 kctydWfBl2Vbmd3sfsFMHjde+SJhqxyq6xiSL59jnx4ZKmtn9VSOYbGmBCdBdYK7
 RTcnJQv9AgMBAAGjEDAOMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEB
-AB6zh/Jw+t232100Tztr7wJoKH8DL1hnSm3e7omdj0WlKfuZwTqDuMzB3H4LOSnS
-A00XpyMAGAJC6yRjS8pt+pjY5Jt6ouSqf6wNq0mF0jiIDeg1k/GNEjigx+0ITqbE
-lUJ56AcpoBNhOwBjOCRFh4JuspHZqHXgUNYTEicClbV+lZwoMIIK1e6FYRZDqMtL
-+34GtZACImqvRkP5alqQg7hJUM1zbDVf2qebY4cfSu4OfTu6Og6KrL8Cu6bqR2et
-0a/TbthHYz1QGDYRoVTSP4uWoG9M1ZbsA/bNE2eqcrQj+dJ4AmIIr8Yl8mrwo/FZ
-SvgeLMlQY7UNwLUDtwy9QkI=
+AKsQncM/5JZez/dECPg7xp8T5Sj++mJSiFsFr2Isk3HjJBI+skvZfpWkJnkEUl4a
++BspqoeAD5K+Fad0/Xg/AyZztONpLU+haA4eQCpwYHVY/DSjasjEI5BbCV8mrrYP
+SLcKGIJrPW+beO8pbjdkJNxBiDTeYzMBTbfHvarBYLYAvur8ZvUgKExDWP5kGUe8
+zA9F4FJ/Nig03QzQgxaNjxXoy892fAs6KyWFoGZDqAXlXAFNuz83joTiGNzNTiW4
+qRKpBa6aitnPVeIs8m3z/SUcm5PdMWvXVlsrlA0Gx2EM/B02EWnPk/U+CHtNey7r
+h4LJ4NA9GngE2gewd/gNItc=
 -----END CERTIFICATE-----
diff --git a/src/test/ssl/ssl/client-crldir/9bb9e3c3.r0 b/src/test/ssl/ssl/client-crldir/9bb9e3c3.r0
new file mode 100644
index 0000000000..b5c689e537
--- /dev/null
+++ b/src/test/ssl/ssl/client-crldir/9bb9e3c3.r0
@@ -0,0 +1,11 @@
+-----BEGIN X509 CRL-----
+MIIBnjCBhzANBgkqhkiG9w0BAQsFADBCMUAwPgYDVQQDDDdUZXN0IENBIGZvciBQ
+b3N0Z3JlU1FMIFNTTCByZWdyZXNzaW9uIHRlc3QgY2xpZW50IGNlcnRzFw0yMDA4
+MzEwNjA3MjNaFw00ODAxMTcwNjA3MjNaMBQwEgIBAhcNMjAwODMxMDYwNzIzWjAN
+BgkqhkiG9w0BAQsFAAOCAQEAQ3ZK9Bx9i2JBSR2XgEFSvy8JrtRurpGpGcnh0ann
+G/vLY+Kp/UGiVnh8jwJ35Q7VUVGYNTKv2gc+WFFmscZaoP69RrgA9fbl9gZ4yUic
+H+XXiR4mQKk03EEKuPlZdWA1PMGAoAZxA8aCrrDZobrRgXEiSRdoQl8sHEJ3f1W1
+EoL+F3w77GzirYQukfNyIfzA6YpfphrNUkDN8jjrNB5/XzTT7fysutpflVKs/tLl
+TKHmwkrCC+TXJ8P2/KaIdQ0QgJSv5XIKS0vn4GC+zgjoUC3D1fprfRqmrBeQyLXV
+eUJda/H6uldOPpAJ2yLNR7S7COvFkGvIxunG7uPZiGq1eg==
+-----END X509 CRL-----
diff --git a/src/test/ssl/ssl/client-revoked.crt b/src/test/ssl/ssl/client-revoked.crt
index 14857a33a2..1a9047dc63 100644
--- a/src/test/ssl/ssl/client-revoked.crt
+++ b/src/test/ssl/ssl/client-revoked.crt
@@ -1,17 +1,17 @@
 -----BEGIN CERTIFICATE-----
 MIICzDCCAbQCAQIwDQYJKoZIhvcNAQELBQAwQjFAMD4GA1UEAww3VGVzdCBDQSBm
 b3IgUG9zdGdyZVNRTCBTU0wgcmVncmVzc2lvbiB0ZXN0IGNsaWVudCBjZXJ0czAe
-Fw0xODExMjcxMzQwNTVaFw00NjA0MTQxMzQwNTVaMBYxFDASBgNVBAMMC3NzbHRl
+Fw0yMDA4MzEwNjA3MjNaFw00ODAxMTcwNjA3MjNaMBYxFDASBgNVBAMMC3NzbHRl
 c3R1c2VyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoBcmY2Z+qa+l
 UB5YSYnGLt96S7axkoDvIzLJkwJugGqw1U72A6lAUTyAPVntsmbhoMpDEHK6ylg8
 U4HC3L1hbhSpFriTITJ3TzH4+wdDH1KZYlM2k0gfrKrksJyZ7ftAyuBvzBRlFbBe
 xopR9VQjqgAuNKByJswldOe0KwP0nmb/TtT9lkAt7XjrSut5MUezFVnvTxabm7tQ
 ciDG+8QqE0b8lH3N3VOXWZWCeXPRrwboO3baAmcue4V20N0ALARP+QZNElBa7Jq+
 l77VNjneRk07jjaE7PCGVlWfPggppZos1Ay1sb2JhK0S9pZrynQT/ck3qhG4QuKp
-cmn/Bbe/8wIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQBySTwOO9zSFCtfRjbbblDx
-AK2ttILR0ZJXnvzjNjuErsT9qeXaq2t/iG/vmhH5XDjaefXFLCLqFunvcg6cIz1A
-HhAw+JInfyk3TUpDaX6M0X8qj184e4kXzVc83Afa3LiP5JkirzCSv6ErqAHw2VVd
-bZbZUwMfQLpWHVqXK89Pb7q791H4VeEx9CLxtZ2PSr2GCdpFbVMJvdBPChD2Re1A
-ELcbMZ9iOq2AUN/gxrt7HnE3dRoGQk6AJOfvhi2eZcVWiLtITScdPk1nYcNxGid3
-BWW+tdLbjmSe2FXNfDwBTvuHh5A9S399X5l/nLAng2iTGSvIm1OgUnC2oWsok3EI
+cmn/Bbe/8wIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQAQzzp5yTHFan/LkTXHkvuU
+XEqQbUzD7iUuEop7I6BY8vzLkijylCIXDOg7WmD2Sysb3+7nJ8JG8BZzXnXoS+hz
+sdEF/lFIZltx6S9wvC6QMK8vJat+XM0FBO7C27cswD929Loiqy0CxOdbrED8kwWf
+oN7Kv01wdtEmd+xK6zqtDB/vm8Dq89zlBDHnJeM5iJi+BIMt1HM+FAlxDwgm18Xa
+K9u7xrmvpycfXFZ+nLM0B8gxJAQ8djxgB/hOAM9CDSEhzN5BJIZ4slZRq9bGVLjy
+dvrW0LoNKhitgS/Pe400Ej9LGXSsBrVP6FXHcL4qvHqdwKl0R3QiodX6ro2H0vBY
 -----END CERTIFICATE-----
diff --git a/src/test/ssl/ssl/client.crl b/src/test/ssl/ssl/client.crl
index a667680e04..b5c689e537 100644
--- a/src/test/ssl/ssl/client.crl
+++ b/src/test/ssl/ssl/client.crl
@@ -1,11 +1,11 @@
 -----BEGIN X509 CRL-----
 MIIBnjCBhzANBgkqhkiG9w0BAQsFADBCMUAwPgYDVQQDDDdUZXN0IENBIGZvciBQ
-b3N0Z3JlU1FMIFNTTCByZWdyZXNzaW9uIHRlc3QgY2xpZW50IGNlcnRzFw0xODEx
-MjcxMzQwNTVaFw00NjA0MTQxMzQwNTVaMBQwEgIBAhcNMTgxMTI3MTM0MDU1WjAN
-BgkqhkiG9w0BAQsFAAOCAQEAXjLxA9Qc6gAudwUHBxMIq5EHBcuNEX5e3GNlkyNf
-8I0DtHTPfJPvmAG+i6lYz//hHmmjxK0dR2ucg79XgXI/6OpDqlxS/TG1Xv52wA1p
-xz6GaJ2hC8Lk4/vbJo/Rrzme2QsI7xqBWya0JWVrehttqhFxPzWA5wID8X7G4Kb4
-pjVnzqYzn8A9FBiV9t10oZg60aVLqt3kbyy+U3pefvjhj8NmQc7uyuVjWvYZA0vG
-nnDUo4EKJzHNIYLk+EfpzKWO2XAWBLOT9SyyNCeMuQ5p/2pdAt9jtWHenms2ajo9
-2iUsHS91e3TooP9yNYuNcN8/wXY6H2Xm+dCLcEnkcr7EEw==
+b3N0Z3JlU1FMIFNTTCByZWdyZXNzaW9uIHRlc3QgY2xpZW50IGNlcnRzFw0yMDA4
+MzEwNjA3MjNaFw00ODAxMTcwNjA3MjNaMBQwEgIBAhcNMjAwODMxMDYwNzIzWjAN
+BgkqhkiG9w0BAQsFAAOCAQEAQ3ZK9Bx9i2JBSR2XgEFSvy8JrtRurpGpGcnh0ann
+G/vLY+Kp/UGiVnh8jwJ35Q7VUVGYNTKv2gc+WFFmscZaoP69RrgA9fbl9gZ4yUic
+H+XXiR4mQKk03EEKuPlZdWA1PMGAoAZxA8aCrrDZobrRgXEiSRdoQl8sHEJ3f1W1
+EoL+F3w77GzirYQukfNyIfzA6YpfphrNUkDN8jjrNB5/XzTT7fysutpflVKs/tLl
+TKHmwkrCC+TXJ8P2/KaIdQ0QgJSv5XIKS0vn4GC+zgjoUC3D1fprfRqmrBeQyLXV
+eUJda/H6uldOPpAJ2yLNR7S7COvFkGvIxunG7uPZiGq1eg==
 -----END X509 CRL-----
diff --git a/src/test/ssl/ssl/client.crt b/src/test/ssl/ssl/client.crt
index 4d0a6ef419..b46de4fa9b 100644
--- a/src/test/ssl/ssl/client.crt
+++ b/src/test/ssl/ssl/client.crt
@@ -1,17 +1,17 @@
 -----BEGIN CERTIFICATE-----
 MIICzDCCAbQCAQEwDQYJKoZIhvcNAQELBQAwQjFAMD4GA1UEAww3VGVzdCBDQSBm
 b3IgUG9zdGdyZVNRTCBTU0wgcmVncmVzc2lvbiB0ZXN0IGNsaWVudCBjZXJ0czAe
-Fw0xODExMjcxMzQwNTVaFw00NjA0MTQxMzQwNTVaMBYxFDASBgNVBAMMC3NzbHRl
+Fw0yMDA4MzEwNjA3MjNaFw00ODAxMTcwNjA3MjNaMBYxFDASBgNVBAMMC3NzbHRl
 c3R1c2VyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtIugLqHywEAE
 vyRZGMVAkdk1zCa5FFaPOEFhHiAMpwFOEIEi4Svk9kSSRecmeJcody1sLNoFqtTA
 b5tYaDoGIVZfc8/kxm8sbsTE/3JOsON3CMqjOQkI1ZKjDSF1gtrGSmatgjqsMnlP
 UJkFEsPhFg6NTf1ZUjFiQeWEli0fQJ2/k+7MI4S0t0pDJJJWrqF4l6eSgu8rsBoX
 XHy4OLAz6j23r2k5FZs6H/poII95ia+E8hG8SrJmMa88naRdq7hHW802Z6lEhnRW
 ND+tDGjt0ZaTfxx+CxN4UjgbboOJifTykVHjuzBR1+IzLHcxoZCLP1cjadSqMz5b
-ziJTGtHzYwIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQAcIGps6BnsRxkN5sphg6GK
-tzDvp2IUyOu5oeAHdJLT5JFZhKKzhDD4KiOv+XWzdHcSAl3xMqAqnFdSTCt2vtc+
-rk04eyVWJALyf6oPT60Vn5sFaaxlTg1+tnZMCCycDxM6lc/6onzgp6DUWGozlgSh
-eNgCyaNU73VTuMgd+s/QrZ5HCr0OPAb3aWRQy7hVZeOniNBXWrO/CC2Swfwz7jU3
-dvLAWYENUvZlE2S7HnQGclGIJb38qFCnquuSgmO9yT30Lmmwp33k5/evN9cNQMxU
-c4ChYCaabOGXUaBJNzJAYMEUHh+o+LPgFF2iB0mL7FAUip9XsjOiOwcrbusM/g+2
+ziJTGtHzYwIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQCQonvnvG8wlfoo+J476Kjr
+Jm4i9pPgUTYNyF4lzhXViw24bKZVsNBaeVbu6XXRamzkrLL/qYUrQAm2ZcDqnVxC
+GXLgOYwIvuN7hGyks3Jh+tWQQf5UuhbhyJrOju1Z8nTI2dDgiHjsEHVxbVM9vMYl
+IiwjoU68gR/Gc8tApiIJe/HDMmSbm2W58heXXKG7r5790u5MO0vdBiGTlj0WdktU
+dB/ltpt5sm17SoUvSDIKZkLjHv/cuetCh7tCVrs0Gi0mf2aWdlXhPDh+KnDzEhlf
+/vW2Btlq1LQtYfP0yzkrmGR2dt72pg6bN6e7qc5YDYMXQPXvEZBiQbsgBPMm75Mc
 -----END CERTIFICATE-----
diff --git a/src/test/ssl/ssl/client_ca.crt b/src/test/ssl/ssl/client_ca.crt
index 1ef3771261..23bac28a0c 100644
--- a/src/test/ssl/ssl/client_ca.crt
+++ b/src/test/ssl/ssl/client_ca.crt
@@ -1,7 +1,7 @@
 -----BEGIN CERTIFICATE-----
 MIIDDTCCAfWgAwIBAgIBAjANBgkqhkiG9w0BAQsFADBAMT4wPAYDVQQDDDVUZXN0
 IHJvb3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NMIHJlZ3Jlc3Npb24gdGVzdCBzdWl0
-ZTAeFw0xODExMjcxMzQwNTVaFw00NjA0MTQxMzQwNTVaMEIxQDA+BgNVBAMMN1Rl
+ZTAeFw0yMDA4MzEwNjA3MjNaFw00ODAxMTcwNjA3MjNaMEIxQDA+BgNVBAMMN1Rl
 c3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NMIHJlZ3Jlc3Npb24gdGVzdCBjbGllbnQg
 Y2VydHMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75x7yuQ1+gK8j
 1aO6D2nGym2x2OFniztlnx4PlWWWivIrYlxy6xAhfrVdjwjc5mMtOCrVKllsdC+S
@@ -10,10 +10,10 @@ B2yipfW1PUxM9a7/p19CRBcDQ+LNW+YFqwARByHGq1wfatJzpM8TXe+XEnRfW9KX
 P3a5PqR6evFQOzjcAf+QBJ0hAEddUDhdYECbs1GrApfsEHBuwXabdCH41j0F/0yc
 kctydWfBl2Vbmd3sfsFMHjde+SJhqxyq6xiSL59jnx4ZKmtn9VSOYbGmBCdBdYK7
 RTcnJQv9AgMBAAGjEDAOMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEB
-AB6zh/Jw+t232100Tztr7wJoKH8DL1hnSm3e7omdj0WlKfuZwTqDuMzB3H4LOSnS
-A00XpyMAGAJC6yRjS8pt+pjY5Jt6ouSqf6wNq0mF0jiIDeg1k/GNEjigx+0ITqbE
-lUJ56AcpoBNhOwBjOCRFh4JuspHZqHXgUNYTEicClbV+lZwoMIIK1e6FYRZDqMtL
-+34GtZACImqvRkP5alqQg7hJUM1zbDVf2qebY4cfSu4OfTu6Og6KrL8Cu6bqR2et
-0a/TbthHYz1QGDYRoVTSP4uWoG9M1ZbsA/bNE2eqcrQj+dJ4AmIIr8Yl8mrwo/FZ
-SvgeLMlQY7UNwLUDtwy9QkI=
+AKsQncM/5JZez/dECPg7xp8T5Sj++mJSiFsFr2Isk3HjJBI+skvZfpWkJnkEUl4a
++BspqoeAD5K+Fad0/Xg/AyZztONpLU+haA4eQCpwYHVY/DSjasjEI5BbCV8mrrYP
+SLcKGIJrPW+beO8pbjdkJNxBiDTeYzMBTbfHvarBYLYAvur8ZvUgKExDWP5kGUe8
+zA9F4FJ/Nig03QzQgxaNjxXoy892fAs6KyWFoGZDqAXlXAFNuz83joTiGNzNTiW4
+qRKpBa6aitnPVeIs8m3z/SUcm5PdMWvXVlsrlA0Gx2EM/B02EWnPk/U+CHtNey7r
+h4LJ4NA9GngE2gewd/gNItc=
 -----END CERTIFICATE-----
diff --git a/src/test/ssl/ssl/root+client-crldir/9bb9e3c3.r0 b/src/test/ssl/ssl/root+client-crldir/9bb9e3c3.r0
new file mode 100644
index 0000000000..b5c689e537
--- /dev/null
+++ b/src/test/ssl/ssl/root+client-crldir/9bb9e3c3.r0
@@ -0,0 +1,11 @@
+-----BEGIN X509 CRL-----
+MIIBnjCBhzANBgkqhkiG9w0BAQsFADBCMUAwPgYDVQQDDDdUZXN0IENBIGZvciBQ
+b3N0Z3JlU1FMIFNTTCByZWdyZXNzaW9uIHRlc3QgY2xpZW50IGNlcnRzFw0yMDA4
+MzEwNjA3MjNaFw00ODAxMTcwNjA3MjNaMBQwEgIBAhcNMjAwODMxMDYwNzIzWjAN
+BgkqhkiG9w0BAQsFAAOCAQEAQ3ZK9Bx9i2JBSR2XgEFSvy8JrtRurpGpGcnh0ann
+G/vLY+Kp/UGiVnh8jwJ35Q7VUVGYNTKv2gc+WFFmscZaoP69RrgA9fbl9gZ4yUic
+H+XXiR4mQKk03EEKuPlZdWA1PMGAoAZxA8aCrrDZobrRgXEiSRdoQl8sHEJ3f1W1
+EoL+F3w77GzirYQukfNyIfzA6YpfphrNUkDN8jjrNB5/XzTT7fysutpflVKs/tLl
+TKHmwkrCC+TXJ8P2/KaIdQ0QgJSv5XIKS0vn4GC+zgjoUC3D1fprfRqmrBeQyLXV
+eUJda/H6uldOPpAJ2yLNR7S7COvFkGvIxunG7uPZiGq1eg==
+-----END X509 CRL-----
diff --git a/src/test/ssl/ssl/root+client-crldir/a3d11bff.r0 b/src/test/ssl/ssl/root+client-crldir/a3d11bff.r0
new file mode 100644
index 0000000000..8cca69ba40
--- /dev/null
+++ b/src/test/ssl/ssl/root+client-crldir/a3d11bff.r0
@@ -0,0 +1,11 @@
+-----BEGIN X509 CRL-----
+MIIBhTBvMA0GCSqGSIb3DQEBCwUAMEAxPjA8BgNVBAMMNVRlc3Qgcm9vdCBDQSBm
+b3IgUG9zdGdyZVNRTCBTU0wgcmVncmVzc2lvbiB0ZXN0IHN1aXRlFw0yMDA4MzEw
+NjA3MjNaFw00ODAxMTcwNjA3MjNaMA0GCSqGSIb3DQEBCwUAA4IBAQB/pWC8moSA
+DL36OWwOig7/yEmbVdpFk2mPmAullbH0A6I/lWkrSrKbb0wk8tE04N2Pw0WDvtqd
+aWq5bx1mL1ve0su2SUkuM5Tb26ZVakI3WDCdDmJIEXAE32g6gmdnAZqaaK2Sy58y
+fEvCTe8Zxe0+8eHNv0VYfhl1ALUwMoO/VrVd453O1FWfXBopm+kkHPB6BDyo9ZbN
+PzLHGnGAP2L+1Ps5TP1AMk2ZEZ87QysB4G2qm1x4A6R4Jf6XBOC5y4YI+vsncUZ2
+UCajgatsFN6LZVHO+q1h5LhsVpSCs9yX8gjaoenJtOrY6XFis1DNHrm0QFSN/yNu
+Muuf3P8i5zl0
+-----END X509 CRL-----
diff --git a/src/test/ssl/ssl/root+client.crl b/src/test/ssl/ssl/root+client.crl
index 854d77b71e..fdc00efebb 100644
--- a/src/test/ssl/ssl/root+client.crl
+++ b/src/test/ssl/ssl/root+client.crl
@@ -1,22 +1,22 @@
 -----BEGIN X509 CRL-----
 MIIBhTBvMA0GCSqGSIb3DQEBCwUAMEAxPjA8BgNVBAMMNVRlc3Qgcm9vdCBDQSBm
-b3IgUG9zdGdyZVNRTCBTU0wgcmVncmVzc2lvbiB0ZXN0IHN1aXRlFw0xODExMjcx
-MzQwNTVaFw00NjA0MTQxMzQwNTVaMA0GCSqGSIb3DQEBCwUAA4IBAQB8OSDym4/a
-qbZOrZvOOhmKrd7AJSTgAadtdK0CX3v58Ym3EmZK7gQFdBuFCXnvbue/x6avZHgz
-4pYFlJmL0IiD4QuTzsoo+LzifrmTzteO9oEJNLd2bjfEnpE5Wdaw6Yuy2Xb5edy5
-lQhNZdc8w3FiXhPOEUAi7EbdfDwn4G/fvEjpzyVb2wCujDUUePUGGayjKIM4PUu4
-pixM6gt9FFL27l47lQ3g0PbvB3TnU3oqcB3Y17FjbxjFc6AsGXholNetoEE2/49E
-PEYzOH7/PtxlZUtoCqZM+741LuI6Q7z4/P2X/IY33lMy6Iiyc41C94l/P7fCkMLG
-AlO+O0a4SpYS
+b3IgUG9zdGdyZVNRTCBTU0wgcmVncmVzc2lvbiB0ZXN0IHN1aXRlFw0yMDA4MzEw
+NjA3MjNaFw00ODAxMTcwNjA3MjNaMA0GCSqGSIb3DQEBCwUAA4IBAQB/pWC8moSA
+DL36OWwOig7/yEmbVdpFk2mPmAullbH0A6I/lWkrSrKbb0wk8tE04N2Pw0WDvtqd
+aWq5bx1mL1ve0su2SUkuM5Tb26ZVakI3WDCdDmJIEXAE32g6gmdnAZqaaK2Sy58y
+fEvCTe8Zxe0+8eHNv0VYfhl1ALUwMoO/VrVd453O1FWfXBopm+kkHPB6BDyo9ZbN
+PzLHGnGAP2L+1Ps5TP1AMk2ZEZ87QysB4G2qm1x4A6R4Jf6XBOC5y4YI+vsncUZ2
+UCajgatsFN6LZVHO+q1h5LhsVpSCs9yX8gjaoenJtOrY6XFis1DNHrm0QFSN/yNu
+Muuf3P8i5zl0
 -----END X509 CRL-----
 -----BEGIN X509 CRL-----
 MIIBnjCBhzANBgkqhkiG9w0BAQsFADBCMUAwPgYDVQQDDDdUZXN0IENBIGZvciBQ
-b3N0Z3JlU1FMIFNTTCByZWdyZXNzaW9uIHRlc3QgY2xpZW50IGNlcnRzFw0xODEx
-MjcxMzQwNTVaFw00NjA0MTQxMzQwNTVaMBQwEgIBAhcNMTgxMTI3MTM0MDU1WjAN
-BgkqhkiG9w0BAQsFAAOCAQEAXjLxA9Qc6gAudwUHBxMIq5EHBcuNEX5e3GNlkyNf
-8I0DtHTPfJPvmAG+i6lYz//hHmmjxK0dR2ucg79XgXI/6OpDqlxS/TG1Xv52wA1p
-xz6GaJ2hC8Lk4/vbJo/Rrzme2QsI7xqBWya0JWVrehttqhFxPzWA5wID8X7G4Kb4
-pjVnzqYzn8A9FBiV9t10oZg60aVLqt3kbyy+U3pefvjhj8NmQc7uyuVjWvYZA0vG
-nnDUo4EKJzHNIYLk+EfpzKWO2XAWBLOT9SyyNCeMuQ5p/2pdAt9jtWHenms2ajo9
-2iUsHS91e3TooP9yNYuNcN8/wXY6H2Xm+dCLcEnkcr7EEw==
+b3N0Z3JlU1FMIFNTTCByZWdyZXNzaW9uIHRlc3QgY2xpZW50IGNlcnRzFw0yMDA4
+MzEwNjA3MjNaFw00ODAxMTcwNjA3MjNaMBQwEgIBAhcNMjAwODMxMDYwNzIzWjAN
+BgkqhkiG9w0BAQsFAAOCAQEAQ3ZK9Bx9i2JBSR2XgEFSvy8JrtRurpGpGcnh0ann
+G/vLY+Kp/UGiVnh8jwJ35Q7VUVGYNTKv2gc+WFFmscZaoP69RrgA9fbl9gZ4yUic
+H+XXiR4mQKk03EEKuPlZdWA1PMGAoAZxA8aCrrDZobrRgXEiSRdoQl8sHEJ3f1W1
+EoL+F3w77GzirYQukfNyIfzA6YpfphrNUkDN8jjrNB5/XzTT7fysutpflVKs/tLl
+TKHmwkrCC+TXJ8P2/KaIdQ0QgJSv5XIKS0vn4GC+zgjoUC3D1fprfRqmrBeQyLXV
+eUJda/H6uldOPpAJ2yLNR7S7COvFkGvIxunG7uPZiGq1eg==
 -----END X509 CRL-----
diff --git a/src/test/ssl/ssl/root+client_ca.crt b/src/test/ssl/ssl/root+client_ca.crt
index 1867cd9c31..c7c024eeba 100644
--- a/src/test/ssl/ssl/root+client_ca.crt
+++ b/src/test/ssl/ssl/root+client_ca.crt
@@ -1,8 +1,8 @@
 -----BEGIN CERTIFICATE-----
-MIIDHjCCAgagAwIBAgIUEAgXJ/ibw6TVTUoomlBsPMfVTlMwDQYJKoZIhvcNAQEL
+MIIDHjCCAgagAwIBAgIUbDho+LuL8GrZ/iVFY16vdG6kNo0wDQYJKoZIhvcNAQEL
 BQAwQDE+MDwGA1UEAww1VGVzdCByb290IENBIGZvciBQb3N0Z3JlU1FMIFNTTCBy
-ZWdyZXNzaW9uIHRlc3Qgc3VpdGUwHhcNMTgxMTI3MTM0MDU0WhcNNDYwNDE0MTM0
-MDU0WjBAMT4wPAYDVQQDDDVUZXN0IHJvb3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NM
+ZWdyZXNzaW9uIHRlc3Qgc3VpdGUwHhcNMjAwODMxMDYwNzIyWhcNNDgwMTE3MDYw
+NzIyWjBAMT4wPAYDVQQDDDVUZXN0IHJvb3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NM
 IHJlZ3Jlc3Npb24gdGVzdCBzdWl0ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
 AQoCggEBALZ81vKKBJlxgjwuNoK67I4IE9zfSLb0eHbgZwZxDVzdmFejARrHlWk3
 +MK7Nav7RLSJ990am33zb58CTHc7YYVlBp07+PwLXzypqWkhYfok1OYYjyjCrFDs
@@ -10,17 +10,17 @@ sjcJI3hRCZNEz+wYsG+tdYWJ+gRPQOWfh0YfO2rFgXAIMLiF6lyWzf1eOM+OjYrF
 /eyzwbMaJkkGa/AyZKz3wZiPq0jTuYLVmH4MK7MBOsUfSmsBsn/ohyRCQzM+ol0v
 Qlsrulj8usponRPDh9ng4PB5OSgR79YimQZnASQzJxiUvMADrKL5L6KwLxJlzbqY
 R0b5mLh8KBzBQmSh3Aj2e2I7Z17hdaMCAwEAAaMQMA4wDAYDVR0TBAUwAwEB/zAN
-BgkqhkiG9w0BAQsFAAOCAQEASzA7ApbuKn8lkC706gRL37a33yTZZ8rjZ4dnvCtq
-6OltlYDJ8IndotKbLH0SUEAxrvcaFnMt7AX9pRf2sGBKbY8zcxqPfsvzVehgx4Ea
-1RYksFW4h97jj1a1RKukTKuEOEEipbxwo0rLxfjvdaf2izqchJsLGtbocIZf0bD8
-djbE9jOLkx7saL08qC8ECrf9utsee+LJCsUYbNgYyIItEy6yVnmF/ICz93Utn1cI
-RfqZr1lM2Ia2LP9eDTmiuR9m+/MzkeRvvJHonNrRJHlcggtYHICvYioh9/jALBcm
-wZ+hTUePVqy4hOCBJ975CXjfKFN4MKQAdeB3EO5eBYAD3Q==
+BgkqhkiG9w0BAQsFAAOCAQEAo5siIstgYy1MjyVaSHpxy6Cq7JT73RhYYudtAy8e
+XwVXqy3xuZtl+i2XaWnsojyHRZ83t+1rVCoesbZefyfz9d6qZJkCkWdKdjiVEu+s
+CJSo+tGyCZQ1ZTb+07WY01P97gfswP+VHN4EjxJmUnLdqJEJsdOckvL1mBfortt6
+CvL7adPwftppNivF64R0QZfOsLIaaOa0oi33DQDDNUdrx5f3xWwYmzw+f95lvbYR
+DXCytT647nc44Gu09erE4sWipIknFBvg3P1D0icFSIoEh44mU9o1lHUFsogXa09g
+8Vkho/rudYrHi/cwwzQlUjZyHPg6k1iU9oZGEaW5gVKxSw==
 -----END CERTIFICATE-----
 -----BEGIN CERTIFICATE-----
 MIIDDTCCAfWgAwIBAgIBAjANBgkqhkiG9w0BAQsFADBAMT4wPAYDVQQDDDVUZXN0
 IHJvb3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NMIHJlZ3Jlc3Npb24gdGVzdCBzdWl0
-ZTAeFw0xODExMjcxMzQwNTVaFw00NjA0MTQxMzQwNTVaMEIxQDA+BgNVBAMMN1Rl
+ZTAeFw0yMDA4MzEwNjA3MjNaFw00ODAxMTcwNjA3MjNaMEIxQDA+BgNVBAMMN1Rl
 c3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NMIHJlZ3Jlc3Npb24gdGVzdCBjbGllbnQg
 Y2VydHMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75x7yuQ1+gK8j
 1aO6D2nGym2x2OFniztlnx4PlWWWivIrYlxy6xAhfrVdjwjc5mMtOCrVKllsdC+S
@@ -29,10 +29,10 @@ B2yipfW1PUxM9a7/p19CRBcDQ+LNW+YFqwARByHGq1wfatJzpM8TXe+XEnRfW9KX
 P3a5PqR6evFQOzjcAf+QBJ0hAEddUDhdYECbs1GrApfsEHBuwXabdCH41j0F/0yc
 kctydWfBl2Vbmd3sfsFMHjde+SJhqxyq6xiSL59jnx4ZKmtn9VSOYbGmBCdBdYK7
 RTcnJQv9AgMBAAGjEDAOMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEB
-AB6zh/Jw+t232100Tztr7wJoKH8DL1hnSm3e7omdj0WlKfuZwTqDuMzB3H4LOSnS
-A00XpyMAGAJC6yRjS8pt+pjY5Jt6ouSqf6wNq0mF0jiIDeg1k/GNEjigx+0ITqbE
-lUJ56AcpoBNhOwBjOCRFh4JuspHZqHXgUNYTEicClbV+lZwoMIIK1e6FYRZDqMtL
-+34GtZACImqvRkP5alqQg7hJUM1zbDVf2qebY4cfSu4OfTu6Og6KrL8Cu6bqR2et
-0a/TbthHYz1QGDYRoVTSP4uWoG9M1ZbsA/bNE2eqcrQj+dJ4AmIIr8Yl8mrwo/FZ
-SvgeLMlQY7UNwLUDtwy9QkI=
+AKsQncM/5JZez/dECPg7xp8T5Sj++mJSiFsFr2Isk3HjJBI+skvZfpWkJnkEUl4a
++BspqoeAD5K+Fad0/Xg/AyZztONpLU+haA4eQCpwYHVY/DSjasjEI5BbCV8mrrYP
+SLcKGIJrPW+beO8pbjdkJNxBiDTeYzMBTbfHvarBYLYAvur8ZvUgKExDWP5kGUe8
+zA9F4FJ/Nig03QzQgxaNjxXoy892fAs6KyWFoGZDqAXlXAFNuz83joTiGNzNTiW4
+qRKpBa6aitnPVeIs8m3z/SUcm5PdMWvXVlsrlA0Gx2EM/B02EWnPk/U+CHtNey7r
+h4LJ4NA9GngE2gewd/gNItc=
 -----END CERTIFICATE-----
diff --git a/src/test/ssl/ssl/root+server-crldir/a3d11bff.r0 b/src/test/ssl/ssl/root+server-crldir/a3d11bff.r0
new file mode 100644
index 0000000000..8cca69ba40
--- /dev/null
+++ b/src/test/ssl/ssl/root+server-crldir/a3d11bff.r0
@@ -0,0 +1,11 @@
+-----BEGIN X509 CRL-----
+MIIBhTBvMA0GCSqGSIb3DQEBCwUAMEAxPjA8BgNVBAMMNVRlc3Qgcm9vdCBDQSBm
+b3IgUG9zdGdyZVNRTCBTU0wgcmVncmVzc2lvbiB0ZXN0IHN1aXRlFw0yMDA4MzEw
+NjA3MjNaFw00ODAxMTcwNjA3MjNaMA0GCSqGSIb3DQEBCwUAA4IBAQB/pWC8moSA
+DL36OWwOig7/yEmbVdpFk2mPmAullbH0A6I/lWkrSrKbb0wk8tE04N2Pw0WDvtqd
+aWq5bx1mL1ve0su2SUkuM5Tb26ZVakI3WDCdDmJIEXAE32g6gmdnAZqaaK2Sy58y
+fEvCTe8Zxe0+8eHNv0VYfhl1ALUwMoO/VrVd453O1FWfXBopm+kkHPB6BDyo9ZbN
+PzLHGnGAP2L+1Ps5TP1AMk2ZEZ87QysB4G2qm1x4A6R4Jf6XBOC5y4YI+vsncUZ2
+UCajgatsFN6LZVHO+q1h5LhsVpSCs9yX8gjaoenJtOrY6XFis1DNHrm0QFSN/yNu
+Muuf3P8i5zl0
+-----END X509 CRL-----
diff --git a/src/test/ssl/ssl/root+server-crldir/a836cc2d.r0 b/src/test/ssl/ssl/root+server-crldir/a836cc2d.r0
new file mode 100644
index 0000000000..9588d1e524
--- /dev/null
+++ b/src/test/ssl/ssl/root+server-crldir/a836cc2d.r0
@@ -0,0 +1,11 @@
+-----BEGIN X509 CRL-----
+MIIBnjCBhzANBgkqhkiG9w0BAQsFADBCMUAwPgYDVQQDDDdUZXN0IENBIGZvciBQ
+b3N0Z3JlU1FMIFNTTCByZWdyZXNzaW9uIHRlc3Qgc2VydmVyIGNlcnRzFw0yMDA4
+MzEwNjA3MjNaFw00ODAxMTcwNjA3MjNaMBQwEgIBBhcNMjAwODMxMDYwNzIzWjAN
+BgkqhkiG9w0BAQsFAAOCAQEA2CBoLuLCpXcVSHqQtKnTcz25FyPsGkSO3luiUiG5
+jnI9HvZ9OzeQGGho6XBhVHAmEtwKOo6pcxqDe8Qkf6X7v0AUc19BWkxOXT+sCCdM
+yOvRhNPAhxJToGgKqp41noTSMhZPLsvFEfbbFTZEABScfX2K+XdvQlAYXa3U375E
+71jFenrNh8fNTKfcikmio1rsybQ4PG/ASsrUflQ5LAz3Nm3awdw01auGzRFezq3z
+Ivnq3z5b2q+m653PUsygNRMFVxCAgrvqAadKci7MK/QthCbocrLIhuc9Mmx1Nbkm
+Wnv+La3b5HeH8Zi9Q89IBr12rH70Y6K3hggCUAo9CoK3zw==
+-----END X509 CRL-----
diff --git a/src/test/ssl/ssl/root+server.crl b/src/test/ssl/ssl/root+server.crl
index 9720b3023c..ba7994d1fa 100644
--- a/src/test/ssl/ssl/root+server.crl
+++ b/src/test/ssl/ssl/root+server.crl
@@ -1,22 +1,22 @@
 -----BEGIN X509 CRL-----
 MIIBhTBvMA0GCSqGSIb3DQEBCwUAMEAxPjA8BgNVBAMMNVRlc3Qgcm9vdCBDQSBm
-b3IgUG9zdGdyZVNRTCBTU0wgcmVncmVzc2lvbiB0ZXN0IHN1aXRlFw0xODExMjcx
-MzQwNTVaFw00NjA0MTQxMzQwNTVaMA0GCSqGSIb3DQEBCwUAA4IBAQB8OSDym4/a
-qbZOrZvOOhmKrd7AJSTgAadtdK0CX3v58Ym3EmZK7gQFdBuFCXnvbue/x6avZHgz
-4pYFlJmL0IiD4QuTzsoo+LzifrmTzteO9oEJNLd2bjfEnpE5Wdaw6Yuy2Xb5edy5
-lQhNZdc8w3FiXhPOEUAi7EbdfDwn4G/fvEjpzyVb2wCujDUUePUGGayjKIM4PUu4
-pixM6gt9FFL27l47lQ3g0PbvB3TnU3oqcB3Y17FjbxjFc6AsGXholNetoEE2/49E
-PEYzOH7/PtxlZUtoCqZM+741LuI6Q7z4/P2X/IY33lMy6Iiyc41C94l/P7fCkMLG
-AlO+O0a4SpYS
+b3IgUG9zdGdyZVNRTCBTU0wgcmVncmVzc2lvbiB0ZXN0IHN1aXRlFw0yMDA4MzEw
+NjA3MjNaFw00ODAxMTcwNjA3MjNaMA0GCSqGSIb3DQEBCwUAA4IBAQB/pWC8moSA
+DL36OWwOig7/yEmbVdpFk2mPmAullbH0A6I/lWkrSrKbb0wk8tE04N2Pw0WDvtqd
+aWq5bx1mL1ve0su2SUkuM5Tb26ZVakI3WDCdDmJIEXAE32g6gmdnAZqaaK2Sy58y
+fEvCTe8Zxe0+8eHNv0VYfhl1ALUwMoO/VrVd453O1FWfXBopm+kkHPB6BDyo9ZbN
+PzLHGnGAP2L+1Ps5TP1AMk2ZEZ87QysB4G2qm1x4A6R4Jf6XBOC5y4YI+vsncUZ2
+UCajgatsFN6LZVHO+q1h5LhsVpSCs9yX8gjaoenJtOrY6XFis1DNHrm0QFSN/yNu
+Muuf3P8i5zl0
 -----END X509 CRL-----
 -----BEGIN X509 CRL-----
 MIIBnjCBhzANBgkqhkiG9w0BAQsFADBCMUAwPgYDVQQDDDdUZXN0IENBIGZvciBQ
-b3N0Z3JlU1FMIFNTTCByZWdyZXNzaW9uIHRlc3Qgc2VydmVyIGNlcnRzFw0xODEx
-MjcxMzQwNTVaFw00NjA0MTQxMzQwNTVaMBQwEgIBBhcNMTgxMTI3MTM0MDU1WjAN
-BgkqhkiG9w0BAQsFAAOCAQEAbVuJXemxM6HLlIHGWlQvVmsmG4ZTQWiDnZjfmrND
-xB4XsvZNPXnFkjdBENDROrbDRwm60SJDW73AbDbfq1IXAzSpuEyuRz61IyYKo0wq
-nmObJtVdIu3bVlWIlDXaP5Emk3d7ouCj5f8Kyeb8gm4pL3N6e0eI63hCaS39hhE6
-RLGh9HU9ht1kKfgcTwmB5b2HTPb4M6z1AmSIaMVqZTjIspsUgNF2+GBm3fOnOaiZ
-SEXWtgjMRXiIHbtU0va3LhSH5OSW0mh+L9oGUQDYnyuudnWGpulhqIp4qVkJRDDu
-41HpD83dV2uRtBLvc25AFHj7kXBflbO3gvGZVPYf1zVghQ==
+b3N0Z3JlU1FMIFNTTCByZWdyZXNzaW9uIHRlc3Qgc2VydmVyIGNlcnRzFw0yMDA4
+MzEwNjA3MjNaFw00ODAxMTcwNjA3MjNaMBQwEgIBBhcNMjAwODMxMDYwNzIzWjAN
+BgkqhkiG9w0BAQsFAAOCAQEA2CBoLuLCpXcVSHqQtKnTcz25FyPsGkSO3luiUiG5
+jnI9HvZ9OzeQGGho6XBhVHAmEtwKOo6pcxqDe8Qkf6X7v0AUc19BWkxOXT+sCCdM
+yOvRhNPAhxJToGgKqp41noTSMhZPLsvFEfbbFTZEABScfX2K+XdvQlAYXa3U375E
+71jFenrNh8fNTKfcikmio1rsybQ4PG/ASsrUflQ5LAz3Nm3awdw01auGzRFezq3z
+Ivnq3z5b2q+m653PUsygNRMFVxCAgrvqAadKci7MK/QthCbocrLIhuc9Mmx1Nbkm
+Wnv+La3b5HeH8Zi9Q89IBr12rH70Y6K3hggCUAo9CoK3zw==
 -----END X509 CRL-----
diff --git a/src/test/ssl/ssl/root+server_ca.crt b/src/test/ssl/ssl/root+server_ca.crt
index 861eba80d0..2c5c2d9a76 100644
--- a/src/test/ssl/ssl/root+server_ca.crt
+++ b/src/test/ssl/ssl/root+server_ca.crt
@@ -1,8 +1,8 @@
 -----BEGIN CERTIFICATE-----
-MIIDHjCCAgagAwIBAgIUEAgXJ/ibw6TVTUoomlBsPMfVTlMwDQYJKoZIhvcNAQEL
+MIIDHjCCAgagAwIBAgIUbDho+LuL8GrZ/iVFY16vdG6kNo0wDQYJKoZIhvcNAQEL
 BQAwQDE+MDwGA1UEAww1VGVzdCByb290IENBIGZvciBQb3N0Z3JlU1FMIFNTTCBy
-ZWdyZXNzaW9uIHRlc3Qgc3VpdGUwHhcNMTgxMTI3MTM0MDU0WhcNNDYwNDE0MTM0
-MDU0WjBAMT4wPAYDVQQDDDVUZXN0IHJvb3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NM
+ZWdyZXNzaW9uIHRlc3Qgc3VpdGUwHhcNMjAwODMxMDYwNzIyWhcNNDgwMTE3MDYw
+NzIyWjBAMT4wPAYDVQQDDDVUZXN0IHJvb3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NM
 IHJlZ3Jlc3Npb24gdGVzdCBzdWl0ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
 AQoCggEBALZ81vKKBJlxgjwuNoK67I4IE9zfSLb0eHbgZwZxDVzdmFejARrHlWk3
 +MK7Nav7RLSJ990am33zb58CTHc7YYVlBp07+PwLXzypqWkhYfok1OYYjyjCrFDs
@@ -10,17 +10,17 @@ sjcJI3hRCZNEz+wYsG+tdYWJ+gRPQOWfh0YfO2rFgXAIMLiF6lyWzf1eOM+OjYrF
 /eyzwbMaJkkGa/AyZKz3wZiPq0jTuYLVmH4MK7MBOsUfSmsBsn/ohyRCQzM+ol0v
 Qlsrulj8usponRPDh9ng4PB5OSgR79YimQZnASQzJxiUvMADrKL5L6KwLxJlzbqY
 R0b5mLh8KBzBQmSh3Aj2e2I7Z17hdaMCAwEAAaMQMA4wDAYDVR0TBAUwAwEB/zAN
-BgkqhkiG9w0BAQsFAAOCAQEASzA7ApbuKn8lkC706gRL37a33yTZZ8rjZ4dnvCtq
-6OltlYDJ8IndotKbLH0SUEAxrvcaFnMt7AX9pRf2sGBKbY8zcxqPfsvzVehgx4Ea
-1RYksFW4h97jj1a1RKukTKuEOEEipbxwo0rLxfjvdaf2izqchJsLGtbocIZf0bD8
-djbE9jOLkx7saL08qC8ECrf9utsee+LJCsUYbNgYyIItEy6yVnmF/ICz93Utn1cI
-RfqZr1lM2Ia2LP9eDTmiuR9m+/MzkeRvvJHonNrRJHlcggtYHICvYioh9/jALBcm
-wZ+hTUePVqy4hOCBJ975CXjfKFN4MKQAdeB3EO5eBYAD3Q==
+BgkqhkiG9w0BAQsFAAOCAQEAo5siIstgYy1MjyVaSHpxy6Cq7JT73RhYYudtAy8e
+XwVXqy3xuZtl+i2XaWnsojyHRZ83t+1rVCoesbZefyfz9d6qZJkCkWdKdjiVEu+s
+CJSo+tGyCZQ1ZTb+07WY01P97gfswP+VHN4EjxJmUnLdqJEJsdOckvL1mBfortt6
+CvL7adPwftppNivF64R0QZfOsLIaaOa0oi33DQDDNUdrx5f3xWwYmzw+f95lvbYR
+DXCytT647nc44Gu09erE4sWipIknFBvg3P1D0icFSIoEh44mU9o1lHUFsogXa09g
+8Vkho/rudYrHi/cwwzQlUjZyHPg6k1iU9oZGEaW5gVKxSw==
 -----END CERTIFICATE-----
 -----BEGIN CERTIFICATE-----
 MIIDDTCCAfWgAwIBAgIBATANBgkqhkiG9w0BAQsFADBAMT4wPAYDVQQDDDVUZXN0
 IHJvb3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NMIHJlZ3Jlc3Npb24gdGVzdCBzdWl0
-ZTAeFw0xODExMjcxMzQwNTRaFw00NjA0MTQxMzQwNTRaMEIxQDA+BgNVBAMMN1Rl
+ZTAeFw0yMDA4MzEwNjA3MjNaFw00ODAxMTcwNjA3MjNaMEIxQDA+BgNVBAMMN1Rl
 c3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NMIHJlZ3Jlc3Npb24gdGVzdCBzZXJ2ZXIg
 Y2VydHMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDiSnYZbmc9vpCt
 Ku1sKV9l663JCceubhMw8Gg16kV0hXEFf/TgGC4zkiYNHN7+G45YD7Nq0kBCq3dH
@@ -29,10 +29,10 @@ t2wPCc6c8pQoI64dfprVqPkvzoe1WBpZNetkUTk20v08jNeRa7XdRbRR6we1s9VG
 QW9YWdH9N5ctaUXMG6lLV2OAjs+W1smpKfpIpMCA1lPGlElu70hynon/nQQvBP77
 SfQpZVc0esM18jkZpr5LEKUCw+x6LaMsqmBHpAULfCffxn2r0uMBW4L4VaGg3W6F
 h6iuJwRfAgMBAAGjEDAOMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEB
-AFlcKTaU/Ug3Q0hr3P1UQ6dWyK4aVn9rs4jvVfFl0a0RnbBowqK2C+zQVUWYTcjo
-KHREVje65goj6VzRB6ko/9mAQ6PZP8jRuRhfCmvmvSQ/mWdgPzSRsUh9MwgEm9c2
-vNbqwaznEU8cYZnLpHiR9O5S7/qWWxehjYtxk5Eb4J006YglYfHnhrRFJvPbiqlf
-IOEivZ7gIVfvaOTbLjmN2kLOnzdlwpXGjxxg4Nu9ZhXOhfrplzUvRfmqvVsDiHXb
-USIdX+OFZZqr64IKG4drT4K4Bt2wupOEyX4ZFsUXXd+Hgq83SWmV4wzflcpmGkLC
-JZ3CEMu8/WA5uQBXdQUozlE=
+AArYO305zkNZc+vdbeXNpgi1/FrOHl2b0DvG4i2gcUVDvvjIHUnVLf2cak+81vER
+CqlCkutXxB+/fyxVXYtLKXQh0D/68QikH+ImEavrUrANXvQRvoixIjrfub/nZB75
+EiOTIR2N0/m6ndjCHJU0W8N7Tt9qob31e3bVJBZOc+9e80y8GDQiMKYACmet9zUR
+hR/yvJhUsH/u5Y7OwrvcyCs+PJXzPnZTSsatSkHI4KY22+7K+ZhscLIaBKjqlIDj
++fHBrutW9jtog1E3JUO9ZHokB1qlRLs4YhpQ8YzHRabEBaX892ZPLNwtmFLOWK1p
+9klR7/RXnu13nStNIYAHk20=
 -----END CERTIFICATE-----
diff --git a/src/test/ssl/ssl/root.crl b/src/test/ssl/ssl/root.crl
index e879cf25a7..8cca69ba40 100644
--- a/src/test/ssl/ssl/root.crl
+++ b/src/test/ssl/ssl/root.crl
@@ -1,11 +1,11 @@
 -----BEGIN X509 CRL-----
 MIIBhTBvMA0GCSqGSIb3DQEBCwUAMEAxPjA8BgNVBAMMNVRlc3Qgcm9vdCBDQSBm
-b3IgUG9zdGdyZVNRTCBTU0wgcmVncmVzc2lvbiB0ZXN0IHN1aXRlFw0xODExMjcx
-MzQwNTVaFw00NjA0MTQxMzQwNTVaMA0GCSqGSIb3DQEBCwUAA4IBAQB8OSDym4/a
-qbZOrZvOOhmKrd7AJSTgAadtdK0CX3v58Ym3EmZK7gQFdBuFCXnvbue/x6avZHgz
-4pYFlJmL0IiD4QuTzsoo+LzifrmTzteO9oEJNLd2bjfEnpE5Wdaw6Yuy2Xb5edy5
-lQhNZdc8w3FiXhPOEUAi7EbdfDwn4G/fvEjpzyVb2wCujDUUePUGGayjKIM4PUu4
-pixM6gt9FFL27l47lQ3g0PbvB3TnU3oqcB3Y17FjbxjFc6AsGXholNetoEE2/49E
-PEYzOH7/PtxlZUtoCqZM+741LuI6Q7z4/P2X/IY33lMy6Iiyc41C94l/P7fCkMLG
-AlO+O0a4SpYS
+b3IgUG9zdGdyZVNRTCBTU0wgcmVncmVzc2lvbiB0ZXN0IHN1aXRlFw0yMDA4MzEw
+NjA3MjNaFw00ODAxMTcwNjA3MjNaMA0GCSqGSIb3DQEBCwUAA4IBAQB/pWC8moSA
+DL36OWwOig7/yEmbVdpFk2mPmAullbH0A6I/lWkrSrKbb0wk8tE04N2Pw0WDvtqd
+aWq5bx1mL1ve0su2SUkuM5Tb26ZVakI3WDCdDmJIEXAE32g6gmdnAZqaaK2Sy58y
+fEvCTe8Zxe0+8eHNv0VYfhl1ALUwMoO/VrVd453O1FWfXBopm+kkHPB6BDyo9ZbN
+PzLHGnGAP2L+1Ps5TP1AMk2ZEZ87QysB4G2qm1x4A6R4Jf6XBOC5y4YI+vsncUZ2
+UCajgatsFN6LZVHO+q1h5LhsVpSCs9yX8gjaoenJtOrY6XFis1DNHrm0QFSN/yNu
+Muuf3P8i5zl0
 -----END X509 CRL-----
diff --git a/src/test/ssl/ssl/root_ca.crt b/src/test/ssl/ssl/root_ca.crt
index 402d7dab89..92000763a9 100644
--- a/src/test/ssl/ssl/root_ca.crt
+++ b/src/test/ssl/ssl/root_ca.crt
@@ -1,8 +1,8 @@
 -----BEGIN CERTIFICATE-----
-MIIDHjCCAgagAwIBAgIUEAgXJ/ibw6TVTUoomlBsPMfVTlMwDQYJKoZIhvcNAQEL
+MIIDHjCCAgagAwIBAgIUbDho+LuL8GrZ/iVFY16vdG6kNo0wDQYJKoZIhvcNAQEL
 BQAwQDE+MDwGA1UEAww1VGVzdCByb290IENBIGZvciBQb3N0Z3JlU1FMIFNTTCBy
-ZWdyZXNzaW9uIHRlc3Qgc3VpdGUwHhcNMTgxMTI3MTM0MDU0WhcNNDYwNDE0MTM0
-MDU0WjBAMT4wPAYDVQQDDDVUZXN0IHJvb3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NM
+ZWdyZXNzaW9uIHRlc3Qgc3VpdGUwHhcNMjAwODMxMDYwNzIyWhcNNDgwMTE3MDYw
+NzIyWjBAMT4wPAYDVQQDDDVUZXN0IHJvb3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NM
 IHJlZ3Jlc3Npb24gdGVzdCBzdWl0ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
 AQoCggEBALZ81vKKBJlxgjwuNoK67I4IE9zfSLb0eHbgZwZxDVzdmFejARrHlWk3
 +MK7Nav7RLSJ990am33zb58CTHc7YYVlBp07+PwLXzypqWkhYfok1OYYjyjCrFDs
@@ -10,10 +10,10 @@ sjcJI3hRCZNEz+wYsG+tdYWJ+gRPQOWfh0YfO2rFgXAIMLiF6lyWzf1eOM+OjYrF
 /eyzwbMaJkkGa/AyZKz3wZiPq0jTuYLVmH4MK7MBOsUfSmsBsn/ohyRCQzM+ol0v
 Qlsrulj8usponRPDh9ng4PB5OSgR79YimQZnASQzJxiUvMADrKL5L6KwLxJlzbqY
 R0b5mLh8KBzBQmSh3Aj2e2I7Z17hdaMCAwEAAaMQMA4wDAYDVR0TBAUwAwEB/zAN
-BgkqhkiG9w0BAQsFAAOCAQEASzA7ApbuKn8lkC706gRL37a33yTZZ8rjZ4dnvCtq
-6OltlYDJ8IndotKbLH0SUEAxrvcaFnMt7AX9pRf2sGBKbY8zcxqPfsvzVehgx4Ea
-1RYksFW4h97jj1a1RKukTKuEOEEipbxwo0rLxfjvdaf2izqchJsLGtbocIZf0bD8
-djbE9jOLkx7saL08qC8ECrf9utsee+LJCsUYbNgYyIItEy6yVnmF/ICz93Utn1cI
-RfqZr1lM2Ia2LP9eDTmiuR9m+/MzkeRvvJHonNrRJHlcggtYHICvYioh9/jALBcm
-wZ+hTUePVqy4hOCBJ975CXjfKFN4MKQAdeB3EO5eBYAD3Q==
+BgkqhkiG9w0BAQsFAAOCAQEAo5siIstgYy1MjyVaSHpxy6Cq7JT73RhYYudtAy8e
+XwVXqy3xuZtl+i2XaWnsojyHRZ83t+1rVCoesbZefyfz9d6qZJkCkWdKdjiVEu+s
+CJSo+tGyCZQ1ZTb+07WY01P97gfswP+VHN4EjxJmUnLdqJEJsdOckvL1mBfortt6
+CvL7adPwftppNivF64R0QZfOsLIaaOa0oi33DQDDNUdrx5f3xWwYmzw+f95lvbYR
+DXCytT647nc44Gu09erE4sWipIknFBvg3P1D0icFSIoEh44mU9o1lHUFsogXa09g
+8Vkho/rudYrHi/cwwzQlUjZyHPg6k1iU9oZGEaW5gVKxSw==
 -----END CERTIFICATE-----
diff --git a/src/test/ssl/ssl/server-cn-and-alt-names.crt b/src/test/ssl/ssl/server-cn-and-alt-names.crt
index 2bb206e413..406d50dbca 100644
--- a/src/test/ssl/ssl/server-cn-and-alt-names.crt
+++ b/src/test/ssl/ssl/server-cn-and-alt-names.crt
@@ -1,7 +1,7 @@
 -----BEGIN CERTIFICATE-----
 MIIDTjCCAjagAwIBAgIBATANBgkqhkiG9w0BAQsFADBCMUAwPgYDVQQDDDdUZXN0
 IENBIGZvciBQb3N0Z3JlU1FMIFNTTCByZWdyZXNzaW9uIHRlc3Qgc2VydmVyIGNl
-cnRzMB4XDTE4MTEyNzEzNDA1NFoXDTQ2MDQxNDEzNDA1NFowRjEeMBwGA1UECwwV
+cnRzMB4XDTIwMDgzMTA2MDcyM1oXDTQ4MDExNzA2MDcyM1owRjEeMBwGA1UECwwV
 UG9zdGdyZVNRTCB0ZXN0IHN1aXRlMSQwIgYDVQQDDBtjb21tb24tbmFtZS5wZy1z
 c2x0ZXN0LnRlc3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBURL6
 YPWJjVQEZY0uy4HEaTI4ZMjVf+xdwJRntos4aRcdhq2JRNwitI00BLnIK9ur8D8L
@@ -11,10 +11,10 @@ YsWwHgcuEIZk3z287hxuyU3j5isYoRwd5cZZFrG/qBJdukSBRil5/PP5AHsB6lTl
 pae2bdf4TXB7kActIpyTBR0G5Pm5iCZlxgD+QILj/1FLTaNOW7hV+t1J6YfC6jZR
 Dk4MnHMCFasSXcXhAgMBAAGjSzBJMEcGA1UdEQRAMD6CHWRuczEuYWx0LW5hbWUu
 cGctc3NsdGVzdC50ZXN0gh1kbnMyLmFsdC1uYW1lLnBnLXNzbHRlc3QudGVzdDAN
-BgkqhkiG9w0BAQsFAAOCAQEAQeKHXoyipubldf4HUDCXrcIk6KiEs9DMH1DXRk7L
-z2Hr0TljmKoGG5P6OrF4eP82bhXZlQmwHVclB7Pfo5DvoMYmYjSHxcEAeyJ7etxb
-pV11yEkMkCbQpBVtdMqyTpckXM49GTwqD9US5p1E350snq4Duj3O7fSpE4HMfSd8
-dCkYdaCHq2NWH4/MfEBRy096oOIFxqgm6tRCU95ZI8KeeK4WwPXiGV2mb2rHj1kv
-uBRC+sJGSnsLdbZzkpdAN1qnWrJoLezAMdhTmNRUJ7Cq8hAkroFIp+LE+JyxR9Nw
-m6jD3eEwCAQi0pPGLEn4Rq4B8kxzL5F/jTq7PONRvOAdIg==
+BgkqhkiG9w0BAQsFAAOCAQEAdXbTpv6xPsy7YMB5AWwmV50aWJ1J7cNSF2mEhQxK
+LNYQi5Z1Ov/MuWxCYbW5EeMQlSS/XJbBnFJR8dFgUXd36uQoe8jHDjf5ceG/CeVb
+AFCvMu2dgbA/PisONnlJJ5jL3eEHA0hIg7EvBzPA0Y2GseeZfTECPrXYOF8kJHyN
+cQjsLsOJuhkeKXsvpASlAuRx+e/7FebXw2Ak/9tMo2TekiFokuVymhcZbH4YrcGO
+dT60+cMm8+Cd9to/uatbF/f0LOKFgQ8LNDb+ZAytJ4NxXw7DB6LwAXyXQlPS6iMg
+q7A/owJO3mtuHgy5XGhtKnP/0l9pKlGASykYJNIMmSCNgQ==
 -----END CERTIFICATE-----
diff --git a/src/test/ssl/ssl/server-cn-only.crt b/src/test/ssl/ssl/server-cn-only.crt
index 67bf0b1645..a185b50b0a 100644
--- a/src/test/ssl/ssl/server-cn-only.crt
+++ b/src/test/ssl/ssl/server-cn-only.crt
@@ -1,7 +1,7 @@
 -----BEGIN CERTIFICATE-----
 MIIC/DCCAeQCAQIwDQYJKoZIhvcNAQELBQAwQjFAMD4GA1UEAww3VGVzdCBDQSBm
 b3IgUG9zdGdyZVNRTCBTU0wgcmVncmVzc2lvbiB0ZXN0IHNlcnZlciBjZXJ0czAe
-Fw0xODExMjcxMzQwNTRaFw00NjA0MTQxMzQwNTRaMEYxHjAcBgNVBAsMFVBvc3Rn
+Fw0yMDA4MzEwNjA3MjNaFw00ODAxMTcwNjA3MjNaMEYxHjAcBgNVBAsMFVBvc3Rn
 cmVTUUwgdGVzdCBzdWl0ZTEkMCIGA1UEAwwbY29tbW9uLW5hbWUucGctc3NsdGVz
 dC50ZXN0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1bNU8yTuLl/5
 bR4Rp1ET5NMC2wgrTwKQsxSeOzvMmTGeebpEYFc/Hq8rcCQAiL7AbhiZeNg/ca4y
@@ -9,10 +9,10 @@ JdouOdaHaTMFJ8hFDI1tNOGeFK7ecOMBWQ97GxKs/KIqKYW42AN+QZ7l1Apr0CDZ
 K5VTi931JjE4wCIgUgLi2zgwtZYl/kP896F1K5zR7kx773U2dvP3SeV2ziUe+4NH
 5oqdmVMeZyHfB+Fe/uU1AiYgHN/CXfop39tYHR8ARUWx7eJlaaKBoj/0UqH/9Yir
 jdM0vGfrw4JCjIx78caNkNH9fCjesTqODr+IDBJaJv3Jpt9g8puqrYagXLppiaYS
-q5oOAu5fuQIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQCTxkqpNNuO15osb+Lyw2aQ
-RikYZiSJ4uJcOIya6DqSYSNf8wrgGMJAKz9TkCGEG7SszLCASaSIS/s+sR1+bE19
-f6BxoBnppPW8uIkTtQvmGhhcWHO13zMUs8bmg9OY7MvFYJdQAmSqfYebUCYR73So
-OthALxV8h+boW5/xc2XM1NObpcuShQ9/uynm2dL3EbrNjvcoXOwu865FmVMffEn9
-+zhE8xl4kMKObQvB3r2utCmlAmJLaU2ejADncS9Y4ZwRMa7x+vfvekF/FvLEXUal
-QcDlfrZ0xsw/HK7n0/UFXf5fUXq3hgUGcXEdWW7/yTA43qNxednfa+fMqlFztupt
+q5oOAu5fuQIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQB8TNuHgAscHJWExsswCCFX
+qfKjpnF/SKD5DGSj+NKfI2CGxWg4X9D67V470OkgHtQqujKb0sIOrbXz2tCg0Z6u
+rbeNctGXKATCawae1nmlz81xBV5cIjlB2mNMQLY0c0zjWozyEq8kEk6bDZ7Nj3bZ
+bf7QK9xdBfWXRhXWSfk45KasxZU/MN+sdIu/xFyBwSEtqVQsfbBK7kOOmDG2SU48
+MA4km6tPVf86BHQshu8vDkB2zWAdECkMVKudkdPT9sT3u26FSGmboXnWNOlfR7TP
+G9BRh+r0zOntkGhJsqUZcEdoOIShKy+69ly2QP7K78EaWvw5Q2ZUqekAvaA7McPb
 -----END CERTIFICATE-----
diff --git a/src/test/ssl/ssl/server-crldir/a836cc2d.r0 b/src/test/ssl/ssl/server-crldir/a836cc2d.r0
new file mode 100644
index 0000000000..9588d1e524
--- /dev/null
+++ b/src/test/ssl/ssl/server-crldir/a836cc2d.r0
@@ -0,0 +1,11 @@
+-----BEGIN X509 CRL-----
+MIIBnjCBhzANBgkqhkiG9w0BAQsFADBCMUAwPgYDVQQDDDdUZXN0IENBIGZvciBQ
+b3N0Z3JlU1FMIFNTTCByZWdyZXNzaW9uIHRlc3Qgc2VydmVyIGNlcnRzFw0yMDA4
+MzEwNjA3MjNaFw00ODAxMTcwNjA3MjNaMBQwEgIBBhcNMjAwODMxMDYwNzIzWjAN
+BgkqhkiG9w0BAQsFAAOCAQEA2CBoLuLCpXcVSHqQtKnTcz25FyPsGkSO3luiUiG5
+jnI9HvZ9OzeQGGho6XBhVHAmEtwKOo6pcxqDe8Qkf6X7v0AUc19BWkxOXT+sCCdM
+yOvRhNPAhxJToGgKqp41noTSMhZPLsvFEfbbFTZEABScfX2K+XdvQlAYXa3U375E
+71jFenrNh8fNTKfcikmio1rsybQ4PG/ASsrUflQ5LAz3Nm3awdw01auGzRFezq3z
+Ivnq3z5b2q+m653PUsygNRMFVxCAgrvqAadKci7MK/QthCbocrLIhuc9Mmx1Nbkm
+Wnv+La3b5HeH8Zi9Q89IBr12rH70Y6K3hggCUAo9CoK3zw==
+-----END X509 CRL-----
diff --git a/src/test/ssl/ssl/server-multiple-alt-names.crt b/src/test/ssl/ssl/server-multiple-alt-names.crt
index 158153d10c..3a392bc7bc 100644
--- a/src/test/ssl/ssl/server-multiple-alt-names.crt
+++ b/src/test/ssl/ssl/server-multiple-alt-names.crt
@@ -1,7 +1,7 @@
 -----BEGIN CERTIFICATE-----
 MIIDRDCCAiygAwIBAgIBBDANBgkqhkiG9w0BAQsFADBCMUAwPgYDVQQDDDdUZXN0
 IENBIGZvciBQb3N0Z3JlU1FMIFNTTCByZWdyZXNzaW9uIHRlc3Qgc2VydmVyIGNl
-cnRzMB4XDTE4MTEyNzEzNDA1NFoXDTQ2MDQxNDEzNDA1NFowIDEeMBwGA1UECwwV
+cnRzMB4XDTIwMDgzMTA2MDcyM1oXDTQ4MDExNzA2MDcyM1owIDEeMBwGA1UECwwV
 UG9zdGdyZVNRTCB0ZXN0IHN1aXRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
 CgKCAQEA10iQpfVf4nCqjkRcLXP9ONQqdhMPMdjHasKqmsFTx83SZLKUzKMOb56j
 3bg83stqGoId4MIxtqnDKaSg1+kseQ1HCi0cu/E3lHLEkPibl9dyVGhXVnPDBdOp
@@ -11,10 +11,10 @@ YXOKjP4+fWr18HdZLrzsa4xPRa9XcsDNyffjWvQTfptR/2vFKN8Ffv3XUqxUx6av
 VCyRKa8xAUS/pHVGnzFQY+oqWREn2wIDAQABo2cwZTBjBgNVHREEXDBagh1kbnMx
 LmFsdC1uYW1lLnBnLXNzbHRlc3QudGVzdIIdZG5zMi5hbHQtbmFtZS5wZy1zc2x0
 ZXN0LnRlc3SCGioud2lsZGNhcmQucGctc3NsdGVzdC50ZXN0MA0GCSqGSIb3DQEB
-CwUAA4IBAQAuV+4TNADB/AinkjQVyzPtmeWDWZJDByRSGIzGlrYtzzrJzdRkohlL
-svZi0QQWbYq3pkRoUncYXXp/JvS48Ft1jRi87RpLRiPRxJC9Eq77kMS5UKCIs86W
-0nuYQ2tNmgHb7gnLHEr2t9gFEXcLwUAnRfNJK56KVmCl/v3/4kcVDLlL6L+pL80r
-WGKGvixNy3bDCJ/YGJu6NH+H7NMlqFcg07nEWUHgMzETGGycTcPy3S6mY5P/1Ep1
-MCSTucUKoBIte2t5p9vM6bsFIioQDAYABhacmC62Z5xNW8evmNVtBDPLR1THsWhq
-UjzdIzjpDgv1KUCVEPc1uVrZ5eju+aoU
+CwUAA4IBAQBORmS+8OIlqJVyquIl4El7OHuC4f2e4s0/uLnEMgIzuXFyi1E7XgXr
+vqHFNIux6/jFnkgT1kvR6I2yZc2UTmU88cjGp2nLb4qglWN0TQonBpm3Ibd3q6Zk
+h2/Z3z2d0CVZKVeKwmX6sWDx3QBmalLTI9UfmnF+3PM7NXWAEyh+HAUAsQFnq7g0
+hAGZnAcGTpVMPDgw6RPwS0LyRW7+pGUWqunoz5ORgC4kPlS/xDlmtCXJNp1Elar9
+Pt/ovjkHyNMMIQV2HgWqnTtfqUoFQsAejFvVmNHVRBrJwi5+tG10f1UI4ST+Ky+I
+4ECOGan/YOKxWzXMy6B2QInFAcaTflQQ
 -----END CERTIFICATE-----
diff --git a/src/test/ssl/ssl/server-no-names.crt b/src/test/ssl/ssl/server-no-names.crt
index 97e11176f6..6682d9f25e 100644
--- a/src/test/ssl/ssl/server-no-names.crt
+++ b/src/test/ssl/ssl/server-no-names.crt
@@ -1,18 +1,18 @@
 -----BEGIN CERTIFICATE-----
 MIIC1jCCAb4CAQUwDQYJKoZIhvcNAQELBQAwQjFAMD4GA1UEAww3VGVzdCBDQSBm
 b3IgUG9zdGdyZVNRTCBTU0wgcmVncmVzc2lvbiB0ZXN0IHNlcnZlciBjZXJ0czAe
-Fw0xODExMjcxMzQwNTRaFw00NjA0MTQxMzQwNTRaMCAxHjAcBgNVBAsMFVBvc3Rn
+Fw0yMDA4MzEwNjA3MjNaFw00ODAxMTcwNjA3MjNaMCAxHjAcBgNVBAsMFVBvc3Rn
 cmVTUUwgdGVzdCBzdWl0ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
 AJ85/vh52iDZAeQmWt47o0kR7VVlRLGf4sF4cfxPl+eIWIzhib1fajdcqFiy81LC
 +t9bAyRqMyR3dve9RGK6IDFjMH/0DBf3tFSRnxN+5TdSAhKIJslmtUdOl8kS/smF
 4+BikCg509aq0U+ac79e/q42OyvH9X/cI6i9SPd4hzJDMCX54LZT1Of/90nSQX6E
 Oc5Hcj/d7psBugmMBW8uXYAGvJpq14e5RoK78F/mYbUNqtc1c8pi4/4quSMeEfQp
 Dgmzee7ts8SIbQT8mYJHjnaPvZYpv4+Ikc7F0wzLO1neTpsYaVvDrSMLBCdQkCU8
-vgb1T6WlVgbp/sfE5okSxx8CAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAh+erODlf
-+mEK2toZhaAmikNJ3Toj9P7I0C0Mo/tl2aVz8jQc/ft5t3blwZHfRzC9WmgnZLdY
-yiCVgUlf9Kwhi836Btbczj3cK6MrngQneFBzSnCzsj40CuQAw5TOI8XRFFGL+fpl
-o7ZnbmMZRhkPqDmNWXfpu7CYOFQyExkDoo0lTfqM+tF8zuKVTmsuWWvZpjuvqWFQ
-/L+XRXi0cvhh+DY9vJiKNRg4exF7/tSedTJmLA8skuaXgAVez4rqzX4k1XnQo6Vi
-YpAIQ4dGiijY24fDq2I/6pO3xlWtN+Lwu44Mnn2vWRtXijT69P5R12W8XS7+ciTU
-NXu/iOo8f7mNDA==
+vgb1T6WlVgbp/sfE5okSxx8CAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAvRq8eCJl
+gAu2LT21OKmuhiMLPWyNVbyHo+A8UOKBXo1WwRbU4W0u2Ki5LenriekpW2A4qiZ1
+HDxpLaSquSIzPwtDvnMqtQ4BDEaikwmGxEl5EIR2+75riV9BNFgA0g+zVTPN+I33
+/OdNbI9XvIVkyOfxgaoE9kcWF6wRLB70oOYtuInUajEuG8GEKR5vrWXPa6sZoUxh
+ziGM/FHSNs3XqLDJxcUx7FMJH7iz9IlhJVN4aEEYX/L3cVnIWCnlNYp1UMHBTBqD
+aaGVTS7I8cIqOT1I0MxRqKBnTDXgfKb6yHYCgdQUzuFH3BcM08D7G6iuH6DCL3ib
+w5kP06Ufd7oOlA==
 -----END CERTIFICATE-----
diff --git a/src/test/ssl/ssl/server-revoked.crt b/src/test/ssl/ssl/server-revoked.crt
index 1ca5e6d3ef..2fa1a6ea71 100644
--- a/src/test/ssl/ssl/server-revoked.crt
+++ b/src/test/ssl/ssl/server-revoked.crt
@@ -1,7 +1,7 @@
 -----BEGIN CERTIFICATE-----
 MIIC/DCCAeQCAQYwDQYJKoZIhvcNAQELBQAwQjFAMD4GA1UEAww3VGVzdCBDQSBm
 b3IgUG9zdGdyZVNRTCBTU0wgcmVncmVzc2lvbiB0ZXN0IHNlcnZlciBjZXJ0czAe
-Fw0xODExMjcxMzQwNTRaFw00NjA0MTQxMzQwNTRaMEYxHjAcBgNVBAsMFVBvc3Rn
+Fw0yMDA4MzEwNjA3MjNaFw00ODAxMTcwNjA3MjNaMEYxHjAcBgNVBAsMFVBvc3Rn
 cmVTUUwgdGVzdCBzdWl0ZTEkMCIGA1UEAwwbY29tbW9uLW5hbWUucGctc3NsdGVz
 dC50ZXN0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAooPO8lSz434p
 4PBYBbTN8jkLW3cHEpTCH4yvC0V40hzGEl30HPLp82e+kxr+Q0+gd82fvc4Yth5I
@@ -9,10 +9,10 @@ PKINznp28GMs5/E9cUU3hMK4jFhKLMiOeIve3M/9ryHK874qpNjJoSxxPz7+s2eq
 WoFc2px0KFIamTTLfi7Ju9aPb/AMlZNsUnbRsj7fQc7EJ8rwOnezw2Wy5VK4soX+
 qpuJ0Nm44ApzT8YmjYX/kAX0yQxgQuYbpcBWr9cOQjegu3FAqHqRh9ye7d8jQzCv
 34Wg/ar4rkqyQDcokuWAE7KQbnk51t7omzhM8eswFOAL1pas/8jWBvy0VjYVU34P
-9aXxP8GiHQIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQAS9abT/PhJgwAnm46Rzu16
-lL7tDb3SeR1RL25xZLzCexHcYJFi7aDZix3QlLRvf6HPqqUPuPYRICTBF4+fieEh
-r5LotdAnadfYONwoB5GiYy2d93VGqlLosI27R6/tVvImXupviPpIYMDgBBRr1pZc
-ykQOjog6T+xk9TqsfFQDe2/VKF7a5RxOA/V77GZ5qge5Nlx9jSXQ/WUG9vDQj9BA
-d4nOwvjauKlcSqUU/3uVKntXQTNjmyq7S75eBitS920LLfjTL9LInLugDikFa/J/
-yPBkJLa/+rNMPikcnF3ci4Oi/XwLA8kGdGZAADuiIOeyORMuLFoTk7KpOYGKS5/U
+9aXxP8GiHQIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQANC+ABgpTg8mHipdTBhhUH
+klkvnmPwzUyfTMfjAMpM/aMXY12R2pcKbDm7uSFZQPyL4w2W6sa56rbFzXLER9U1
+woOdlUfpREtISaC+wI+plhPLvERW9Id57IWNuOpPaAP2KWOVa9gtRVIBj/Z09+3w
+nB3aqHxCl7GKI78ruqR8VGAhSl58KAVzG7TS25848nYIijZ4Aeoqr99x6EuHAVhf
+47xShRQTQZTzANaXqMaqeR4UoPxb5GUt1I2+4Q9Q0FC3M4CVgCbxgaKqmNms88k9
+yrXx+BA5fDXMhcyX/R09t+aPBnKhC+dmLohmB9cV0jgQLAGaN81+ZXyyghXk3iCV
 -----END CERTIFICATE-----
diff --git a/src/test/ssl/ssl/server-single-alt-name.crt b/src/test/ssl/ssl/server-single-alt-name.crt
index e7403f3a6b..6637fa467b 100644
--- a/src/test/ssl/ssl/server-single-alt-name.crt
+++ b/src/test/ssl/ssl/server-single-alt-name.crt
@@ -1,7 +1,7 @@
 -----BEGIN CERTIFICATE-----
 MIIDCzCCAfOgAwIBAgIBAzANBgkqhkiG9w0BAQsFADBCMUAwPgYDVQQDDDdUZXN0
 IENBIGZvciBQb3N0Z3JlU1FMIFNTTCByZWdyZXNzaW9uIHRlc3Qgc2VydmVyIGNl
-cnRzMB4XDTE4MTEyNzEzNDA1NFoXDTQ2MDQxNDEzNDA1NFowIDEeMBwGA1UECwwV
+cnRzMB4XDTIwMDgzMTA2MDcyM1oXDTQ4MDExNzA2MDcyM1owIDEeMBwGA1UECwwV
 UG9zdGdyZVNRTCB0ZXN0IHN1aXRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
 CgKCAQEAxYocLWWuiDsDzJ7wLc0zfwkGJAEy4hlHjTA5GXSEnGPlOnx1fxejZOGL
 1HLff5h8zB+SQXrplHCcwwRrxVgGY7P59kXMXX1akTwXUJHc/EoTtqLO+6fHLygz
@@ -9,11 +9,11 @@ F1d0i5NPO3xrk1wMt7bYLhiPbWpplWiHXzbJy8wf3dXgzCwtxXf8Z1UqjtCnA/Zk
 J/kPWuHJxzH5OvDJvZsq+Fbkl3catFpwUlAV9TKsC78W/K5I+afzppsmSvsIKAWW
 Dp7g71IVjvJeI6Aui2yhDn9iuJMuKe9RMYIwJLFqiX3urHcjaBSkJm6Lsf7gO30v
 kVwIyyGXRNTfZ2yPDoSXVZvOnq+gKwIDAQABoy4wLDAqBgNVHREEIzAhgh9zaW5n
-bGUuYWx0LW5hbWUucGctc3NsdGVzdC50ZXN0MA0GCSqGSIb3DQEBCwUAA4IBAQBU
-8wp8KZfS8vClx2gYSRlbXu3J1oAu4EBh45OuuRuLOJUhQZYcjFB3d/s0R1kcCQkB
-EekV9X1iQSzk/HQq4uWi6ViUzxTR67Q6TXEFo8iuqJ6Rag7R7G6fhRD1upf1lev+
-rz7F9GsoWLyLAg8//DUfq1kfQUyy6TxamoRs0vipZ4s0p4G8rbRCxKT1WTRLJFdd
-fSDVuMNuQQKTQXNdp6cYn+ikEhbUv/gG2S7Xiy2UM8oR7DR54nZBAKxgujWJZPfX
-/ieSwLxnLFyePwtwgk9xMmywFBjHWTxSdyI1UnJwWC917BSw4M00djsRv5COsBX7
-v/Co7oiMyTrCqyCsWOBu
+bGUuYWx0LW5hbWUucGctc3NsdGVzdC50ZXN0MA0GCSqGSIb3DQEBCwUAA4IBAQBP
+tJo8pTdcrsvooz15feSdJpxxmUut7/ub4ddRZQj08jL7SrUtAfmiUFBqaR618lr7
++7L30XkVv4j0p6U5jaE6V0L/r/GH6XyFLoH7ygTa4mmSrK8BWU1h2PvcqswxbxBY
+5Bu7pTajip2JuQ+6+rKfEvchGsELtWc1526QIa3LFsHTL8eWCFny16K7zlMkfFB1
+w58suL8ucTWfEcRByKkLD7wcZpAFvQD80BU7TvErr4ydEiNfH5NwrrUzycracPnc
+WKTjbAkRO615ht1z5E/TTLXENPlmibu08/g+Y8wu61S2Bjhn5LM33zKb/OrpVraY
+vVEKKU2NkD8bb+ztzu/H
 -----END CERTIFICATE-----
diff --git a/src/test/ssl/ssl/server-ss.crt b/src/test/ssl/ssl/server-ss.crt
index d775e6029a..6662afe3af 100644
--- a/src/test/ssl/ssl/server-ss.crt
+++ b/src/test/ssl/ssl/server-ss.crt
@@ -1,8 +1,8 @@
 -----BEGIN CERTIFICATE-----
-MIIDGDCCAgCgAwIBAgIUVR71MjsbvBO6T1gJQaL/6hMwhqQwDQYJKoZIhvcNAQEL
+MIIDGDCCAgCgAwIBAgIUby7HZZ6t7KHCu15JC/MVcj8VEYcwDQYJKoZIhvcNAQEL
 BQAwRjEkMCIGA1UEAwwbY29tbW9uLW5hbWUucGctc3NsdGVzdC50ZXN0MR4wHAYD
-VQQLDBVQb3N0Z3JlU1FMIHRlc3Qgc3VpdGUwHhcNMTgxMTI3MTM0MDU0WhcNNDYw
-NDE0MTM0MDU0WjBGMSQwIgYDVQQDDBtjb21tb24tbmFtZS5wZy1zc2x0ZXN0LnRl
+VQQLDBVQb3N0Z3JlU1FMIHRlc3Qgc3VpdGUwHhcNMjAwODMxMDYwNzIzWhcNNDgw
+MTE3MDYwNzIzWjBGMSQwIgYDVQQDDBtjb21tb24tbmFtZS5wZy1zc2x0ZXN0LnRl
 c3QxHjAcBgNVBAsMFVBvc3RncmVTUUwgdGVzdCBzdWl0ZTCCASIwDQYJKoZIhvcN
 AQEBBQADggEPADCCAQoCggEBANWzVPMk7i5f+W0eEadRE+TTAtsIK08CkLMUnjs7
 zJkxnnm6RGBXPx6vK3AkAIi+wG4YmXjYP3GuMiXaLjnWh2kzBSfIRQyNbTThnhSu
@@ -10,10 +10,10 @@ zJkxnnm6RGBXPx6vK3AkAIi+wG4YmXjYP3GuMiXaLjnWh2kzBSfIRQyNbTThnhSu
 Jf5D/PehdSuc0e5Me+91Nnbz90nlds4lHvuDR+aKnZlTHmch3wfhXv7lNQImIBzf
 wl36Kd/bWB0fAEVFse3iZWmigaI/9FKh//WIq43TNLxn68OCQoyMe/HGjZDR/Xwo
 3rE6jg6/iAwSWib9yabfYPKbqq2GoFy6aYmmEquaDgLuX7kCAwEAATANBgkqhkiG
-9w0BAQsFAAOCAQEAtHR6o4UIO/aWEAzcmnJKsQDC999jbQGiqs9+v62mz5TvCk/1
-gL9/s/yfGY+pnDGW1ijI2xiL9KCJzjd8YB+F8iUViVQ6uHBxghxC1H2qOIr2UPFQ
-gQRu7d0DByQBsiXMOdw10luGo1oHhqMe5J7VyMVG/7aRpr6zYKrH7PzsB8ucvxzv
-Lm8ez0WBPebV69sim431iJcVcxxBbFd4qUJ9cHIc7VO2mSaazsIOzbd400POF/vk
-gfpDs48GfnZ+X3hgoQA4u7eudLqttI+j1xV+IHlCtaa1nDHymUrN/FhI1x+6c1SU
-V12eHqVatPMe0d+OCJPqIL9lbe+sGXlxDkMqAQ==
+9w0BAQsFAAOCAQEAO68c0amf+x5U7o6nZfNcwwMEY3wPt/NYWnfwp0+/5R50KY2L
+ZKqKxN26BQPFID2j/H84ve5idcJoilzy3W4/P5hs7R53sTyID/fFz6xB7p3eQnJO
+I6YT8D+dcNnipjK3O0O4Htqq7L25idkmYM8HxeSVWC65MzbUI9nLzqg4FRv3pM+m
+AM9Cpq41j8mhN3NS2vhpgy9T6qrM8v0usJuoAMMnwp0yXo3/ZfpoT80BaGhlWR5g
+Wm36rA50Z0Vz1zgRJb/xXl9SEnySWAM/WIuRiAHRw9J5K3ye8U8aW+xV3/uQEtG2
+s7h6mW3YqdIh2o5Gc83rLEvPOHLFohKMvFmJTA==
 -----END CERTIFICATE-----
diff --git a/src/test/ssl/ssl/server.crl b/src/test/ssl/ssl/server.crl
index 717951c26a..9588d1e524 100644
--- a/src/test/ssl/ssl/server.crl
+++ b/src/test/ssl/ssl/server.crl
@@ -1,11 +1,11 @@
 -----BEGIN X509 CRL-----
 MIIBnjCBhzANBgkqhkiG9w0BAQsFADBCMUAwPgYDVQQDDDdUZXN0IENBIGZvciBQ
-b3N0Z3JlU1FMIFNTTCByZWdyZXNzaW9uIHRlc3Qgc2VydmVyIGNlcnRzFw0xODEx
-MjcxMzQwNTVaFw00NjA0MTQxMzQwNTVaMBQwEgIBBhcNMTgxMTI3MTM0MDU1WjAN
-BgkqhkiG9w0BAQsFAAOCAQEAbVuJXemxM6HLlIHGWlQvVmsmG4ZTQWiDnZjfmrND
-xB4XsvZNPXnFkjdBENDROrbDRwm60SJDW73AbDbfq1IXAzSpuEyuRz61IyYKo0wq
-nmObJtVdIu3bVlWIlDXaP5Emk3d7ouCj5f8Kyeb8gm4pL3N6e0eI63hCaS39hhE6
-RLGh9HU9ht1kKfgcTwmB5b2HTPb4M6z1AmSIaMVqZTjIspsUgNF2+GBm3fOnOaiZ
-SEXWtgjMRXiIHbtU0va3LhSH5OSW0mh+L9oGUQDYnyuudnWGpulhqIp4qVkJRDDu
-41HpD83dV2uRtBLvc25AFHj7kXBflbO3gvGZVPYf1zVghQ==
+b3N0Z3JlU1FMIFNTTCByZWdyZXNzaW9uIHRlc3Qgc2VydmVyIGNlcnRzFw0yMDA4
+MzEwNjA3MjNaFw00ODAxMTcwNjA3MjNaMBQwEgIBBhcNMjAwODMxMDYwNzIzWjAN
+BgkqhkiG9w0BAQsFAAOCAQEA2CBoLuLCpXcVSHqQtKnTcz25FyPsGkSO3luiUiG5
+jnI9HvZ9OzeQGGho6XBhVHAmEtwKOo6pcxqDe8Qkf6X7v0AUc19BWkxOXT+sCCdM
+yOvRhNPAhxJToGgKqp41noTSMhZPLsvFEfbbFTZEABScfX2K+XdvQlAYXa3U375E
+71jFenrNh8fNTKfcikmio1rsybQ4PG/ASsrUflQ5LAz3Nm3awdw01auGzRFezq3z
+Ivnq3z5b2q+m653PUsygNRMFVxCAgrvqAadKci7MK/QthCbocrLIhuc9Mmx1Nbkm
+Wnv+La3b5HeH8Zi9Q89IBr12rH70Y6K3hggCUAo9CoK3zw==
 -----END X509 CRL-----
diff --git a/src/test/ssl/ssl/server_ca.crt b/src/test/ssl/ssl/server_ca.crt
index 9f727bf9e9..94da6cd092 100644
--- a/src/test/ssl/ssl/server_ca.crt
+++ b/src/test/ssl/ssl/server_ca.crt
@@ -1,7 +1,7 @@
 -----BEGIN CERTIFICATE-----
 MIIDDTCCAfWgAwIBAgIBATANBgkqhkiG9w0BAQsFADBAMT4wPAYDVQQDDDVUZXN0
 IHJvb3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NMIHJlZ3Jlc3Npb24gdGVzdCBzdWl0
-ZTAeFw0xODExMjcxMzQwNTRaFw00NjA0MTQxMzQwNTRaMEIxQDA+BgNVBAMMN1Rl
+ZTAeFw0yMDA4MzEwNjA3MjNaFw00ODAxMTcwNjA3MjNaMEIxQDA+BgNVBAMMN1Rl
 c3QgQ0EgZm9yIFBvc3RncmVTUUwgU1NMIHJlZ3Jlc3Npb24gdGVzdCBzZXJ2ZXIg
 Y2VydHMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDiSnYZbmc9vpCt
 Ku1sKV9l663JCceubhMw8Gg16kV0hXEFf/TgGC4zkiYNHN7+G45YD7Nq0kBCq3dH
@@ -10,10 +10,10 @@ t2wPCc6c8pQoI64dfprVqPkvzoe1WBpZNetkUTk20v08jNeRa7XdRbRR6we1s9VG
 QW9YWdH9N5ctaUXMG6lLV2OAjs+W1smpKfpIpMCA1lPGlElu70hynon/nQQvBP77
 SfQpZVc0esM18jkZpr5LEKUCw+x6LaMsqmBHpAULfCffxn2r0uMBW4L4VaGg3W6F
 h6iuJwRfAgMBAAGjEDAOMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEB
-AFlcKTaU/Ug3Q0hr3P1UQ6dWyK4aVn9rs4jvVfFl0a0RnbBowqK2C+zQVUWYTcjo
-KHREVje65goj6VzRB6ko/9mAQ6PZP8jRuRhfCmvmvSQ/mWdgPzSRsUh9MwgEm9c2
-vNbqwaznEU8cYZnLpHiR9O5S7/qWWxehjYtxk5Eb4J006YglYfHnhrRFJvPbiqlf
-IOEivZ7gIVfvaOTbLjmN2kLOnzdlwpXGjxxg4Nu9ZhXOhfrplzUvRfmqvVsDiHXb
-USIdX+OFZZqr64IKG4drT4K4Bt2wupOEyX4ZFsUXXd+Hgq83SWmV4wzflcpmGkLC
-JZ3CEMu8/WA5uQBXdQUozlE=
+AArYO305zkNZc+vdbeXNpgi1/FrOHl2b0DvG4i2gcUVDvvjIHUnVLf2cak+81vER
+CqlCkutXxB+/fyxVXYtLKXQh0D/68QikH+ImEavrUrANXvQRvoixIjrfub/nZB75
+EiOTIR2N0/m6ndjCHJU0W8N7Tt9qob31e3bVJBZOc+9e80y8GDQiMKYACmet9zUR
+hR/yvJhUsH/u5Y7OwrvcyCs+PJXzPnZTSsatSkHI4KY22+7K+ZhscLIaBKjqlIDj
++fHBrutW9jtog1E3JUO9ZHokB1qlRLs4YhpQ8YzHRabEBaX892ZPLNwtmFLOWK1p
+9klR7/RXnu13nStNIYAHk20=
 -----END CERTIFICATE-----
diff --git a/src/test/ssl/t/001_ssltests.pl b/src/test/ssl/t/001_ssltests.pl
index fd2727b568..dd8833ac48 100644
--- a/src/test/ssl/t/001_ssltests.pl
+++ b/src/test/ssl/t/001_ssltests.pl
@@ -13,7 +13,7 @@ use SSLServer;
 
 if ($ENV{with_openssl} eq 'yes')
 {
-    plan tests => 93;
+    plan tests => 100;
 }
 else
 {
@@ -214,6 +214,12 @@ test_connect_fails(
     "sslrootcert=ssl/root+server_ca.crt sslmode=verify-ca sslcrl=ssl/client.crl",
     qr/SSL error/,
     "CRL belonging to a different CA");
+# The same for CRL directory, fails
+test_connect_fails(
+    $common_connstr,
+    "sslrootcert=ssl/root+server_ca.crt sslmode=verify-ca sslcrl=ssl/client-crldir",
+    qr/SSL error/,
+    "directory CRL belonging to a different CA");
 
 # With the correct CRL, succeeds (this cert is not revoked)
 test_connect_ok(
@@ -221,6 +227,12 @@ test_connect_ok(
     "sslrootcert=ssl/root+server_ca.crt sslmode=verify-ca sslcrl=ssl/root+server.crl",
     "CRL with a non-revoked cert");
 
+# With the correct server CRL directory, succeeds (this cert is not revoked)
+test_connect_ok(
+    $common_connstr,
+    "sslrootcert=ssl/root+server_ca.crt sslmode=verify-ca sslcrl=ssl/root+server-crldir",
+    "directory CRL with a non-revoked cert");
+
 # Check that connecting with verify-full fails, when the hostname doesn't
 # match the hostname in the server's certificate.
 $common_connstr =
@@ -346,7 +358,12 @@ test_connect_fails(
     $common_connstr,
     "sslrootcert=ssl/root+server_ca.crt sslmode=verify-ca sslcrl=ssl/root+server.crl",
     qr/SSL error/,
-    "does not connect with client-side CRL");
+    "does not connect with client-side CRL file");
+test_connect_fails(
+    $common_connstr,
+    "sslrootcert=ssl/root+server_ca.crt sslmode=verify-ca sslcrl=ssl/root+server-crldir",
+    qr/SSL error/,
+    "does not connect with client-side CRL directory");
 
 # pg_stat_ssl
 command_like(
@@ -545,6 +562,16 @@ test_connect_ok(
 test_connect_fails($common_connstr, "sslmode=require sslcert=ssl/client.crt",
     qr/SSL error/, "intermediate client certificate is missing");
 
+# test server-side CRL directory
+switch_server_cert($node, 'server-cn-only', undef, 'root+client-crldir');
+
+# revoked client cert
+test_connect_fails(
+    $common_connstr,
+    "user=ssltestuser sslcert=ssl/client-revoked.crt sslkey=ssl/client-revoked_tmp.key",
+    qr/SSL error/,
+    "certificate authorization fails with revoked client cert with server-side CRL directory");
+
 # clean up
 foreach my $key (@keys)
 {
diff --git a/src/test/ssl/t/SSLServer.pm b/src/test/ssl/t/SSLServer.pm
index f5987a003e..381e8a95d6 100644
--- a/src/test/ssl/t/SSLServer.pm
+++ b/src/test/ssl/t/SSLServer.pm
@@ -150,6 +150,8 @@ sub configure_test_server_for_ssl
     copy_files("ssl/root+client_ca.crt", $pgdata);
     copy_files("ssl/root_ca.crt",        $pgdata);
     copy_files("ssl/root+client.crl",    $pgdata);
+    mkdir("$pgdata/root+client-crldir");
+    copy_files("ssl/root+client-crldir/*", "$pgdata/root+client-crldir/");
 
     # Stop and restart server to load new listen_addresses.
     $node->restart;
@@ -167,6 +169,7 @@ sub switch_server_cert
     my $node     = $_[0];
     my $certfile = $_[1];
     my $cafile   = $_[2] || "root+client_ca";
+    my $crlfile  = $_[3] || "root+client.crl";
     my $pgdata   = $node->data_dir;
 
     open my $sslconf, '>', "$pgdata/sslconfig.conf";
@@ -174,7 +177,7 @@ sub switch_server_cert
     print $sslconf "ssl_ca_file='$cafile.crt'\n";
     print $sslconf "ssl_cert_file='$certfile.crt'\n";
     print $sslconf "ssl_key_file='$certfile.key'\n";
-    print $sslconf "ssl_crl_file='root+client.crl'\n";
+    print $sslconf "ssl_crl_file='$crlfile'\n";
     close $sslconf;
 
     $node->restart;
-- 
2.18.4

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Tom Lane

Date:

25 September 2020, 04:59:50

Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> Thank you Bruce, Michael. This is a rebased version.

I really strongly object to all the encoded data in this patch.
One cannot read it, one cannot even easily figure out how long
it is until the tests break by virtue of the certificates expiring.

One can, however, be entirely certain that they *will* break at
some point.  I don't like the idea of time bombs in our test suite.
That being the case, it'd likely be better to drop all the pre-made
certificates and have the test scripts create them on the fly.
That'd remove both the documentation problem (i.e., having readable
info as to how the certificates were made) and the expiration problem.

            regards, tom lane

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Kyotaro Horiguchi

Date:

28 September 2020, 03:21:51

Hello.

At Fri, 25 Sep 2020 13:30:06 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> On Thu, Sep 24, 2020 at 09:59:50PM -0400, Tom Lane wrote:
> > Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> > > Thank you Bruce, Michael. This is a rebased version.
> > 
> > I really strongly object to all the encoded data in this patch.
> > One cannot read it, one cannot even easily figure out how long
> > it is until the tests break by virtue of the certificates expiring.

I thought the same but the current source tree contains generated
certificates, perhaps for developer's convenience. This patch follows
the policy (if it is correct..). If certificates expiring matters,
don't we need to remove the certificates in the current tree?

(Anyway we experenced replacement of existing certificates due to
obsoletion of a cipher algorithm and will face the same when the
current cipher algorithm gets obsolete.)

> > One can, however, be entirely certain that they *will* break at
> > some point.  I don't like the idea of time bombs in our test suite.
> > That being the case, it'd likely be better to drop all the pre-made
> > certificates and have the test scripts create them on the fly.
> > That'd remove both the documentation problem (i.e., having readable
> > info as to how the certificates were made) and the expiration problem.
> 
> I am not planning to apply the test parts of this patch.  I think
> having the committer test it is sufficient.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Bruce Momjian

Date:

03 October 2020, 05:55:45

On Fri, Sep 25, 2020 at 09:33:48AM +0900, Kyotaro Horiguchi wrote:
> At Thu, 24 Sep 2020 11:43:40 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > On Thu, Sep 24, 2020 at 12:44:01PM +0900, Michael Paquier wrote:
> > > On Tue, Sep 01, 2020 at 10:27:03PM -0400, Bruce Momjian wrote:
> > > > OK, good.  Let's wait a few days and I will then apply it for PG 14.
> > > 
> > > It has been a few days, and nothing has happened here.  I have not
> > > looked at the patch in details, so I cannot say if that's fine or not,
> > > but please note that the patch fails to apply per the CF bot.
> > 
> > I will handle it.
> 
> Thank you Bruce, Michael. This is a rebased version.
> 
> regards.
> 
> -- 
> Kyotaro Horiguchi
> NTT Open Source Software Center

> >From 2978479ada887284eae0ed36c8acf29f1a002feb Mon Sep 17 00:00:00 2001
> From: Kyotaro Horiguchi <horikyoga.ntt@gmail.com>
> Date: Tue, 21 Jul 2020 23:01:27 +0900
> Subject: [PATCH v2] Allow directory name for GUC ssl_crl_file and connection
>  option sslcrl
> 
> X509_STORE_load_locations accepts a directory, which leads to
> on-demand loading method with which method only relevant CRLs are
> loaded.

Uh, I think this CRL patch is the wrong patch.  This thread is about the
clientcert=verify-ca in pg_hba.conf.  I will use the patch I developed
and posted on Tue, 1 Sep 2020 11:47:34 -0400 in this thread.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Kyotaro Horiguchi

Date:

05 October 2020, 04:25:08

At Fri, 2 Oct 2020 22:55:45 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> On Fri, Sep 25, 2020 at 09:33:48AM +0900, Kyotaro Horiguchi wrote:
> > At Thu, 24 Sep 2020 11:43:40 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > > On Thu, Sep 24, 2020 at 12:44:01PM +0900, Michael Paquier wrote:
> > > > On Tue, Sep 01, 2020 at 10:27:03PM -0400, Bruce Momjian wrote:
> > > > > OK, good.  Let's wait a few days and I will then apply it for PG 14.
> > > > 
> > > > It has been a few days, and nothing has happened here.  I have not
> > > > looked at the patch in details, so I cannot say if that's fine or not,
> > > > but please note that the patch fails to apply per the CF bot.
> > > 
> > > I will handle it.
> > 
> > Thank you Bruce, Michael. This is a rebased version.
> > 
> > regards.
> > 
> > -- 
> > Kyotaro Horiguchi
> > NTT Open Source Software Center
> 
> > >From 2978479ada887284eae0ed36c8acf29f1a002feb Mon Sep 17 00:00:00 2001
> > From: Kyotaro Horiguchi <horikyoga.ntt@gmail.com>
> > Date: Tue, 21 Jul 2020 23:01:27 +0900
> > Subject: [PATCH v2] Allow directory name for GUC ssl_crl_file and connection
> >  option sslcrl
> > 
> > X509_STORE_load_locations accepts a directory, which leads to
> > on-demand loading method with which method only relevant CRLs are
> > loaded.
> 
> Uh, I think this CRL patch is the wrong patch.  This thread is about the
> clientcert=verify-ca in pg_hba.conf.  I will use the patch I developed
> and posted on Tue, 1 Sep 2020 11:47:34 -0400 in this thread.

Mmmm. Sorry for the silly mistake. I'm confused with another one.

FWIW, the cause is a rewording of "cannot" to "can not". This is the
right one.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
index d62d1a061c..bad3c3469c 100644
--- a/doc/src/sgml/client-auth.sgml
+++ b/doc/src/sgml/client-auth.sgml
@@ -2044,13 +2044,10 @@ host ... radius radiusservers="server1,server2" radiussecrets="""secret one"",""
    </para>
 
    <para>
-    In a <filename>pg_hba.conf</filename> record specifying certificate
-    authentication, the authentication option <literal>clientcert</literal> is
-    assumed to be <literal>verify-ca</literal> or <literal>verify-full</literal>,
-    and it cannot be turned off since a client certificate is necessary for this
-    method. What the <literal>cert</literal> method adds to the basic
-    <literal>clientcert</literal> certificate validity test is a check that the
-    <literal>cn</literal> attribute matches the database user name.
+    It is redundant to use the <literal>clientcert</literal> option with
+    <literal>cert</literal> authentication because <literal>cert</literal>
+    authentication is effectively <literal>trust</literal> authentication
+    with <literal>clientcert=verify-full</literal>.
    </para>
   </sect1>
 
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 418aa3f85c..17e938148c 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -2345,9 +2345,8 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433
    The <literal>clientcert</literal> authentication option is available for
    all authentication methods, but only in <filename>pg_hba.conf</filename> lines
    specified as <literal>hostssl</literal>.  When <literal>clientcert</literal> is
-   not specified or is set to <literal>no-verify</literal>, the server will still
-   verify any presented client certificates against its CA file, if one is
-   configured — but it will not insist that a client certificate be presented.
+   not specified, the server verifies the client certificate against its CA
+   file only if a client certificate is presented and the CA is configured.
   </para>
 
   <para>
diff --git a/src/backend/libpq/hba.c b/src/backend/libpq/hba.c
index 7b54ffc31e..8de437422d 100644
--- a/src/backend/libpq/hba.c
+++ b/src/backend/libpq/hba.c
@@ -1730,29 +1730,24 @@ parse_hba_auth_opt(char *name, char *val, HbaLine *hbaline,
             *err_msg = "clientcert can only be configured for \"hostssl\" rows";
             return false;
         }
-        if (strcmp(val, "1") == 0
-            || strcmp(val, "verify-ca") == 0)
-        {
-            hbaline->clientcert = clientCertCA;
-        }
-        else if (strcmp(val, "verify-full") == 0)
+
+         if (strcmp(val, "verify-full") == 0)
         {
             hbaline->clientcert = clientCertFull;
         }
-        else if (strcmp(val, "0") == 0
-                 || strcmp(val, "no-verify") == 0)
+         else if (strcmp(val, "verify-ca") == 0)
         {
             if (hbaline->auth_method == uaCert)
             {
                 ereport(elevel,
                         (errcode(ERRCODE_CONFIG_FILE_ERROR),
-                         errmsg("clientcert cannot be set to \"no-verify\" when using \"cert\" authentication"),
+                         errmsg("clientcert only accepts \"verify-full\" when using \"cert\" authentication"),
                          errcontext("line %d of configuration file \"%s\"",
                                     line_num, HbaFileName)));
-                *err_msg = "clientcert cannot be set to \"no-verify\" when using \"cert\" authentication";
+                *err_msg = "clientcert can only be set to \"verify-full\" when using \"cert\" authentication";
                 return false;
             }
-            hbaline->clientcert = clientCertOff;
+            hbaline->clientcert = clientCertCA;
         }
         else
         {

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Bruce Momjian

Date:

05 October 2020, 21:02:34

On Mon, Oct  5, 2020 at 10:25:08AM +0900, Kyotaro Horiguchi wrote:
> > > >From 2978479ada887284eae0ed36c8acf29f1a002feb Mon Sep 17 00:00:00 2001
> > > From: Kyotaro Horiguchi <horikyoga.ntt@gmail.com>
> > > Date: Tue, 21 Jul 2020 23:01:27 +0900
> > > Subject: [PATCH v2] Allow directory name for GUC ssl_crl_file and connection
> > >  option sslcrl
> > > 
> > > X509_STORE_load_locations accepts a directory, which leads to
> > > on-demand loading method with which method only relevant CRLs are
> > > loaded.
> > 
> > Uh, I think this CRL patch is the wrong patch.  This thread is about the
> > clientcert=verify-ca in pg_hba.conf.  I will use the patch I developed
> > and posted on Tue, 1 Sep 2020 11:47:34 -0400 in this thread.
> 
> Mmmm. Sorry for the silly mistake. I'm confused with another one.
> 
> FWIW, the cause is a rewording of "cannot" to "can not". This is the
> right one.

Yes, that is the version I was going to apply.  I will do it today. 
Thanks.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Bruce Momjian

Date:

05 October 2020, 23:07:50

On Mon, Oct  5, 2020 at 02:02:34PM -0400, Bruce Momjian wrote:
> On Mon, Oct  5, 2020 at 10:25:08AM +0900, Kyotaro Horiguchi wrote:
> > > > >From 2978479ada887284eae0ed36c8acf29f1a002feb Mon Sep 17 00:00:00 2001
> > > > From: Kyotaro Horiguchi <horikyoga.ntt@gmail.com>
> > > > Date: Tue, 21 Jul 2020 23:01:27 +0900
> > > > Subject: [PATCH v2] Allow directory name for GUC ssl_crl_file and connection
> > > >  option sslcrl
> > > > 
> > > > X509_STORE_load_locations accepts a directory, which leads to
> > > > on-demand loading method with which method only relevant CRLs are
> > > > loaded.
> > > 
> > > Uh, I think this CRL patch is the wrong patch.  This thread is about the
> > > clientcert=verify-ca in pg_hba.conf.  I will use the patch I developed
> > > and posted on Tue, 1 Sep 2020 11:47:34 -0400 in this thread.
> > 
> > Mmmm. Sorry for the silly mistake. I'm confused with another one.
> > 
> > FWIW, the cause is a rewording of "cannot" to "can not". This is the
> > right one.
> 
> Yes, that is the version I was going to apply.  I will do it today. 
> Thanks.

Patch applied to master, and the first paragraph diff was applied to PG
12-13 too.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee

Re: "cert" + clientcert=verify-ca in pg_hba.conf?

From

Kyotaro Horiguchi

Date:

06 October 2020, 05:31:03

At Mon, 5 Oct 2020 16:07:50 -0400, Bruce Momjian <bruce@momjian.us> wrote in 
> > Yes, that is the version I was going to apply.  I will do it today. 
> > Thanks.
> 
> Patch applied to master, and the first paragraph diff was applied to PG
> 12-13 too.

Thanks!

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center