[openssl-dev] [openssl.org #4174] Support the TLS Feature (aka Must Staple) X.509v3 extension (RFC7633)
https://github.com/openssl/openssl/pull/495 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4043] monitoring software depending onopenssl not working on cloudflare ssl websites
Hi Horatiu. To connect to a site that uses CloudFlare Universal SSL [1], you need to specify the SNI (Server Name Indication) header. Modern browsers do this by default, but for s_client you need to do this... openssl s_client -connect :443 -servername This isn't an OpenSSL bug, so I suggest closing this ticket. [1] https://blog.cloudflare.com/introducing-universal-ssl/ On 15/09/15 15:33, Horatiu N via RT wrote: > Greetings, > > Using the nagios plugins (latest debian package for 8.1) to check > availability of https websites using cloudflare gives errors >> CRITICAL - Cannot make SSL connection. >> 139729452828304:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 >> alert internal error:s23_clnt.c:770: > > same goes if i attempt to run >> openssl s_client -connect :443 > > This basically makes monitoring impossible at this time, > Any idea how to remedy this situation ? > > i attached a textfile with sample domains as extracted from the > certificate's "Certificate Subject alt name" > it's reproducible on any target as long as it's online > > openssl version >> OpenSSL 1.0.1k 8 Jan 2015 > > > dpkg -l openssl >> ii openssl 1.0.1k-3+deb8u1amd64 Secure >> Sockets Layer toolkit - cryptographic utility > > tried also to compile the newest one from openssl.org and use it, same > problem. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3665] Bug report and a patch forOpenSSL 1.0.1l (and 1.0.1k)
On 19/01/15 14:47, Stephen Henson via RT wrote: > On Mon Jan 19 14:40:32 2015, steve wrote: >> >> The problem is that the two fields containing the signature algorithm >> do not match. > > The current 'x509' utility can't show this difference (I have an option I'm > testing which will). Steve, while you're there... I've been caught out a few times in the past because the 'x509' utility displays the "outer" signature algorithm in the place where it should display the "inner" signature algorithm. This is fine when they match, but it's rather unhelpful when they don't match! Please consider this trivial patch. Thanks. diff --git a/crypto/asn1/t_x509.c b/crypto/asn1/t_x509.c index 89115c7..97abd51 100644 --- a/crypto/asn1/t_x509.c +++ b/crypto/asn1/t_x509.c @@ -168,7 +168,7 @@ int X509_print_ex(BIO *bp, X509 *x, unsigned long nmflags, unsigned long cflag) if(!(cflag & X509_FLAG_NO_SIGNAME)) { - if(X509_signature_print(bp, x->sig_alg, NULL) <= 0) + if(X509_signature_print(bp, ci->signature, NULL) <= 0) goto err; #if 0 if (BIO_printf(bp,"%8sSignature Algorithm: ","") <= 0) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl.org #3169] [PATCH] Additional "chain_cert" functions for 1.0.2-dev
This patch, which currently applies successfully against master and 1_0_2, adds the following functions: SSL_[CTX_]select_current_cert() - set the current certificate without disturbing the existing structure. SSL_[CTX_]get0_chain_certs() - get the current certificate's chain. SSL_[CTX_]clear_chain_certs() - clear the current certificate's chain. The patch also adds these functions to, and fixes some existing errors in, SSL_CTX_add1_chain_cert.pod. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online diff --git a/doc/ssl/SSL_CTX_add1_chain_cert.pod b/doc/ssl/SSL_CTX_add1_chain_cert.pod index 04f7526..2d2161a 100644 --- a/doc/ssl/SSL_CTX_add1_chain_cert.pod +++ b/doc/ssl/SSL_CTX_add1_chain_cert.pod @@ -3,9 +3,11 @@ =head1 NAME SSL_CTX_set0_chain, SSL_CTX_set1_chain, SSL_CTX_add0_chain_cert, -SSL_CTX_add1_chain_cert, SSL_set0_chain, SSL_set1_chain, -SSL_add0_chain_cert, SSL_add1_chain_cert, SSL_CTX_build_cert_chain, -SSL_build_cert_chain - extra chain certificate processing +SSL_CTX_add1_chain_cert, SSL_CTX_get0_chain_certs, SSL_CTX_clear_chain_certs, +SSL_set0_chain, SSL_set1_chain, SSL_add0_chain_cert, SSL_add1_chain_cert, +SSL_get0_chain_certs, SSL_clear_chain_certs, SSL_CTX_build_cert_chain, +SSL_build_cert_chain, SSL_CTX_select_current_cert, +SSL_select_current_cert - extra chain certificate processing =head1 SYNOPSIS @@ -13,36 +15,58 @@ SSL_build_cert_chain - extra chain certificate processing int SSL_CTX_set0_chain(SSL_CTX *ctx, STACK_OF(X509) *sk); int SSL_CTX_set1_chain(SSL_CTX *ctx, STACK_OF(X509) *sk); - int SSL_CTX_add0_chain_cert(SSL_CTX *ctx, STACK_OF(X509) *x509); + int SSL_CTX_add0_chain_cert(SSL_CTX *ctx, X509 *x509); int SSL_CTX_add1_chain_cert(SSL_CTX *ctx, X509 *x509); + int SSL_CTX_get0_chain_certs(SSL_CTX *ctx, STACK_OF(X509) **sk); + int SSL_CTX_clear_chain_certs(SSL_CTX *ctx); int SSL_set0_chain(SSL *ssl, STACK_OF(X509) *sk); int SSL_set1_chain(SSL *ssl, STACK_OF(X509) *sk); - int SSL_add0_chain_cert(SSL *ssl, STACK_OF(X509) *x509); + int SSL_add0_chain_cert(SSL *ssl, X509 *x509); int SSL_add1_chain_cert(SSL *ssl, X509 *x509); + int SSL_get0_chain_certs(SSL *ssl, STACK_OF(X509) **sk); + int SSL_clear_chain_certs(SSL *ssl); int SSL_CTX_build_cert_chain(SSL_CTX *ctx, flags); - int SSL_build_cert_chain(SSL_CTX *ctx, flags); + int SSL_build_cert_chain(SSL *ssl, flags); + + int SSL_CTX_select_current_cert(SSL_CTX *ctx, X509 *x509); + int SSL_select_current_cert(SSL *ssl, X509 *x509); =head1 DESCRIPTION SSL_CTX_set0_chain() and SSL_CTX_set1_chain() set the certificate chain -associated with the current certificate of B to B. If B is set -to B any existing chain is cleared. +associated with the current certificate of B to B. SSL_CTX_add0_chain_cert() and SSL_CTX_add1_chain_cert() append the single certificate B to the chain associated with the current certificate of B. +SSL_CTX_get0_chain_certs() retrieves the chain associated with the current +certificate of B. + +SSL_CTX_clear_chain_certs() clears any existing chain associated with the +current certificate of B. (This is implemented by calling +SSL_CTX_set0_chain() with B set to B). + SSL_CTX_build_cert_chain() builds the certificate chain for B using the chain store. Any existing chain certificates are used as untrusted CAs. If the function is successful the built chain will replace any existing chain. The B parameter can be set to B to omit the root CA from the built chain. -SSL_set0_chain(), SSL_set1_chain(), SSL_add0_chain_cert(), SSL_add0_chain_cert() -and SSL_build_cert_chain() are similar except they apply to SSL structure -B. +Each of these functions operates on the I end entity +(i.e. server or client) certificate. This is the last certificate loaded or +selected on the corresponding B structure. + +SSL_CTX_select_current_cert() selects B as the current end entity +certificate, but only if B has already been loaded into B using a +function such as SSL_CTX_use_certificate(). + +SSL_set0_chain(), SSL_set1_chain(), SSL_add0_chain_cert(), +SSL_add1_chain_cert(), SSL_get0_chain_certs(), SSL_clear_chain_certs(), +SSL_build_cert_chain() and SSL_select_current_cert() are similar except they +apply to SSL structure B. All these functions are implemented as macros. Those containing a B<1> increment the reference count of the supplied certificate or chain so it must @@ -56,10 +80,6 @@ The chains associate with an SSL_CTX structure are copied to any SSL structures when SSL_new() is called. SSL structures will not be affected by any chains subsequently changed in the parent SSL_CTX. -Each of these functions operates on the I end entity -(i.e. server or client) certificate. This is the last certificate set -on the corresponding B or B structure. - One chain can be set for each key type supported by a server. So, for example, an RSA and a DSA certificate can (and often will) have different chains. diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c i
[openssl.org #3068] [PATCH] Safari broken ECDHE-ECDSA workaround
The Safari browser on OSX versions 10.8 to 10.8.3 advertises support for several ECDHE-ECDSA ciphers but fails to negotiate them. When a Safari client connects to an OpenSSL-based server that has the attached patch (against the "master" branch) applied, the server will prefer other mutually supported ciphers above ECDHE-ECDSA ciphers. This patch enables a webserver to have an ECC certificate together with an RSA and/or DSA certificate, and to offer ECDHE-ECDSA ciphers without fear of breaking compatibility with Safari clients. The ssl_check_for_safari() function, which fingerprints Safari clients based on the TLS Extensions used, was written by Adam Langley. A representative from Apple has told me that the Safari bug will be fixed in OSX 10.8.4. However, since OSX users won't be forced to upgrade, I believe that a significant number of users will still be using affected Safari versions a few years from now. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c index 7ad8a54..fff73eb 100644 --- a/ssl/s3_lib.c +++ b/ssl/s3_lib.c @@ -3076,7 +3076,10 @@ void ssl3_clear(SSL *s) OPENSSL_free(s->s3->tlsext_authz_client_types); s->s3->tlsext_authz_client_types = NULL; } -#endif +#ifndef OPENSSL_NO_EC + s->s3->is_probably_safari = 0; +#endif /* OPENSSL_NO_EC */ +#endif /* OPENSSL_NO_TLSEXT */ rp = s->s3->rbuf.buf; wp = s->s3->wbuf.buf; @@ -4145,8 +4148,15 @@ SSL_CIPHER *ssl3_choose_cipher(SSL *s, STACK_OF(SSL_CIPHER) *clnt, ii=sk_SSL_CIPHER_find(allow,c); if (ii >= 0) { - ret=sk_SSL_CIPHER_value(allow,ii); - break; + if ((alg_k & SSL_kEECDH) && (alg_a & SSL_aECDSA) && s->s3->is_probably_safari) +{ +if (!ret) ret=sk_SSL_CIPHER_value(allow,ii); +} + else +{ +ret=sk_SSL_CIPHER_value(allow,ii); +break; +} } } return(ret); diff --git a/ssl/ssl.h b/ssl/ssl.h index e14a8d4..dd62578 100644 --- a/ssl/ssl.h +++ b/ssl/ssl.h @@ -568,6 +568,7 @@ struct ssl_session_st #define SSL_OP_SSLEAY_080_CLIENT_DH_BUG 0x0080L #define SSL_OP_TLS_D5_BUG0x0100L #define SSL_OP_TLS_BLOCK_PADDING_BUG 0x0200L +#define SSL_OP_SAFARI_ECDHE_ECDSA_BUG 0x0400L /* Disable SSL 3.0/TLS 1.0 CBC vulnerability workaround that was added * in OpenSSL 0.9.6d. Usually (depending on the application protocol) @@ -578,7 +579,7 @@ struct ssl_session_st /* SSL_OP_ALL: various bug workarounds that should be rather harmless. * This used to be 0x000FL before 0.9.7. */ -#define SSL_OP_ALL 0x8BFFL +#define SSL_OP_ALL 0x8FFFL /* DTLS options */ #define SSL_OP_NO_QUERY_MTU 0x1000L diff --git a/ssl/ssl3.h b/ssl/ssl3.h index d8ed725..0b900b5 100644 --- a/ssl/ssl3.h +++ b/ssl/ssl3.h @@ -577,7 +577,14 @@ typedef struct ssl3_state_st * server echoed our server_authz extension and therefore must send us * a supplemental data handshake message. */ char tlsext_authz_server_promised; -#endif + +#ifndef OPENSSL_NO_EC + /* This is set to true if we believe that this is a version of Safari + * running on OS X 10.6 .. 10.8. We wish to know this because Safari + * on 10.8 has broken ECDHE-ECDSA support. */ + char is_probably_safari; +#endif /* OPENSSL_NO_EC */ +#endif /* OPENSSL_NO_TLSEXT */ } SSL3_STATE; #endif diff --git a/ssl/t1_lib.c b/ssl/t1_lib.c index 31daa50..c5e2b85 100644 --- a/ssl/t1_lib.c +++ b/ssl/t1_lib.c @@ -1716,6 +1716,89 @@ unsigned char *ssl_add_serverhello_tlsext(SSL *s, unsigned char *p, unsigned cha return ret; } +#ifndef OPENSSL_NO_EC +/* ssl_check_for_safari attempts to fingerprint Safari using OS X + * SecureTransport using the TLS extension block in |d|, of length |n|. + * Safari, since 10.6, sends exactly these extensions, in this order: + * SNI, + * elliptic_curves + * ec_point_formats + * + * We wish to fingerprint Safari because they broke ECDHE-ECDSA support in 10.8, + * but they advertise support. So enabling ECDHE-ECDSA ciphers breaks them. + * Sadly we cannot differentiate 10.6 and 10.7 (which work), from 10.8 (which + * doesn't). + */ +static void ssl_check_for_safari(SSL *s, const unsigned char *data, const unsigned char *d, int n) { + unsigned short type, size; + static const unsigned char kSafariExtensionsBlock[] = { + 0x00, 0x0a, /* elliptic_curves extension */ + 0x00, 0x08, /* 8 bytes */ + 0x00, 0x06, /* 6 bytes of curve ids */ + 0x00, 0x17, /* P-256 */ + 0x00, 0x18, /* P-384 */ + 0x00, 0x19, /* P-521 */ + + 0x00, 0x0b, /* ec_point_formats */ + 0x00, 0x02, /* 2 bytes */ + 0x01,/* 1 point format */ + 0x00,/* uncompressed */ + }; + + /* The following is only present in TLS 1.2 */ + static const unsigned char kSafariTLS12ExtensionsBlock[] = { + 0x00, 0x0d, /* signature_algorithms */ + 0x00, 0x0c, /* 12 bytes */ + 0x00, 0x0a, /* 10 bytes */ + 0x05, 0x01, /* SHA-384/RSA */ + 0x04, 0x01, /* SHA-256/RSA */ + 0x02, 0x01, /* SHA-1/
Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured
On 21/09/12 15:38, Rob Stradling via RT wrote: > On 21/09/12 15:12, Rob Stradling via RT wrote: >> On 21/09/12 15:04, Stephen Henson via RT wrote: > >>> Easiest solution is to also backport ssl_get_server_send_pkey see: >>> >>> http://cvs.openssl.org/chngview?cn=22840 >> >> I didn't think of that. Thanks! >> >> I'll prepare patches to backport 22840 to 1.0.0 and 0.9.8 (unless you or >> Ben get there first). > > http://cvs.openssl.org/patchset?cn=22840 applies cleanly (i.e. no failed > hunks) on top of my patches for 1.0.0 and 0.9.8. Steve, Ben committed my patch to the 1.0.0 branch yesterday: http://cvs.openssl.org/chngview?cn=22875 So, please would you now apply http://cvs.openssl.org/patchset?cn=22840 to the 1.0.0 branch? Thanks. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured
On 21/09/12 15:12, Rob Stradling via RT wrote: > On 21/09/12 15:04, Stephen Henson via RT wrote: >> Easiest solution is to also backport ssl_get_server_send_pkey see: >> >> http://cvs.openssl.org/chngview?cn=22840 > > I didn't think of that. Thanks! > > I'll prepare patches to backport 22840 to 1.0.0 and 0.9.8 (unless you or > Ben get there first). http://cvs.openssl.org/patchset?cn=22840 applies cleanly (i.e. no failed hunks) on top of my patches for 1.0.0 and 0.9.8. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured
On 21/09/12 15:04, Stephen Henson via RT wrote: >> [rob.stradl...@comodo.com - Fri Sep 21 15:55:39 2012]: >> >> Hi Steve. >> >> I saw your update (to 1.0.2 and HEAD), and I did start looking at >> backporting it into my 1.0.1/1.0.0/0.9.8 patches. >> >> ssl_get_server_send_pkey() is not available in 1.0.1 and earlier, so the >> t1_lib.c patch would have to be something like... >> >> +X509 *x; >> +x = ssl_get_server_send_cert)s); >> +/* If no certificate can't return certificate status */ >> +if (x == NULL) >> +{ >> +s->tlsext_status_expected = 0; >> +return 1; >> +} >> +/* Set current certificate to one we will use so >> + * SSL_get_certificate et al can pick it up. >> + */ >> +s->cert->key->x509 = x; >> >> Is it OK to update s->cert->key->x509 like this? >> > > No because you could end up with all sorts of bad things happening (keys > and certificates not matching, certificate types not matching and memory > leaks). That's what I thought. > Easiest solution is to also backport ssl_get_server_send_pkey see: > > http://cvs.openssl.org/chngview?cn=22840 I didn't think of that. Thanks! I'll prepare patches to backport 22840 to 1.0.0 and 0.9.8 (unless you or Ben get there first). -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured
Hi Steve. I saw your update (to 1.0.2 and HEAD), and I did start looking at backporting it into my 1.0.1/1.0.0/0.9.8 patches. ssl_get_server_send_pkey() is not available in 1.0.1 and earlier, so the t1_lib.c patch would have to be something like... + X509 *x; + x = ssl_get_server_send_cert)s); + /* If no certificate can't return certificate status */ + if (x == NULL) + { + s->tlsext_status_expected = 0; + return 1; + } + /* Set current certificate to one we will use so +* SSL_get_certificate et al can pick it up. +*/ + s->cert->key->x509 = x; Is it OK to update s->cert->key->x509 like this? On 21/09/12 14:34, Stephen Henson via RT wrote: >> [rob.stradl...@comodo.com - Fri Sep 21 15:02:54 2012]: >> >> Attached are patches for 1.0.0 and 0.9.8. >> >> > > Note, I updated the original change to retain compatibility with > existing behaviour as far as possible. See: > > http://cvs.openssl.org/chngview?cn=22808 > > Steve. > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured
Attached are patches for 1.0.0 and 0.9.8. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. Index: ssl/s3_srvr.c === RCS file: /v/openssl/cvs/openssl/ssl/s3_srvr.c,v retrieving revision 1.126.2.42 diff -u -r1.126.2.42 s3_srvr.c --- ssl/s3_srvr.c 16 Feb 2012 15:21:17 - 1.126.2.42 +++ ssl/s3_srvr.c 20 Sep 2012 14:40:41 - @@ -1005,7 +1005,7 @@ goto f_err; } } - if (ssl_check_clienthello_tlsext(s) <= 0) { + if (ssl_check_clienthello_tlsext_early(s) <= 0) { SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_CLIENTHELLO_TLSEXT); goto err; } @@ -1131,6 +1131,16 @@ * s->tmp.new_cipher- the new cipher to use. */ + /* Handles TLS extensions that we couldn't check earlier */ + if (s->version >= SSL3_VERSION) + { + if (ssl_check_clienthello_tlsext_late(s) <= 0) + { + SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_CLIENTHELLO_TLSEXT); + goto err; + } + } + if (ret < 0) ret=1; if (0) { Index: ssl/ssl_lib.c === RCS file: /v/openssl/cvs/openssl/ssl/ssl_lib.c,v retrieving revision 1.133.2.31 diff -u -r1.133.2.31 ssl_lib.c --- ssl/ssl_lib.c 5 Jan 2012 10:21:49 - 1.133.2.31 +++ ssl/ssl_lib.c 20 Sep 2012 14:40:41 - @@ -1943,7 +1943,7 @@ } /* THIS NEEDS CLEANING UP */ -X509 *ssl_get_server_send_cert(SSL *s) +X509 *ssl_get_server_send_cert(const SSL *s) { unsigned long alg,kalg; CERT *c; @@ -2420,7 +2420,9 @@ /* Fix this function so that it takes an optional type parameter */ X509 *SSL_get_certificate(const SSL *s) { - if (s->cert != NULL) + if (s->server) + return(ssl_get_server_send_cert(s)); + else if (s->cert != NULL) return(s->cert->key->x509); else return(NULL); Index: ssl/ssl_locl.h === RCS file: /v/openssl/cvs/openssl/ssl/ssl_locl.h,v retrieving revision 1.63.2.22 diff -u -r1.63.2.22 ssl_locl.h --- ssl/ssl_locl.h 9 Mar 2012 15:51:56 - 1.63.2.22 +++ ssl/ssl_locl.h 20 Sep 2012 14:40:41 - @@ -740,7 +740,7 @@ int ssl_undefined_function(SSL *s); int ssl_undefined_void_function(void); int ssl_undefined_const_function(const SSL *s); -X509 *ssl_get_server_send_cert(SSL *); +X509 *ssl_get_server_send_cert(const SSL *); EVP_PKEY *ssl_get_sign_pkey(SSL *,SSL_CIPHER *); int ssl_cert_type(X509 *x,EVP_PKEY *pkey); void ssl_set_cert_masks(CERT *c, SSL_CIPHER *cipher); @@ -979,7 +979,8 @@ int ssl_parse_serverhello_tlsext(SSL *s, unsigned char **data, unsigned char *d, int n, int *al); int ssl_prepare_clienthello_tlsext(SSL *s); int ssl_prepare_serverhello_tlsext(SSL *s); -int ssl_check_clienthello_tlsext(SSL *s); +int ssl_check_clienthello_tlsext_early(SSL *s); +int ssl_check_clienthello_tlsext_late(SSL *s); int ssl_check_serverhello_tlsext(SSL *s); #ifdef OPENSSL_NO_SHA256 Index: ssl/t1_lib.c === RCS file: /v/openssl/cvs/openssl/ssl/t1_lib.c,v retrieving revision 1.13.2.30 diff -u -r1.13.2.30 t1_lib.c --- ssl/t1_lib.c4 Jan 2012 14:25:10 - 1.13.2.30 +++ ssl/t1_lib.c20 Sep 2012 14:40:41 - @@ -745,7 +745,7 @@ return 1; } -int ssl_check_clienthello_tlsext(SSL *s) +int ssl_check_clienthello_tlsext_early(SSL *s) { int ret=SSL_TLSEXT_ERR_NOACK; int al = SSL_AD_UNRECOGNIZED_NAME; @@ -755,11 +755,34 @@ else if (s->initial_ctx != NULL && s->initial_ctx->tlsext_servername_callback != 0) ret = s->initial_ctx->tlsext_servername_callback(s, &al, s->initial_ctx->tlsext_servername_arg); + switch (ret) + { +
Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured
On 07/09/12 11:51, Rob Stradling wrote: > Attached is an updated patch for CVS HEAD, plus a patch for the 1.0.2 > branch. > > Are you still accepting patches for 1.0.1? Attached is a patch for 1.0.1. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Index: ssl/s3_srvr.c === RCS file: /v/openssl/cvs/openssl/ssl/s3_srvr.c,v retrieving revision 1.171.2.21.2.26 diff -u -r1.171.2.21.2.26 s3_srvr.c --- ssl/s3_srvr.c 8 Jun 2012 09:18:46 - 1.171.2.21.2.26 +++ ssl/s3_srvr.c 12 Sep 2012 15:45:12 - @@ -1183,7 +1183,7 @@ goto f_err; } } - if (ssl_check_clienthello_tlsext(s) <= 0) { + if (ssl_check_clienthello_tlsext_early(s) <= 0) { SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_CLIENTHELLO_TLSEXT); goto err; } @@ -1405,6 +1405,16 @@ * s->tmp.new_cipher- the new cipher to use. */ + /* Handles TLS extensions that we couldn't check earlier */ + if (s->version >= SSL3_VERSION) + { + if (ssl_check_clienthello_tlsext_late(s) <= 0) + { + SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_CLIENTHELLO_TLSEXT); + goto err; + } + } + if (ret < 0) ret=1; if (0) { Index: ssl/ssl_lib.c === RCS file: /v/openssl/cvs/openssl/ssl/ssl_lib.c,v retrieving revision 1.176.2.19.2.25 diff -u -r1.176.2.19.2.25 ssl_lib.c --- ssl/ssl_lib.c 8 Jun 2012 09:18:46 - 1.176.2.19.2.25 +++ ssl/ssl_lib.c 12 Sep 2012 15:45:12 - @@ -2287,7 +2287,7 @@ #endif /* THIS NEEDS CLEANING UP */ -X509 *ssl_get_server_send_cert(SSL *s) +X509 *ssl_get_server_send_cert(const SSL *s) { unsigned long alg_k,alg_a; CERT *c; @@ -2780,7 +2780,9 @@ /* Fix this function so that it takes an optional type parameter */ X509 *SSL_get_certificate(const SSL *s) { - if (s->cert != NULL) + if (s->server) + return(ssl_get_server_send_cert(s)); + else if (s->cert != NULL) return(s->cert->key->x509); else return(NULL); Index: ssl/ssl_locl.h === RCS file: /v/openssl/cvs/openssl/ssl/ssl_locl.h,v retrieving revision 1.100.2.10.2.17 diff -u -r1.100.2.10.2.17 ssl_locl.h --- ssl/ssl_locl.h 9 Mar 2012 15:52:20 - 1.100.2.10.2.17 +++ ssl/ssl_locl.h 12 Sep 2012 15:45:12 - @@ -830,7 +830,7 @@ int ssl_undefined_function(SSL *s); int ssl_undefined_void_function(void); int ssl_undefined_const_function(const SSL *s); -X509 *ssl_get_server_send_cert(SSL *); +X509 *ssl_get_server_send_cert(const SSL *); EVP_PKEY *ssl_get_sign_pkey(SSL *s,const SSL_CIPHER *c, const EVP_MD **pmd); int ssl_cert_type(X509 *x,EVP_PKEY *pkey); void ssl_set_cert_masks(CERT *c, const SSL_CIPHER *cipher); @@ -1088,7 +1088,8 @@ int ssl_parse_serverhello_tlsext(SSL *s, unsigned char **data, unsigned char *d, int n, int *al); int ssl_prepare_clienthello_tlsext(SSL *s); int ssl_prepare_serverhello_tlsext(SSL *s); -int ssl_check_clienthello_tlsext(SSL *s); +int ssl_check_clienthello_tlsext_early(SSL *s); +int ssl_check_clienthello_tlsext_late(SSL *s); int ssl_check_serverhello_tlsext(SSL *s); #ifndef OPENSSL_NO_HEARTBEATS Index: ssl/t1_lib.c === RCS file: /v/openssl/cvs/openssl/ssl/t1_lib.c,v retrieving revision 1.64.2.14.2.33 diff -u -r1.64.2.14.2.33 t1_lib.c --- ssl/t1_lib.c27 Jun 2012 14:11:40 - 1.64.2.14.2.33 +++ ssl/t1_lib.c12 Sep 2012 15:45:12 - @@ -1763,7 +1763,7 @@ return 1; } -int ssl_check_clienthello_tlsext(SSL *s) +int ssl_check_clienthello_tlsext_early(SSL *s) { int ret=SSL_TLSEXT_ERR_NOACK; int al = SSL_AD_UNRECOGNIZED_NAME; @@ -1782,42 +1782,12 @@ else if (s->initial_ctx != NULL && s->initial_ctx->tlsext_servername_callback != 0) ret = s->initial_ctx->tlsext_servername_callback(s, &al, s->initial_ctx->tlsext_servername_arg); - /* If status request then ask callback what to do. -* Note: this must be called after servername callbacks in case -* the certificate has changed. -*/ - if ((s->tlsext_status_type != -1) && s->ctx && s->ctx->tlsext_status_cb) - { - int r; - r = s->ctx->tlsext_status_cb(s, s->ctx->tlsext_status_arg); - switch (r) - { - /* We don't want to send a status request response */ - case SSL_TLSEXT_ERR_NOACK: -
Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured
Attached is an updated patch for CVS HEAD, plus a patch for the 1.0.2 branch. Are you still accepting patches for 1.0.1? Any chance of reviewing these patches soon? Thanks. On 19/06/12 21:15, Rob Stradling via RT wrote: > The OCSP Stapling Callback function (s->ctx->tlsext_status_cb) is called > during the parsing of the ClientHello message, before the server has > decided which cipher to use. However, since the choice of cipher can > influence which server certificate is sent, this means that the wrong > OCSP Response may be sent in cases where multiple server certificates > are configured. > > The attached patch against CVS HEAD makes the following changes: > - Moves the s->ctx->tlsext_status_cb() call to just after the cipher > has been chosen. This involves splitting ssl_check_clienthello_tlsext() > into two functions: "early" and "late". > - Updates SSL_get_certificate() so that it returns the server > certificate that actually gets sent. (This is the function that Apache > httpd's OCSP Stapling code calls in order to determine which OCSP > Response to send). > > I've tested this patch successfully with an installation of httpd 2.4.2 > that has both an RSA cert and an ECC cert configured. > > If this patch is OK, I'd like to backport it to the OpenSSL 1.0.x branch > as well. > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Index: ssl/s3_srvr.c === RCS file: /v/openssl/cvs/openssl/ssl/s3_srvr.c,v retrieving revision 1.239 diff -u -r1.239 s3_srvr.c --- ssl/s3_srvr.c 15 Aug 2012 15:15:05 - 1.239 +++ ssl/s3_srvr.c 7 Sep 2012 10:00:12 - @@ -1432,6 +1432,16 @@ * s->tmp.new_cipher- the new cipher to use. */ + /* Handles TLS extensions that we couldn't check earlier */ + if (s->version >= SSL3_VERSION) + { + if (ssl_check_clienthello_tlsext_late(s) <= 0) + { + SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_CLIENTHELLO_TLSEXT); + goto err; + } + } + if (ret < 0) ret=1; if (0) { Index: ssl/ssl_lib.c === RCS file: /v/openssl/cvs/openssl/ssl/ssl_lib.c,v retrieving revision 1.242 diff -u -r1.242 ssl_lib.c --- ssl/ssl_lib.c 31 Aug 2012 11:18:54 - 1.242 +++ ssl/ssl_lib.c 7 Sep 2012 10:00:12 - @@ -2336,7 +2336,7 @@ #endif -static int ssl_get_server_cert_index(SSL *s) +static int ssl_get_server_cert_index(const SSL *s) { int idx; idx = ssl_cipher_get_cert_index(s->s3->tmp.new_cipher); @@ -2347,7 +2347,7 @@ return idx; } -CERT_PKEY *ssl_get_server_send_pkey(SSL *s) +CERT_PKEY *ssl_get_server_send_pkey(const SSL *s) { CERT *c; int i; @@ -2833,6 +2833,14 @@ /* Fix this function so that it takes an optional type parameter */ X509 *SSL_get_certificate(const SSL *s) { + if (s->server) + { + CERT_PKEY *certpkey; + certpkey = ssl_get_server_send_pkey(s); + if (certpkey && certpkey->x509) + return certpkey->x509; + } + if (s->cert != NULL) return(s->cert->key->x509); else Index: ssl/ssl_locl.h === RCS file: /v/openssl/cvs/openssl/ssl/ssl_locl.h,v retrieving revision 1.155 diff -u -r1.155 ssl_locl.h --- ssl/ssl_locl.h 31 Aug 2012 11:18:54 - 1.155 +++ ssl/ssl_locl.h 7 Sep 2012 10:00:12 - @@ -934,7 +934,7 @@ int ssl_undefined_function(SSL *s); int ssl_undefined_void_function(void); int ssl_undefined_const_function(const SSL *s); -CERT_PKEY *ssl_get_server_send_pkey(SSL *); +CERT_PKEY *ssl_get_server_send_pkey(const SSL *s); unsigned char *ssl_get_authz_data(SSL *s, size_t *authz_length); EVP_PKEY *ssl_get_sign_pkey(SSL *s,const SSL_CIPHER *c, const EVP_MD **pmd); int ssl_cert_type(X509 *x,EVP_PKEY *pkey); @@ -1201,6 +1201,7 @@ unsigned char *ssl_add_clienthello_tlsext(SSL *s, unsigned char *p, unsigned char *limit); unsigned char *ssl_add_serverhello_tlsext(SSL *s, unsigned char *p, unsigned char *limit); int ssl_parse_clienthello_tlsext(SSL *s, unsigned char **data, unsigned char *d, int n); +int ssl_check_clienthello_tlsext_late(SSL *s); int ssl_parse_serverhello_tlsext(SSL *s, unsigned char **data, unsigned char *d, int n); int ssl_prepare_clienthello_tlsext(SSL *s); int ssl_prepare_serverhello_tlsext(SSL *s); Index: ssl/t1_lib.c === RCS file: /v/openssl/cvs/o
[openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured
The OCSP Stapling Callback function (s->ctx->tlsext_status_cb) is called during the parsing of the ClientHello message, before the server has decided which cipher to use. However, since the choice of cipher can influence which server certificate is sent, this means that the wrong OCSP Response may be sent in cases where multiple server certificates are configured. The attached patch against CVS HEAD makes the following changes: - Moves the s->ctx->tlsext_status_cb() call to just after the cipher has been chosen. This involves splitting ssl_check_clienthello_tlsext() into two functions: "early" and "late". - Updates SSL_get_certificate() so that it returns the server certificate that actually gets sent. (This is the function that Apache httpd's OCSP Stapling code calls in order to determine which OCSP Response to send). I've tested this patch successfully with an installation of httpd 2.4.2 that has both an RSA cert and an ECC cert configured. If this patch is OK, I'd like to backport it to the OpenSSL 1.0.x branch as well. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Index: ssl/s3_srvr.c === RCS file: /v/openssl/cvs/openssl/ssl/s3_srvr.c,v retrieving revision 1.233 diff -u -r1.233 s3_srvr.c --- ssl/s3_srvr.c 6 Jun 2012 12:52:19 - 1.233 +++ ssl/s3_srvr.c 19 Jun 2012 10:59:34 - @@ -1424,6 +1424,16 @@ * s->tmp.new_cipher- the new cipher to use. */ + /* Handles TLS extensions that we couldn't check earlier */ + if (s->version >= SSL3_VERSION) + { + if (!ssl_check_clienthello_tlsext_late(s)) + { + SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_PARSE_TLSEXT); + goto err; + } + } + if (ret < 0) ret=1; if (0) { Index: ssl/ssl_lib.c === RCS file: /v/openssl/cvs/openssl/ssl/ssl_lib.c,v retrieving revision 1.234 diff -u -r1.234 ssl_lib.c --- ssl/ssl_lib.c 18 Jun 2012 12:56:59 - 1.234 +++ ssl/ssl_lib.c 19 Jun 2012 10:59:34 - @@ -2846,6 +2846,14 @@ /* Fix this function so that it takes an optional type parameter */ X509 *SSL_get_certificate(const SSL *s) { + if (s->server) + { + CERT_PKEY *certpkey; + certpkey = ssl_get_server_send_pkey((SSL *)s); + if (certpkey && certpkey->x509) + return certpkey->x509; + } + if (s->cert != NULL) return(s->cert->key->x509); else Index: ssl/ssl_locl.h === RCS file: /v/openssl/cvs/openssl/ssl/ssl_locl.h,v retrieving revision 1.141 diff -u -r1.141 ssl_locl.h --- ssl/ssl_locl.h 18 Jun 2012 12:56:59 - 1.141 +++ ssl/ssl_locl.h 19 Jun 2012 10:59:34 - @@ -1132,6 +1132,7 @@ unsigned char *ssl_add_clienthello_tlsext(SSL *s, unsigned char *p, unsigned char *limit); unsigned char *ssl_add_serverhello_tlsext(SSL *s, unsigned char *p, unsigned char *limit); int ssl_parse_clienthello_tlsext(SSL *s, unsigned char **data, unsigned char *d, int n); +int ssl_check_clienthello_tlsext_late(SSL *s); int ssl_parse_serverhello_tlsext(SSL *s, unsigned char **data, unsigned char *d, int n); int ssl_prepare_clienthello_tlsext(SSL *s); int ssl_prepare_serverhello_tlsext(SSL *s); Index: ssl/t1_lib.c === RCS file: /v/openssl/cvs/openssl/ssl/t1_lib.c,v retrieving revision 1.123 diff -u -r1.123 t1_lib.c --- ssl/t1_lib.c11 Jun 2012 09:23:55 - 1.123 +++ ssl/t1_lib.c19 Jun 2012 10:59:34 - @@ -123,7 +123,7 @@ static int tls_decrypt_ticket(SSL *s, const unsigned char *tick, int ticklen, const unsigned char *sess_id, int sesslen, SSL_SESSION **psess); -static int ssl_check_clienthello_tlsext(SSL *s); +static int ssl_check_clienthello_tlsext_early(SSL *s); int ssl_check_serverhello_tlsext(SSL *s); #endif @@ -1846,7 +1846,7 @@ return 0; } - if (ssl_check_clienthello_tlsext(s) <= 0) + if (ssl_check_clienthello_tlsext_early(s) <= 0) { SSLerr(SSL_F_SSL_PARSE_CLIENTHELLO_TLSEXT,SSL_R_CLIENTHELLO_TLSEXT); return 0; @@ -2247,7 +2247,7 @@ return 1; } -static int ssl_check_clienthello_tlsext(SSL *s) +static int ssl_check_clienthello_tlsext_early(SSL *s) { int ret=SSL_TLSEXT_ERR_NOACK; int al = SSL_AD_UNRECOGNIZED_NAME; @@ -2266,42 +2266,11 @@ else if (s->initial_ctx != NULL && s->initial_ctx->tlsext_servername_callback != 0) ret =
[openssl.org #2354] [PATCH] Increase Default RSA Key Size to 2048-bits
NIST (SP800-57 Part 1) recommends a minimum RSA key size of 2048-bits beyond 2010. From January 1st 2011, in order to comply with the current Microsoft[1] and Mozilla[2] CA Policies, Commercial CAs will no longer be permitted to issue certificates with RSA key sizes of <2048-bit. Please accept the attached patch, which increases the default RSA key size to 2048-bits for the "req", "genrsa" and "genpkey" apps. Thanks. [1] http://technet.microsoft.com/en-us/library/cc751157.aspx says: "we have advised Certificate Authorities...to transition their subordinate and end-certificates to 2048-bit RSA certificates, and to complete this transition for any root certificate distributed by the Program no later than December 31, 2010". [2] https://wiki.mozilla.org/CA:MD5and1024 says: "December 31, 2010 – CAs should stop issuing intermediate and end-entity certificates from roots with RSA key sizes smaller than 2048 bits. All CAs should stop issuing intermediate and end-entity certificates with RSA key size smaller than 2048 bits under any root". Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. Index: apps/genrsa.c === RCS file: /v/openssl/cvs/openssl/apps/genrsa.c,v retrieving revision 1.40 diff -U 5 -r1.40 genrsa.c --- apps/genrsa.c 1 Mar 2010 14:22:21 - 1.40 +++ apps/genrsa.c 28 Sep 2010 14:44:44 - @@ -76,11 +76,11 @@ #include #include #include #include -#define DEFBITS 512 +#define DEFBITS 2048 #undef PROG #define PROG genrsa_main static int MS_CALLBACK genrsa_cb(int p, int n, BN_GENCB *cb); Index: apps/openssl-vms.cnf === RCS file: /v/openssl/cvs/openssl/apps/openssl-vms.cnf,v retrieving revision 1.11 diff -U 5 -r1.11 openssl-vms.cnf --- apps/openssl-vms.cnf 23 Apr 2009 16:32:37 - 1.11 +++ apps/openssl-vms.cnf 28 Sep 2010 14:44:44 - @@ -101,11 +101,11 @@ commonName = supplied emailAddress = optional [ req ] -default_bits = 1024 +default_bits = 2048 default_keyfile = privkey.pem distinguished_name = req_distinguished_name attributes = req_attributes x509_extensions = v3_ca # The extentions to add to the self signed cert Index: apps/openssl.cnf === RCS file: /v/openssl/cvs/openssl/apps/openssl.cnf,v retrieving revision 1.32 diff -U 5 -r1.32 openssl.cnf --- apps/openssl.cnf 4 Apr 2009 19:54:02 - 1.32 +++ apps/openssl.cnf 28 Sep 2010 14:44:44 - @@ -101,11 +101,11 @@ commonName = supplied emailAddress = optional [ req ] -default_bits = 1024 +default_bits = 2048 default_keyfile = privkey.pem distinguished_name = req_distinguished_name attributes = req_attributes x509_extensions = v3_ca # The extentions to add to the self signed cert Index: apps/req.c === RCS file: /v/openssl/cvs/openssl/apps/req.c,v retrieving revision 1.146 diff -U 5 -r1.146 req.c --- apps/req.c 14 Mar 2010 12:54:45 - 1.146 +++ apps/req.c 28 Sep 2010 14:44:44 - @@ -97,11 +97,11 @@ #define V3_EXTENSIONS "x509_extensions" #define REQ_EXTENSIONS "req_extensions" #define STRING_MASK "string_mask" #define UTF8_IN "utf8" -#define DEFAULT_KEY_LENGTH 512 +#define DEFAULT_KEY_LENGTH 2048 #define MIN_KEY_LENGTH 384 #undef PROG #define PROG req_main Index: crypto/rsa/rsa_pmeth.c === RCS file: /v/openssl/cvs/openssl/crypto/rsa/rsa_pmeth.c,v retrieving revision 1.39 diff -U 5 -r1.39 rsa_pmeth.c --- crypto/rsa/rsa_pmeth.c 1 Jun 2010 14:39:01 - 1.39 +++ crypto/rsa/rsa_pmeth.c 28 Sep 2010 14:44:44 - @@ -91,11 +91,11 @@ { RSA_PKEY_CTX *rctx; rctx = OPENSSL_malloc(sizeof(RSA_PKEY_CTX)); if (!rctx) return 0; - rctx->nbits = 1024; + rctx->nbits = 2048; rctx->pub_exp = NULL; rctx->pad_mode = RSA_PKCS1_PADDING; rctx->md = NULL; rctx->mgf1md = NULL; rctx->tbuf = NULL; Index: doc/apps/
[openssl.org #2206] [PATCH] Implicitly support non-delegated OCSP response signing
The attached patches (generated against OpenSSL 0.9.8n and OpenSSL-1.0.0- beta5) cause "openssl ocsp" to implicitly trust the Issuing CA Certificate (as denoted by the "-issuer" parameter) as a candidate OCSP Response signer. This "non-delegated" model is allowed by RFC 2560. With this patch, it's possible to do an OCSP check like this: $ ~/local/openssl-0.9.8n-modified/bin/openssl ocsp -issuer ComodoEVSGCCA.crt - cert secure.comodo.com.crt -no_nonce -url http://ocsp.comodoca.com Response verify OK secure.comodo.com.crt: good This Update: Mar 25 19:03:00 2010 GMT Next Update: Mar 29 19:03:00 2010 GMT But without this patch, you have to also specify "-VAfile ComodoEVSGCCA.crt" to achieve the same result. Here are an example End-entity Certificate and Issuing CA Certificate whose OCSP Responder uses the "non-delegated" model. secure.comodo.com.crt: -BEGIN CERTIFICATE- MIIGUjCCBTqgAwIBAgIRAJQkYZmHGtbUyY0tko7rIB4wDQYJKoZIhvcNAQEFBQAw czELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxGTAXBgNV BAMTEENPTU9ETyBFViBTR0MgQ0EwHhcNMDkwMTA4MDAwMDAwWhcNMTEwNDA3MjM1 OTU5WjCCAX8xETAPBgNVBAUTCDA0MDU4NjkwMRMwEQYLKwYBBAGCNzwCAQMTAkdC MSMwIQYLKwYBBAGCNzwCAQITEkdyZWF0ZXIgTWFuY2hlc3RlcjEbMBkGCysGAQQB gjc8AgEBEwpNYW5jaGVzdGVyMRswGQYDVQQPExJWMS4wLCBDbGF1c2UgNS4oYikx CzAJBgNVBAYTAkdCMQ8wDQYDVQQREwZNNSAzRVExGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEWMBQGA1UECRMNVHJhZmZvcmQg Um9hZDEWMBQGA1UECRMNRXhjaGFuZ2UgUXVheTElMCMGA1UECRMcM3JkIEZsb29y LCAyNiBPZmZpY2UgVmlsbGFnZTEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx GjAYBgNVBAsTEUNvbW9kbyBFViBTR0MgU1NMMRowGAYDVQQDExFzZWN1cmUuY29t b2RvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMWgPqeYQTL9 IdKWF/FxZ/y32XyGgU3gi2n6cd4ewDlSPkadoaYCeR8nTQBsssuFHaYA2T15+Iky TZ/O63fFB5ZjWCaN6Ryjsk5PWDTYiYRieswQOREEvWr9N3Rpn9/l7vOd9L3Kngbz QGTDzPxjba1Kz+5jx436y3s/0830c8bd002qPbSwvnrqdfSA2x6pHfY6mKvJI7Bj p1FfYHk3Tt6P03j5l4rLu51dxf0u5J66sxQBJBjTWrc3YJzuRZ5BYs6GzKeUv0lz X1RzkAUA0gq2PFUarCEVSd392rD9gXfVS+VEnssqpyjlScsbPD9EIopW+sXylHb4 CJx+kh/wFskCAwEAAaOCAdEwggHNMB8GA1UdIwQYMBaAFH/2TDYoFK7NHjev3lry W8OgrCv+MB0GA1UdDgQWBBR3BpKJiE8F31jgH6F+yyU9mwXksDAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADA0BgNVHSUELTArBggrBgEFBQcDAQYIKwYBBQUH AwIGCisGAQQBgjcKAwMGCWCGSAGG+EIEATARBglghkgBhvhCAQEEBAMCBsAwRgYD VR0gBD8wPTA7BgwrBgEEAbIxAQIBBQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9z ZWN1cmUuY29tb2RvLm5ldC9DUFMwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vQ29tb2RvRVZTR0NDQS5jcmwwawYIKwYBBQUHAQEEXzBd MDUGCCsGAQUFBzAChilodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9Db21vZG9FVlNH Q0NBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMDMG A1UdEQQsMCqCEXNlY3VyZS5jb21vZG8uY29tghV3d3cuc2VjdXJlLmNvbW9kby5j b20wDQYJKoZIhvcNAQEFBQADggEBAH/IFXTOFOEuxm38/yN1ssElb4hRS349eK8o 72Sn1HDdmvDnZaEDjZsHAH7Dtm6N6Wd67rkt2fLczTi+BJWX2qttw4ttwsnRJoIV Rucu+QrqgX4Duce+smo3qXbTTWgrUNgHVmuOpyWtafIcKJ/CqPz3rkp+u8NSlXKj /dvm/3P8i4RcRsE63+pR/o0sFrGzQaC6UdQtCUFcQXFQzrkWUAsxwnN3V7wXq+YH h2OEDNsojuogH6zBkcknmd5cpoFu4BANx4lbbWDUr+rqJmXvZWa4jlsiI+k8wRhz m83TXZpbVZI7VpZT7hnQyEeNxeu7jv9ygME84X6UPJp3004m2nw= -END CERTIFICATE- ComodoEVSGCCA.crt: -BEGIN CERTIFICATE- MIIEljCCA36gAwIBAgIQE2Lo61QaEIy4qA7ln7HUUTANBgkqhkiG9w0BAQUFADCB gTELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxJzAlBgNV BAMTHkNPTU9ETyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNjEyMDEwMDAw MDBaFw0xOTEyMzEyMzU5NTlaMHMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMRkwFwYDVQQDExBDT01PRE8gRVYgU0dDIENBMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6M6qqSWvLo7ReZVepIgkT/2zXK4qnkp7 QODMUOmBWBXSh/ethXppUqCVbo9nCY7x81wX40lCyBJnpgX4N6APFmEPjzFSxuGH 4U+528n+aRvUyfctrEjXc0oEleOhN4dSWoiz1gEs8QNwLCZwK0c7Cq4xetflFE6s LzDhfG022qD1g2JdiCYNBUVezveL65W04OsQetS5WXVGUt2GdITLX9McQerwmtqR ZITf3p/y3dD6pmiWtz6XLX+x+4xsp/5ygtDjitO7484Bt51n6akTmjsh7fdzE+Mz XXoBqcpJ0E5jh1eBOhdUMPYCXpS2YNIp+U7nKaCgnSpb6z+JLkWi/QIDAQABo4IB FTCCAREwHwYDVR0jBBgwFoAUC1jli8ZMFTekQKkwqSG+RzZaVv8wHQYDVR0OBBYE FH/2TDYoFK7NHjev3lryW8OgrCv+MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8E CDAGAQH/AgEAMCAGA1UdJQQZMBcGCisGAQQBgjcKAwMGCWCGSAGG+EIEATA+BgNV HSAENzA1MDMGBFUdIAAwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29t b2RvLm5ldC9DUFMwSQYDVR0fBEIwQDA+oDygOoY4aHR0cDovL2NybC5jb21vZG9j YS5jb20vQ09NT0RPQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwDQYJKoZIhvcN AQEFBQADggEBAIzZ2VIz7gf24eyrFeCfFdiZJdsZlSWbQ75ZK4EpyPjxX45JAjZG HOvyof7RCkW60NtQRAxQozxuX4TUTxqoaY8kZgHSC7QIGbq9NAmQCWJxrTmOuHh5 sSR4tM2nSflteH9wh4KRNayxAIYhUdLNRss6gsBIGtMVJtvxD4JxZuKLd1Sjdi/X bfgNDs46TmVXPxx3UMq7elP3+189dVaq0+MfErUdv8Pc4fk5Z4HxM5zIHsXm7iu5 2VjIxy7fSNHJ5LMaCF+aGG1h07CtJ14INTQloZ9CyHWY0wJkVZTjr9HnSrnk2QZu cSj43azlRd/Y5ygFoWjOwSVbhfpGnf7bZPA= -END CERTIFICATE- On Wednesday 24 March 2010 12:38:07 you wrote: > On Wednesday 24 March 2010 12:01:51 you wrote: > > > > > > Well it would typically require giving a public responder access to a > > > > CA