Re: [openssl.org #1790] [Patch] Windows CE 5 and following support
Hi, ext Roumen Petrov wrote: Some notes about patch: First, thank you for having a look at it. - INSTALL.WCE "perl by MSYS" what is this ? If this is perl build from mingw32 project ? I can't found perl issue in mingw32 bug tracker. Since the issue is not confirmed you can't write that a package don't work. Sorry, I meant the one from the mingw32 project. I use msysgit in my environment, thus I mixed up with the names. In any case, if I use that perl version, then nmake is not capable of parsing the generated makefiles. I can send a diff of both versions to this thread or create another request, if you prefer that. - apps/ocsp.c why extra include of ? this mean that e_os.h patch is incomplete. I was tempted to add the include in e_os.h, but as this is the only file requiring this header I felt it to be much cleaner. If the general consensus is that e_os should be responsible for header inclusion ignoring that other files will use it for no purpose, I can change the patch accordingly. - ms/do_ms.bat please keep changes minimal There seemed to be a line-ending mixup or sth. It basically just adds "enable-experimental-jpake" to the WinCE makefile generator. - util/pl/VC-32.pl please don't remove flags that affect warnings. WX->Wall ? As stated in the mail, I needed to disable WX to have at least a successful compilation. WX treats warnings as errors and thus it will fail on two instances, where my knowledge about OpenSSL insides is limited. As already mentioned, I can send both compile warnings(errors) to this list and somebody can have a look at them. why is linked with crypt32 ? The additional dependency results from using Cert* functions inside of engines/e_capi.c. Best Regards, Maurice Kalinowski -- Maurice Kalinowski - maurice.kalinowski (AT) nokia.com Software Engineer - Nokia, Qt Software Rudower Chaussee 13, 12489 Berlin, Germany __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1791] BUG: openssl 0.9.8i creates a notAfter time in the past for dates after 2049
If I attempt to create a certificate with an expiry time after 2049 (so that openssl will use a GeneralizedTime rather than a UTCTime for the notAfter field), openssl actually generates a date in the past. This can be seen with the following: openssl req -new -key -config -x509 -set_serial 1 -days 2 | openssl x509 -noout -dates Which produces the following output on STDOUT: notBefore=Nov 24 14:52:00 2008 GMT notAfter=Jul 23 08:24:00 1927 GMT Please excuse me if this is a known issue. A quick Google search did not turn anything up. Kind regards, Christopher Williams, Software engineer, McAfee Inc. McAfee International Limited is registered in England and Wales with its registered address at 100 New Bridge Street, London, Company No. 02825890 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: verify certificate - not from a file
On November 23, 2008 10:57:55 pm ThanhTrung Do wrote: > > From: Itay Dagan <[EMAIL PROTECTED]> > > Subject: verify certificate - not from a file > > To: openssl-dev@openssl.org > > Date: Monday, November 24, 2008, 12:37 AM > > Hi Guys > > > > I am new in openssl - so hopfully I am not bringing up an > > old issue : > > > > I am trying to verify a certificate that I am saving as > > string in a random place on my PC memory. > > > > I know that there is the > > "SSL_CTX_load_verify_locations()" that verify > > certificate from a file or a path. > > > > My Q is : > > Does openssl supports taking certificate not from a file or > > path but from a place in the memory ? > > meaning - A function that gets a char* - reads the > > certificate from that location and verifying it. > > > > > > appreciate your help :) > > I have the same need too, highly appreciate your helps. > Something like the following should work if the certificate is in PEM format. (note: this is example only - the below code is probably full of errors, because I just zen'd it from memory). I'm sure that Steve or one of the other guru's will correct any problems :) char certbuf = "PEM-ENCODED-CERTIFICATE"; BIO *bufbio = BIO_new(BIO_s_mem()); int len = BIO_puts(bufbio , certbuf); X509 *cert = X509_new(); PEM_read_bio_X509(bufbio, &cert, NULL, NULL); If the Cert is already in DER format, just use the d2i_X509() function to read it into the OpenSSL internal representation. Have fun. -- Patrick Patterson President and Chief PKI Architect, Carillon Information Security Inc. http://www.carillon.ca __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
FIPS v1.2 test failures on FreeBSD 7
When running the tx509 test (with no args), it ends up generating a SIGILL. GDB says the instruction is 'ud2a' which I believe is the guaranteed illegal opcode on ia32. Not sure why it's being generated though. This occurs on both FreeBSD 7 x86 and x64. FreeBSD 5 and 6 do not exhibit this behavior. All are being run within VMWare Server v1.0.x, but that's never been an issue before. Just for testing purposes, I also tried using the 'no-asm', 'no-sse2', and '386' flags, and edited Configure to use '-O0 -g' instead of '-O3' and it also generates the same thing. Here's what GDB says: Starting program: /usr/home/build/openssl-fips-1.2/apps/openssl x509 -in fff.p -inform p -outform d [New LWP 100100] [New Thread 0x28401100 (LWP 100100)] Program received signal SIGILL, Illegal instruction. [Switching to Thread 0x28401100 (LWP 100100)] 0x0815b5e0 in PEM_read_bio_X509_AUX (bp=0x284051c0, x=0x0, cb=0x80c2a60 , u=0x0) (gdb) bt #0 0x0815b5e0 in PEM_read_bio_X509_AUX (bp=0x284051c0, x=0x0, cb=0x80c2a60 , u=0x0) #1 0x080c3843 in load_cert (err=0x28405040, file=0xbfbfedc3 "fff.p", format=3, pass=0x0, e=0x0, cert_descrip=0x81d3290 "Certificate") at apps.c:821 #2 0x080af73e in x509_main (argc=0, argv=0xbfbfecc0) at x509.c:632 #3 0x0809082b in do_cmd (prog=0x28406200, argc=7, argv=0xbfbfeca4) at openssl.c:396 #4 0x080904b8 in main (Argc=7, Argv=0xbfbfeca4) at openssl.c:315 (gdb) disas Dump of assembler code for function PEM_read_bio_X509_AUX: 0x0815b5e0 : ud2a End of assembler dump. $ gcc --version gcc (GCC) 4.2.1 20070719 [FreeBSD] Any ideas? GCC issue perhaps? Thanks. -Brad __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: FIPS v1.2 test failures on FreeBSD 7
I might have jumped the gun here. I'm getting that failure on OpenSSL 0.9.8e (no fips), which I think was the branch point for the FIPS v1.2, but not OpenSSL 0.9.8f (no fips). So something must have been fixed between those 2 releases for FreeBSD7. I'm going to go ahead and build the FIPS release, then try to use the 20081123 snapshot and link the fips canister to that and see if the tests pass. -Brad Brad House wrote: > When running the tx509 test (with no args), it ends up generating > a SIGILL. GDB says the instruction is 'ud2a' which I believe is the > guaranteed illegal opcode on ia32. Not sure why it's being generated > though. This occurs on both FreeBSD 7 x86 and x64. FreeBSD 5 and 6 > do not exhibit this behavior. All are being run within VMWare Server > v1.0.x, but that's never been an issue before. > > Just for testing purposes, I also tried using the 'no-asm', 'no-sse2', > and '386' flags, and edited Configure to use '-O0 -g' instead of '-O3' > and it also generates the same thing. > > Here's what GDB says: > > Starting program: /usr/home/build/openssl-fips-1.2/apps/openssl x509 -in > fff.p -inform p -outform d > [New LWP 100100] > [New Thread 0x28401100 (LWP 100100)] > > Program received signal SIGILL, Illegal instruction. > [Switching to Thread 0x28401100 (LWP 100100)] > 0x0815b5e0 in PEM_read_bio_X509_AUX (bp=0x284051c0, x=0x0, cb=0x80c2a60 > , u=0x0) > (gdb) bt > #0 0x0815b5e0 in PEM_read_bio_X509_AUX (bp=0x284051c0, x=0x0, cb=0x80c2a60 > , u=0x0) > #1 0x080c3843 in load_cert (err=0x28405040, file=0xbfbfedc3 "fff.p", > format=3, pass=0x0, e=0x0, cert_descrip=0x81d3290 "Certificate") at apps.c:821 > #2 0x080af73e in x509_main (argc=0, argv=0xbfbfecc0) at x509.c:632 > #3 0x0809082b in do_cmd (prog=0x28406200, argc=7, argv=0xbfbfeca4) at > openssl.c:396 > #4 0x080904b8 in main (Argc=7, Argv=0xbfbfeca4) at openssl.c:315 > (gdb) disas > Dump of assembler code for function PEM_read_bio_X509_AUX: > 0x0815b5e0 : ud2a > End of assembler dump. > > $ gcc --version > gcc (GCC) 4.2.1 20070719 [FreeBSD] > > Any ideas? GCC issue perhaps? > > Thanks. > -Brad > > > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager [EMAIL PROTECTED] > __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Heimdal compatibility of the kerberos support
On 2008/11/23 23:07, Evgeny Sinelnikov wrote:
../libssl.so: undefined reference to `krb5_principal_set_type
Thank you for the warning.
I'm consulting MIT krb5 sources, but not actually testing compilation
against MIT kerberos installed. Thus I haven't realized when I've got
somehow myself under a delusion that krb5_principal_set_type is common
to MIT and Heimdal, just as krb5_principal_compare is -- which is not
the case.
The attached patch is corrected with respect to this (but still does not
solve the krb5_ticket differences).
With best regards
Honza Macháček
diff -Naur openssl-0.9.8i/include/openssl/kssl.h
openssl-0.9.8i-heimdal/include/openssl/kssl.h
--- include/openssl/kssl.h 2005-04-09 23:55:55.0 +
+++ include/openssl/kssl.h 2008-11-22 16:27:24.0 +
@@ -81,6 +81,7 @@
*/
#ifdef KRB5_HEIMDAL
typedef unsigned char krb5_octet;
+typedef krb5_times krb5_ticket_times;
#define FAR
#else
diff -Naur openssl-0.9.8i/ssl/kssl.c openssl-0.9.8i-heimdal/ssl/kssl.c
--- ssl/kssl.c 2008-04-02 11:15:05.0 +
+++ ssl/kssl.c 2008-11-24 16:05:07.0 +
@@ -821,16 +821,27 @@
{
switch (enctype)
{
- case ENCTYPE_DES_HMAC_SHA1: /*EVP_des_cbc(); */
- case ENCTYPE_DES_CBC_CRC:
+ case ENCTYPE_DES_CBC_CRC: /*EVP_des_cbc(); */
case ENCTYPE_DES_CBC_MD4:
case ENCTYPE_DES_CBC_MD5:
+#ifdef KRB5_HEIMDAL
+ case ENCTYPE_DES_CBC_NONE:
+ case ENCTYPE_DES_CFB64_NONE:
+ case ENCTYPE_DES_PCBC_NONE:
+#else
+ case ENCTYPE_DES_HMAC_SHA1:
case ENCTYPE_DES_CBC_RAW:
+#endif
return EVP_des_cbc();
break;
case ENCTYPE_DES3_CBC_SHA1: /*EVP_des_ede3_cbc(); */
+#ifdef KRB5_HEIMDAL
+ case ENCTYPE_DES3_CBC_MD5:
+ case ENCTYPE_DES3_CBC_NONE:
+#else
case ENCTYPE_DES3_CBC_SHA:
case ENCTYPE_DES3_CBC_RAW:
+#endif
return EVP_des_ede3_cbc();
break;
default:return NULL;
@@ -883,6 +894,7 @@
{
int i, j, n;
static size_t *cklens = NULL;
+ size_t cksumsize;
#ifdef KRB5_MIT_OLD11
n = krb5_max_cksum;
@@ -894,13 +906,14 @@
if (!cklens && !(cklens = (size_t *) calloc(sizeof(int),n+1))) return
NULL;
for (i=0; i < n; i++) {
- if (!valid_cksumtype(i)) continue; /* array has holes */
+ if (!krb5_c_valid_cksumtype(i)) continue; /* array has
holes */
+ if (krb5_c_checksum_length(NULL, i, &cksumsize)) continue;
/* there's something wrong */
for (j=0; j < n; j++) {
if (cklens[j] == 0) {
- cklens[j] = krb5_checksum_size(NULL,i);
+ cklens[j] = cksumsize;
break; /* krb5 elem was new: add */
}
- if (cklens[j] == krb5_checksum_size(NULL,i)) {
+ if (cklens[j] == cksumsize) {
break; /* ignore duplicate elements */
}
}
@@ -957,14 +970,21 @@
print_krb5_data(char *label, krb5_data *kdata)
{
int i;
+ unsigned char *datastring;
+
+#ifdef KRB5_HEIMDAL
+ memcpy(datastring, kdata->data, kdata->length);
+#else
+ datastring = kdata->data;
+#endif
printf("%s[%d] ", label, kdata->length);
for (i=0; i < (int)kdata->length; i++)
{
- if (0 && isprint((int) kdata->data[i]))
-printf("%c ", kdata->data[i]);
+ if (0 && isprint((int) datastring[i]))
+printf("%c ", datastring[i]);
else
-printf("%02x ", (unsigned char)
kdata->data[i]);
+printf("%02x ", datastring[i]);
}
printf("\n");
}
@@ -1002,28 +1022,28 @@
print_krb5_keyblock(char *label, krb5_keyblock *keyblk)
{
int i;
+ unsigned char *keyblkcontents;
if (keyblk == NULL)
{
printf("%s, keyblk==0\n", label);
return;
}
+
#ifdef KRB5_HEIMDAL
printf("%s\n\t[et%d:%d]: ", label, keyblk->keytype,
- keyblk->keyvalue->length);
- for (i=0; i < (int)keyblk->keyvalue->length; i++)
-{
- printf("%02x",(unsigned char *)(keyblk->keyvalue->contents)[i]);
- }
- printf("\n");
+ keyblk->keyvalue.length);
+ memcpy(keyblkcontents, keyblk->keyvalue.data, keyblk->keyvalue.length);
Re: verify certificate - not from a file
Hi Patrick Thanks alot for the advise - I will try it :) Itay - Original Message - From: "Patrick Patterson" <[EMAIL PROTECTED]> To: openssl-dev@openssl.org Sent: Monday, November 24, 2008 5:36:31 PM (GMT+0200) Auto-Detected Subject: Re: verify certificate - not from a file On November 23, 2008 10:57:55 pm ThanhTrung Do wrote: > > From: Itay Dagan <[EMAIL PROTECTED]> > > Subject: verify certificate - not from a file > > To: openssl-dev@openssl.org > > Date: Monday, November 24, 2008, 12:37 AM > > Hi Guys > > > > I am new in openssl - so hopfully I am not bringing up an > > old issue : > > > > I am trying to verify a certificate that I am saving as > > string in a random place on my PC memory. > > > > I know that there is the > > "SSL_CTX_load_verify_locations()" that verify > > certificate from a file or a path. > > > > My Q is : > > Does openssl supports taking certificate not from a file or > > path but from a place in the memory ? > > meaning - A function that gets a char* - reads the > > certificate from that location and verifying it. > > > > > > appreciate your help :) > > I have the same need too, highly appreciate your helps. > Something like the following should work if the certificate is in PEM format. (note: this is example only - the below code is probably full of errors, because I just zen'd it from memory). I'm sure that Steve or one of the other guru's will correct any problems :) char certbuf = "PEM-ENCODED-CERTIFICATE"; BIO *bufbio = BIO_new(BIO_s_mem()); int len = BIO_puts(bufbio , certbuf); X509 *cert = X509_new(); PEM_read_bio_X509(bufbio, &cert, NULL, NULL); If the Cert is already in DER format, just use the d2i_X509() function to read it into the OpenSSL internal representation. Have fun. -- Patrick Patterson President and Chief PKI Architect, Carillon Information Security Inc. http://www.carillon.ca __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: verify certificate - not from a file
Patrick Patterson wrote:
On November 23, 2008 10:57:55 pm ThanhTrung Do wrote:
From: Itay Dagan <[EMAIL PROTECTED]>
Subject: verify certificate - not from a file
To: openssl-dev@openssl.org
Date: Monday, November 24, 2008, 12:37 AM
Hi Guys
I am new in openssl - so hopfully I am not bringing up an
old issue :
I am trying to verify a certificate that I am saving as
string in a random place on my PC memory.
I know that there is the
"SSL_CTX_load_verify_locations()" that verify
certificate from a file or a path.
My Q is :
Does openssl supports taking certificate not from a file or
path but from a place in the memory ?
meaning - A function that gets a char* - reads the
certificate from that location and verifying it.
appreciate your help :)
I have the same need too, highly appreciate your helps.
Something like the following should work if the certificate is in PEM format.
(note: this is example only - the below code is probably full of errors,
because I just zen'd it from memory). I'm sure that Steve or one of the other
guru's will correct any problems :)
char certbuf = "PEM-ENCODED-CERTIFICATE";
BIO *bufbio = BIO_new(BIO_s_mem());
int len = BIO_puts(bufbio , certbuf);
X509 *cert = X509_new();
PEM_read_bio_X509(bufbio, &cert, NULL, NULL);
If the Cert is already in DER format, just use the d2i_X509() function to read
it into the OpenSSL internal representation.
Have fun.
As Patrick wrote you can load a certificate into X509 structure, but
after that you need to validate it with other facilities such as
functions implemented in X509_STORE set. You can find a simple code
below to load both PEM and DER certificate into a X509 structure.
int loadFromMemory(char *buf, int bufLen)
{
BIO *bp = NULL;
X509 *cert = NULL;
#define retFree(x) do { \
if(bp) \
BIO_free(bp); \
if(cert) \
X509_free(cert); \
return x; \
} while(0);
if(!buf || bufLen < 1)
return 1;
bp = BIO_new(BIO_s_mem());
if(!bp)
return 2;
cert = X509_new();
if(!cert)
retFree(3);
if(!BIO_write(bp, buf, bufLen))
retFree(4);
cert = PEM_read_bio_X509(bp, NULL, NULL);
if(!cert) {
BIO_free(bp);
bp = BIO_new(BIO_s_mem());
if(!bp)
retFree(5);
if(!BIO_write(bp, (char *) buf, bufLen))
retFree(6);
cert = d2i_X509_bio(bp, NULL);
}
BIO_free(bp);
if(!cert)
retFree(7);
return 0;
}
Regards,
Shahin Khorasani
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: FIPS v1.2 test failures on FreeBSD 7
Ok, the tests passed when linking the fipscanister against the 0.9.8-stable snap 20081123 ... -Brad Brad House wrote: > I might have jumped the gun here. I'm getting that failure > on OpenSSL 0.9.8e (no fips), which I think was the branch > point for the FIPS v1.2, but not OpenSSL 0.9.8f (no fips). > So something must have been fixed between those 2 releases > for FreeBSD7. > > I'm going to go ahead and build the FIPS release, then try to > use the 20081123 snapshot and link the fips canister to that and > see if the tests pass. > > -Brad > > Brad House wrote: >> When running the tx509 test (with no args), it ends up generating >> a SIGILL. GDB says the instruction is 'ud2a' which I believe is the >> guaranteed illegal opcode on ia32. Not sure why it's being generated >> though. This occurs on both FreeBSD 7 x86 and x64. FreeBSD 5 and 6 >> do not exhibit this behavior. All are being run within VMWare Server >> v1.0.x, but that's never been an issue before. >> >> Just for testing purposes, I also tried using the 'no-asm', 'no-sse2', >> and '386' flags, and edited Configure to use '-O0 -g' instead of '-O3' >> and it also generates the same thing. >> >> Here's what GDB says: >> >> Starting program: /usr/home/build/openssl-fips-1.2/apps/openssl x509 -in >> fff.p -inform p -outform d >> [New LWP 100100] >> [New Thread 0x28401100 (LWP 100100)] >> >> Program received signal SIGILL, Illegal instruction. >> [Switching to Thread 0x28401100 (LWP 100100)] >> 0x0815b5e0 in PEM_read_bio_X509_AUX (bp=0x284051c0, x=0x0, cb=0x80c2a60 >> , u=0x0) >> (gdb) bt >> #0 0x0815b5e0 in PEM_read_bio_X509_AUX (bp=0x284051c0, x=0x0, cb=0x80c2a60 >> , u=0x0) >> #1 0x080c3843 in load_cert (err=0x28405040, file=0xbfbfedc3 "fff.p", >> format=3, pass=0x0, e=0x0, cert_descrip=0x81d3290 "Certificate") at >> apps.c:821 >> #2 0x080af73e in x509_main (argc=0, argv=0xbfbfecc0) at x509.c:632 >> #3 0x0809082b in do_cmd (prog=0x28406200, argc=7, argv=0xbfbfeca4) at >> openssl.c:396 >> #4 0x080904b8 in main (Argc=7, Argv=0xbfbfeca4) at openssl.c:315 >> (gdb) disas >> Dump of assembler code for function PEM_read_bio_X509_AUX: >> 0x0815b5e0 : ud2a >> End of assembler dump. >> >> $ gcc --version >> gcc (GCC) 4.2.1 20070719 [FreeBSD] >> >> Any ideas? GCC issue perhaps? >> >> Thanks. >> -Brad >> >> >> __ >> OpenSSL Project http://www.openssl.org >> Development Mailing List openssl-dev@openssl.org >> Automated List Manager [EMAIL PROTECTED] >> > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager [EMAIL PROTECTED] > __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: FIPS v1.2 test failures on FreeBSD 7
On Mon, Nov 24, 2008, Brad House wrote: > I might have jumped the gun here. I'm getting that failure > on OpenSSL 0.9.8e (no fips), which I think was the branch > point for the FIPS v1.2, but not OpenSSL 0.9.8f (no fips). > So something must have been fixed between those 2 releases > for FreeBSD7. > > I'm going to go ahead and build the FIPS release, then try to > use the 20081123 snapshot and link the fips canister to that and > see if the tests pass. > There is an issue with how OpenSSL uses function pointers which gcc 4.2 and later chokes on, you should see warning saying it will abort when you compiled it. It was was fixed around that time. You shouldn't see that issue if you compile a newer version of OpenSSL or link the FIPS modules against a newer version. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1790] [Patch] Windows CE 5 and following support
Maurice Kalinowski wrote:
Hi,
[SNIP]
- apps/ocsp.c
why extra include of ? this mean that e_os.h patch is
incomplete.
I was tempted to add the include in e_os.h, but as this is the only file
requiring this header I felt it to be much cleaner. If the general
consensus is that e_os should be responsible for header inclusion
ignoring that other files will use it for no purpose, I can change the
patch accordingly.
Other openssl code use socket functions too.
- ms/do_ms.bat
please keep changes minimal
There seemed to be a line-ending mixup or sth. It basically just adds
"enable-experimental-jpake" to the WinCE makefile generator.
- util/pl/VC-32.pl
please don't remove flags that affect warnings. WX->Wall ?
As stated in the mail, I needed to disable WX to have at least a
successful compilation. WX treats warnings as errors and thus it will
fail on two instances, where my knowledge about OpenSSL insides is
limited. As already mentioned, I can send both compile warnings(errors)
to this list and somebody can have a look at them.
If I remember well option "Wall" don't treat warnings as errors.
why is linked with crypt32 ?
The additional dependency results from using Cert* functions inside of
engines/e_capi.c.
Yep. capi is experimental and build of openssl-HEAD need some
improvements, i.e. to support additional engine libraries in both cases:
static and shared build.
I mean following changes:
=
+ if ($wcevers >= 500) {
+ $lflags .=" /NODEFAULTLIB:oldnames.lib /NODEFAULTLIB:libc.lib
crypt32.lib";
+ if ($target =~ /capi/ && $FLAVOR !~ /CE/)
{
$ex.=' crypt32.lib advapi32.lib';
=
Only capi-engine require crypt32.
Why you add crypt32 to $lflags ?
Best Regards,
Maurice Kalinowski
Roumen
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1791] BUG: openssl 0.9.8i creates a notAfter time in the past for dates after 2049
Christopher Williams via RT wrote: If I attempt to create a certificate with an expiry time after 2049 (so that openssl will use a GeneralizedTime rather than a UTCTime for the notAfter field), openssl actually generates a date in the past. [SNIP] Did HEAD work for you ? http://cvs.openssl.org/chngview?cn=17499 Roumen __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1703] Bug report for DTLS
Apologies for delayed response. There was some bureaucracy to go through to make sure I had management approval for releasing the code which explains my interest in the subject. That's done now; we have a full open source client for the VPN in question, and OpenSSL client support for BAD_DTLS_VER is the last piece in the jigsaw for me. http://git.infradead.org/users/dwmw2/openconnect.git git://git.infradead.org/users/dwmw2/openconnect.git On Wed, 2008-10-15 at 09:13 +0200, Andy Polyakov wrote: > >>> Note: I have reverted the DTLS1_BAD_VER part as DTLS1_BAD_VER handling > >>> is not present in HEAD (0.9.9). > >>> > >> That makes sense. > >> > >> I assume that DTLS1_BAD_VER handling wasn't added to HEAD because the > >> pre-RFC version of DTLS was considered to be an OpenSSL-specific thing > >> that would quickly die out as people upgraded to 0.9.8f and beyond? > > Right. > > >> Now we've observed that there are servers in the wild which implement > >> that old OpenSSL-specific version of the protocol, but which we'd like > >> to be compatible with. > > Could you clarify? Haven't you mentioned that it's about Cisco > AnyConnect VPN? Isn't it OpenSSL-based? If it's pre-0.9.8f-based, then > shouldn't you question if it's appropriate to use it at all because of > security problems? They do update to a new version of OpenSSL periodically, and they also backport security patches even more frequently than that, allegedly. But their products use the pre-RFC version of DTLS, so they have to remain compatible with that. So even though they're currently on 0.9.8f, they're still using DTLS1_BAD_VER. Their server _does_ seem to accept some variant of the _real_ DTLS protocol, but it's strangely broken -- you have to calculate the MAC as if the version number in the packets was DTLS1_BAD_VER, even though it isn't. And although the _handshake_ works that way, the server still seems to ignore all incoming data packets. I strongly suspect that their implementation of REAL_VER is completely broken, and that there is _no_ way to interoperate with it. The real clients use DTLS1_BAD_VER, and that's what we need to use too. > And if it turns out that their REAL_VER is not RFC-compliant, then > why did they choose REAL_VER and not VENDOR_VER? They don't care about REAL_VER and probably aren't even aware that their server seems to accept it. They never use it, and it's not tested. If they do ever realise, they'll probably turn it off. > In other words, can you remind the reason for re-introducing > BAD_DTLS:-) _My_ reason for wanting to re-introduce DTLS1_BAD_VER is purely interoperability. There are servers out there which use it, which we really really want to talk to. And it's a fairly simple patch. > Even in worst case is DTLS the only option in > AnyConnect? I mean if it doesn't work, why not use TLS [till DTLS is > fixed to be RFC-compliant]? This is a VPN, and TCP over TCP _really_ sucks. The only viable option for connecting to these VPN servers is to use DTLS1_BAD_VER, really. > >> If I can actually get that working in HEAD, would > >> a patch to support it be acceptable? > >> > > I had a deeper look into the mailing list archive and I did not find > > any explicit statement on why this was handed differently in 0.9.8 > > and in HEAD. > > Finally we would of course prefer to move people to update to an > > RFC compliant version, so I guess the pre-RFC support should be > > configurable somehow. Andy, what do you think? With my patch, the pre-RFC support is only available if you manually set up a session to be 'resumed' that way. We don't need anything more, because the master-secret and session-id for the DTLS session are actually exchanged over HTTPS in advance. > My vote still goes for *not* implementing BAD_VER in HEAD. Please reconsider. Obviously the _correct_ thing for them to do is make REAL_VER work on the server in parallel with BAD_VER, then slowly migrate their clients to use REAL_VER and over time they can completely forget about BAD_VER. But this is a vendor of proprietary software. Of _course_ they don't have the wit to do that, and we have to interoperate with what we're given. -- dwmw2 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Can I create certificate for using in Windows ???
Can I create certificate for using in Windows ???
