Re: doubt regarding certificate generation
Thanks Dave could you please elaborate below lines too $(OPENSSL) req -newkey rsa:1024 -sha1 -keyout rootkey.pem -out rootreq.pem -config root.cnf $(OPENSSL) x509 -req -in rootreq.pem -sha1 -extfile root.cnf -extensions certificate_extensions -signkey rootkey.pem -out rootcert.pem $(CAT) rootcert.pem rootkey.pem root.pem $(OPENSSL) req -newkey rsa:1024 -sha1 -keyout serverCAkey.pem -out serverCAreq.pem -config serverCA.cnf $(OPENSSL) x509 -req -in serverCAreq.pem -sha1 -extfile serverCA.cnf -extensions certificate_extensions -CA root.pem -CAkey root.pem -CAcreateserial -out serverCAcert.pem $(CAT) serverCAcert.pem serverCAkey.pem rootcert.pem serverCA.pem -Thanks mithun On Wed, Apr 11, 2012 at 1:45 AM, Dave Thompson dthomp...@prinpay.comwrote: From: owner-openssl-us...@openssl.org On Behalf Of Mithun Kumar Sent: Monday, 09 April, 2012 01:54 I am newbie to OpenSSL. I am trying to understand how certificates are generated. I downloaded the samples and started understanding the Makefile that came with the sources. FYI- this is *a* way of generating matching keys and certificates, which is what you need, in OpenSSL. There are other methods. Below is my understanding so far $(OPENSSL) req -newkey rsa:1024 -sha1 -keyout serverkey.pem -out serverreq.pem -config server.cnf -reqexts req_extensions Here we are trying to create a RSA private key with Private Key file serverkey.pem and output file serverreq.pem This creates an RSA key*pair* (private and public) which is stored in CRT format in serverkey.pem, *and* a certficate signing request aka CSR for the publickey half of that keypair in serverreq.pem. Although theoretical RSA public and private keys can be distinct with only (e,n) and (d,n), much better performance is obtained by the CRT implementation which stores e,d,n,p,q plus more. The publickey (e,n) is extracted from CRT format when needed. (CRT here means Chinese Remainder Theorem.) $(OPENSSL) x509 -req -in serverreq.pem -sha1 -extfile server.cnf -extensions certificate_extensions -CA serverCA.pem -CAkey serverCA.pem -CAcreateserial -out servercert.pem Here we are creating a ServerCertificate which has the private key from serverreq.pem , signed by CA serverCA.pem using CA private key serverCA.pem The cert has the *public*key from the CSR, plus other information. It is signed by the CA's privatekey in serverCA.pem and is linked under the CA's certificate (matching that CA privatekey) also in serverCA.pem. (In many but not all cases, OpenSSL allows multiple things to be stored in one .pem file. Other programs may not.) $(CAT) servercert.pem serverkey.pem serverCAcert.pem rootcert.pem server.pem Not shure why we are doing here. Assuming serverCAcert.pem contains the same cert as serverCA.pem (but *not* the privatekey apparently also in serverCA.pem) and rootcert.pem contains the root cert over serverCAcert.pem, this puts the server's keypair, the cert for the server's key, the CA cert over the server's cert (called an intermediate or chain cert), and the root cert all in one file. Some servers (can) use a single file like that to define together the (server) key and cert with its chain they use for SSL/TLS handshake. Some clients do the same if you use client auth, but that is rarer. Technically the server doesn't need the root cert in this file. Any root supplied by the server to the client during handshaking is ignored; the client must use only a root configured locally. But if you want a record of what root the server cert chain uses, putting it in the file is a convenient and reliable way. Can some one explain me clearly above 3 commands. Also during Server Authentication , Server sends its certificate to the client which has the Public Key of the server. Here where is the Public Key generated? As above; the publickey in the server cert came from the CSR, which came from the server keypair generated and stored in the first step. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl/crypto cleanup
On a disconnect check the state of the SSL data structure and call
SSL_free if it is not null.
if (*sslptr != NULL) {
SSL_free (*sslptr);
*sslptr = NULL;
}
Though as you say it is a certificate issue, then perhaps you need to
look at
SSL_CTX_free(*sslctxptr)
Look at the man page for this. Perhaps you are reusing an SSL context
structure. We don't need to call this in our disconnect code, but
testing code may reuse a structure that running code doesn't.
If these don't work for you, then maybe you should look at putting in
some diagnostic printfs to look for where the dirty data is being kept,
you might be reusing something like a DH or X509 structure and you may
need to call a free or cleanup function for that particular structure.
I don't know about the callback function, but I like your guess.
Good Luck,
Jeremy
Nou Dadoun wrote:
Hi, I’ve looked at the archives and didn’t see any apropos discussions
so I thought I’d go straight to the list:
We use the openssl crypto libraries in several places in our product
both in fips and non-fips modes.
We have a set of unit tests to exercise various portions of our code
to ensure that our implementations using these tools work the way that
they’re supposed to.
I’ve run into an unusual problem, we have a set of crypto
(encrypt/decrypt) tests and a separate set of certificate tests (e.g.
retrieve a certificate and its CA and do a certificate verification).
If I run the certificate tests first and then the crypto tests, all
the tests pass and everything works great.
If I run the crypto tests first and then the certificate test, the
verification fails due to a “signature” failure. This implies to me
that the crypto tests are leaving something in the openssl/crypto
machinery in a funky state which breaks the subsequent certificate
signature computation.
A couple of questions:
What can I do to completely clean the openssl/crypto state to ensure
that this doesn’t happen? I’ve added:
CRYPTO_cleanup_all_ex_data();
ENGINE_cleanup();
But this appears to be inadequate (I suspect necessary but
insufficient), any suggestions?
(I’ve reordered the tests so that they’re passing now but I’d like to
avoid this hack if I can.)
Second question, I added a verification callback routine, e.g.
staticint verify_callback(int ok, X509_STORE_CTX *stor)
{
if(!ok)
{
printf(verify_callback Certificate Verification Error: %s\n,
X509_verify_cert_error_string(stor-error));
}
else
{
printf(verify_callback Certificate Verification Success\n);
}
return ok;
}
I’ve put a breakpoint in it and noticed that when verifying a
certificate, this callback is called twice,
In the successful order above (cert then crypto tests) both calls have
ok == 1,
In the unsuccessful order (crypto then cert), the first call is 1 and
the second is 0 with a “signature error” reported.
Why is it called twice and what’s the difference? (I suspect the
second is signature checking and the first is everything else but I’m
curious).
Thanks in advance … N
---
Nou Dadoun
ndadoun@teradici.com_
_604-628-1215
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: expired ssl certificate
Hi Nou Please help me understand more about this subject ( I am new to Openssl) 1. What happen if the peer presents an expired certificate and we do not implement callback using SSL_CTX_set_verify with SSL_VERIFY_PEER flag set, will the SSL_connect or SSL_accept fail ??? 2. What is the function of verification callback ? Just report error of expired certificate or actually let expired certificate be accepted ?? what is X509_.. function shoud I uses to let expired cert being accept ?? 3. what is the different between standard verify operation and the verify callback ??? Thank You Thao Dinh -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Nou Dadoun Sent: Tuesday, April 10, 2012 3:15 PM To: openssl-users@openssl.org Subject: RE: expired ssl certificate You can use a verification callback to look at the certificate after the standard verify operation has been performed to decide whether or not to allow the certificate anyway. Look at the O'Reilly book (http://doc.hackbbs.org/Reseaux/O_Reilly_-_Network_Security_with_OpenSSL.pdf ) page 132 or so has some sample code you can probably modify. Standard warnings apply .. N --- Nou Dadoun ndad...@teradici.com 604-628-1215 From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Srihari, Gautam Sent: April 10, 2012 3:04 AM To: openssl-...@openssl.org; openssl-users@openssl.org Subject: expired ssl certificate Hi, I have a server application and the client uses https to connect to the server. For this I had created an openssl self signed certificate cacert.pem which has been distributed to all the client applications. Now unfortunately the certificate has expired. I can create a new certificate. But distributing to all the clients is going to be difficult. Is there some way by using open ssl, I can make the server ignore expired certificates so I don't have to ask each client to update to a new certificate? The crux of the problem is that I want to continue to allow clients to use the server without Having them to upgrade anything i.e change should be done only on the server side. Reg., Gautam smime.p7s Description: S/MIME cryptographic signature
Re: Accept failing - SysCall error - advice?
Thanks, Dave, for your reply. Very helpful. If this server is getting connections from the client above, and that client mistakenly handles WANT_READ by closing or even exiting/aborting, the server gets either TCP abort or unexpected TCP shutdown (aka EOF), which causes this error. Errno didn't return much. But this sounds reasonable. Playing with the blocking settings on the fd seems to help. Assume that it could be similar for the SSL_ACCEPT? (though WANT_WRITE, perhaps?) Interestingly, in a situation where two apps open a number of SSL connections between each other (over time) I get a deadlock - where a client blocks on the SSL_Connect, and the server on the general (socketIO) accept. Any hints? You are but invisibly; SSL_set_fd() creates a socket-BIO internally. That's fine You can actually use socket-BIO, and/or accept-BIO and connect-BIO, to do plain TCP connections directly, To clarify, that's what I'm dong now, right? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: expired ssl certificate
I'm no ssl guru either but I'll make some brief comments and let others jump in
if I'm too far off the mark.
1. If you use the standard verify and the peer presents an expired
certificate, the certificate will not be verified and the connection will fail.
2. The verification callback is called after the regular verification is
performed, here's a simple example I posted with my own question yesterday:
static int verify_callback(int ok, X509_STORE_CTX *stor)
{
if(!ok)
{
printf(verify_callback Certificate Verification Error: %s\n,
X509_verify_cert_error_string(stor-error));
}
else
{
printf(verify_callback Certificate Verification Success\n);
}
return ok;
}
The ok parameter tells you whether the certificate passed so that if it's not
ok (didn't pass) you can examine the reason/error and the certificate itself to
see whether or not you want to over-rule that result. The return value
indicates whether you want to accept it or not - the above example only reports
the result (without changing it) and (if it fails) the reason for failure
without changing anything. If it's not ok and you look at the cert and it's
expired but you don't care, return 1 and it will be accepted. Look at the
examples in the pdf for some examples.
As I said earlier, standard warnings apply - you're overruling standard
security mechanisms for your own purposes which can be dangerous if you're not
careful.
3. I think I've answered that above N
---
Nou Dadoun
ndad...@teradici.com
604-628-1215
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Dinh, Thao V CIV NSWCDD, K72
Sent: April 11, 2012 4:19 AM
To: openssl-users@openssl.org
Subject: RE: expired ssl certificate
Hi Nou
Please help me understand more about this subject ( I am new to Openssl)
1. What happen if the peer presents an expired certificate and we do not
implement callback using SSL_CTX_set_verify with SSL_VERIFY_PEER flag set, will
the SSL_connect or SSL_accept fail ???
2. What is the function of verification callback ? Just report error of
expired certificate or actually let expired certificate be accepted ?? what is
X509_.. function shoud I uses to let expired cert being accept ??
3. what is the different between standard verify operation and the verify
callback ???
Thank You
Thao Dinh
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Nou Dadoun
Sent: Tuesday, April 10, 2012 3:15 PM
To: openssl-users@openssl.org
Subject: RE: expired ssl certificate
You can use a verification callback to look at the certificate after the
standard verify operation has been performed to decide whether or not to allow
the certificate anyway.
Look at the O'Reilly book
(http://doc.hackbbs.org/Reseaux/O_Reilly_-_Network_Security_with_OpenSSL.pdf )
page 132 or so has some sample code you can probably modify.
Standard warnings apply .. N
---
Nou Dadoun
ndad...@teradici.com
604-628-1215
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Srihari, Gautam
Sent: April 10, 2012 3:04 AM
To: openssl-...@openssl.org; openssl-users@openssl.org
Subject: expired ssl certificate
Hi,
I have a server application and the client uses https to connect
to the server. For this I had created an openssl self signed certificate
cacert.pem which has been distributed to all the client applications.
Now unfortunately the certificate has expired. I can create a new
certificate.
But distributing to all the clients is going to be difficult.
Is there some way by using open ssl, I can make the server ignore expired
certificates
so I don't have to ask each client to update to a new certificate?
The crux of the problem is that I want to continue to allow clients to use the
server without
Having them to upgrade anything i.e change should be done only on the server
side.
Reg.,
Gautam
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: openssl/crypto cleanup
Thanks for the note, seems like it's even more fundamental than that because
the unit test not only doesn't establish an ssl connection, it doesn't even use
an ssl context! As a certificate unit test, it's *only* testing our various
certificate deployment scenarios to make sure that we retrieve the right CA
certificate and do a verification correctly (we also do a test encrypt/decrypt
on the keys to make sure they're usable).
The spoiler crypto tests don't use an ssl context either (they're really just
using test encrypt/decrypts for the various algorithm deployments scenarios) so
it's still a little mysterious why the two would interfere with each other! It
would seem to be right down in the crypto algorithm code because that seems to
be all that they have in common. That's why a total scrub cleanup function
would be useful ... N
---
Nou Dadoun
ndad...@teradici.com
604-628-1215
-Original Message-
From: jeremy hunt [mailto:jere...@optimation.com.au]
Sent: April 10, 2012 6:11 PM
To: openssl-users@openssl.org
Cc: Nou Dadoun
Subject: Re: openssl/crypto cleanup
On a disconnect check the state of the SSL data structure and call
SSL_free if it is not null.
if (*sslptr != NULL) {
SSL_free (*sslptr);
*sslptr = NULL;
}
Though as you say it is a certificate issue, then perhaps you need to
look at
SSL_CTX_free(*sslctxptr)
Look at the man page for this. Perhaps you are reusing an SSL context
structure. We don't need to call this in our disconnect code, but
testing code may reuse a structure that running code doesn't.
If these don't work for you, then maybe you should look at putting in
some diagnostic printfs to look for where the dirty data is being kept,
you might be reusing something like a DH or X509 structure and you may
need to call a free or cleanup function for that particular structure.
I don't know about the callback function, but I like your guess.
Good Luck,
Jeremy
Nou Dadoun wrote:
Hi, I've looked at the archives and didn't see any apropos discussions
so I thought I'd go straight to the list:
We use the openssl crypto libraries in several places in our product
both in fips and non-fips modes.
We have a set of unit tests to exercise various portions of our code
to ensure that our implementations using these tools work the way that
they're supposed to.
I've run into an unusual problem, we have a set of crypto
(encrypt/decrypt) tests and a separate set of certificate tests (e.g.
retrieve a certificate and its CA and do a certificate verification).
If I run the certificate tests first and then the crypto tests, all
the tests pass and everything works great.
If I run the crypto tests first and then the certificate test, the
verification fails due to a signature failure. This implies to me
that the crypto tests are leaving something in the openssl/crypto
machinery in a funky state which breaks the subsequent certificate
signature computation.
A couple of questions:
What can I do to completely clean the openssl/crypto state to ensure
that this doesn't happen? I've added:
CRYPTO_cleanup_all_ex_data();
ENGINE_cleanup();
But this appears to be inadequate (I suspect necessary but
insufficient), any suggestions?
(I've reordered the tests so that they're passing now but I'd like to
avoid this hack if I can.)
Second question, I added a verification callback routine, e.g.
staticint verify_callback(int ok, X509_STORE_CTX *stor)
{
if(!ok)
{
printf(verify_callback Certificate Verification Error: %s\n,
X509_verify_cert_error_string(stor-error));
}
else
{
printf(verify_callback Certificate Verification Success\n);
}
return ok;
}
I've put a breakpoint in it and noticed that when verifying a
certificate, this callback is called twice,
In the successful order above (cert then crypto tests) both calls have
ok == 1,
In the unsuccessful order (crypto then cert), the first call is 1 and
the second is 0 with a signature error reported.
Why is it called twice and what's the difference? (I suspect the
second is signature checking and the first is everything else but I'm
curious).
Thanks in advance ... N
---
Nou Dadoun
ndadoun@teradici.com_
_604-628-1215
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: expired ssl certificate
Reading Nou's proposal, I have the impression that the client needs to be
modified to accept expired server's certificate. Is my understanding
correct? If my understanding is corrrect, the client needs to be updated.
If the client needs to be updated, In my opinion, it is simpler to update
the client with a new server certificate.
However, you should not use a selfsigned certificate for your serve
certificate. Instead, I am proposing to create a chain of certificate
(PKI). You could avoid this problem in the future by creating a simple
PKI. FUrther you could expand this PKI to issue certificate for other
application.
This is what I am proposing:
1. Create a long lived self-signed CA certificate (for example: 20 or 30
years); This self-signed certificate is called trust anchor certificate.
Make sure, basic constraint CA is set to true.
Do not make the expiration less than 5 years, since you will have the
same issue again in the next 5 year to roll-over your trust anchor
certificate. Also, keep the private key of this CA as safe as possible.
THis is your root of trust. If you compromise this root CA private key,
your PKI becomes void.
2. Distribute this self-signed certificate to all clients and install this
as the trusted certificate.
3. Have this self-signed CA (trust anchor) created in step-1 issues the
server certificate. For this server certificate, validity period does not
matter. Of course you do not want to make the validity period too short
since you have to frequently update the server certificate when it is
expired.
Using this proposed method, you can update or change the server certificate
as often as you like.
The server certificate is typically included in the SSL's ServerHello
message, so the client always got the server certificate during SSL
handshake. I think (?) the server could also include the chain of
certificate up to the trust anchor certificate.
When the client receives the server certificate issued by the self-signed
CA (the self-signed CA certificate could also be included in the
ServerHello), the client can verify this certificate chain up to the
self-signed CA certificate. If the chain can be verified, then the server
certificate is successfully validated. Hence, the server can be
cryptographically authenticated.
Using Nou's proposal, your client would practically accept any self-signed
certificate and prone to man-in-the-middle attack. The client can
cryptographically verify the server certificate, but the client can not
cryptographically authenticate the server since the client does not have
the knowledge of the server's legitimate public key. Using my proposal,
your client can cryptographically authenticate the server, by verifying the
digital signature in the server's certificate using the (selfsigned) CA
certificate. The selfsigned CA certificate is then verified against a list
of trusted certificates. My proposal is actually similar with what you are
doing currently. The difference between my proposal and yours is: in yours,
you verify the server certificate against a list of trusted certificates.
In my proposal, you verify the server certificate using the CA certificate
which is in a list of trusted certificates.
Erwin
On Wed, Apr 11, 2012 at 11:34 AM, Nou Dadoun ndad...@teradici.com wrote:
I'm no ssl guru either but I'll make some brief comments and let others
jump in if I'm too far off the mark.
1. If you use the standard verify and the peer presents an expired
certificate, the certificate will not be verified and the connection will
fail.
2. The verification callback is called after the regular verification
is performed, here's a simple example I posted with my own question
yesterday:
static int verify_callback(int ok, X509_STORE_CTX *stor)
{
if(!ok)
{
printf(verify_callback Certificate Verification Error: %s\n,
X509_verify_cert_error_string(stor-error));
}
else
{
printf(verify_callback Certificate Verification Success\n);
}
return ok;
}
The ok parameter tells you whether the certificate passed so that if it's
not ok (didn't pass) you can examine the reason/error and the certificate
itself to see whether or not you want to over-rule that result. The return
value indicates whether you want to accept it or not - the above example
only reports the result (without changing it) and (if it fails) the reason
for failure without changing anything. If it's not ok and you look at the
cert and it's expired but you don't care, return 1 and it will be accepted.
Look at the examples in the pdf for some examples.
As I said earlier, standard warnings apply - you're overruling standard
security mechanisms for your own purposes which can be dangerous if you're
not careful.
3. I think I've answered that above N
---
Nou Dadoun
ndad...@teradici.com
604-628-1215
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:
owner-openssl-us...@openssl.org] On
Re: expired ssl certificate
Hi,
I had almost the same requirement and eventually achieved it by patching my
openssl package's x509_verify code to do the check_cert_time() method
optionally depending on some conditions. Ideally I feel openSSL should
provide a validation flag like
*X509_V_FLAG_IGNORE_LIFETIME **which would help in this case. I can see
many existing flags listed here.** *
http://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set_flags.html#VERIFICATION_FLAGS
Is there any specific reason as to why OpenSSL does not want to support
this feature?
Regds,
Ashok
On Thu, Apr 12, 2012 at 12:26 AM, Erwin Himawan ehima...@gmail.com wrote:
Reading Nou's proposal, I have the impression that the client needs to be
modified to accept expired server's certificate. Is my understanding
correct? If my understanding is corrrect, the client needs to be updated.
If the client needs to be updated, In my opinion, it is simpler to update
the client with a new server certificate.
However, you should not use a selfsigned certificate for your serve
certificate. Instead, I am proposing to create a chain of certificate
(PKI). You could avoid this problem in the future by creating a simple
PKI. FUrther you could expand this PKI to issue certificate for other
application.
This is what I am proposing:
1. Create a long lived self-signed CA certificate (for example: 20 or 30
years); This self-signed certificate is called trust anchor certificate.
Make sure, basic constraint CA is set to true.
Do not make the expiration less than 5 years, since you will have the
same issue again in the next 5 year to roll-over your trust anchor
certificate. Also, keep the private key of this CA as safe as possible.
THis is your root of trust. If you compromise this root CA private key,
your PKI becomes void.
2. Distribute this self-signed certificate to all clients and install this
as the trusted certificate.
3. Have this self-signed CA (trust anchor) created in step-1 issues the
server certificate. For this server certificate, validity period does not
matter. Of course you do not want to make the validity period too short
since you have to frequently update the server certificate when it is
expired.
Using this proposed method, you can update or change the server
certificate as often as you like.
The server certificate is typically included in the SSL's ServerHello
message, so the client always got the server certificate during SSL
handshake. I think (?) the server could also include the chain of
certificate up to the trust anchor certificate.
When the client receives the server certificate issued by the self-signed
CA (the self-signed CA certificate could also be included in the
ServerHello), the client can verify this certificate chain up to the
self-signed CA certificate. If the chain can be verified, then the server
certificate is successfully validated. Hence, the server can be
cryptographically authenticated.
Using Nou's proposal, your client would practically accept any self-signed
certificate and prone to man-in-the-middle attack. The client can
cryptographically verify the server certificate, but the client can not
cryptographically authenticate the server since the client does not have
the knowledge of the server's legitimate public key. Using my proposal,
your client can cryptographically authenticate the server, by verifying the
digital signature in the server's certificate using the (selfsigned) CA
certificate. The selfsigned CA certificate is then verified against a list
of trusted certificates. My proposal is actually similar with what you are
doing currently. The difference between my proposal and yours is: in yours,
you verify the server certificate against a list of trusted certificates.
In my proposal, you verify the server certificate using the CA certificate
which is in a list of trusted certificates.
Erwin
On Wed, Apr 11, 2012 at 11:34 AM, Nou Dadoun ndad...@teradici.com wrote:
I'm no ssl guru either but I'll make some brief comments and let others
jump in if I'm too far off the mark.
1. If you use the standard verify and the peer presents an expired
certificate, the certificate will not be verified and the connection will
fail.
2. The verification callback is called after the regular verification
is performed, here's a simple example I posted with my own question
yesterday:
static int verify_callback(int ok, X509_STORE_CTX *stor)
{
if(!ok)
{
printf(verify_callback Certificate Verification Error: %s\n,
X509_verify_cert_error_string(stor-error));
}
else
{
printf(verify_callback Certificate Verification Success\n);
}
return ok;
}
The ok parameter tells you whether the certificate passed so that if it's
not ok (didn't pass) you can examine the reason/error and the certificate
itself to see whether or not you want to over-rule that result. The return
value indicates whether you want to accept it or
