Re: [openssl-dev] [openssl.org #4622] OpenSSL doesn't recognise pre-rfc3820 proxy certs
Hi Rich, On 22/07/16 14:52, Salz, Rich via RT wrote: And now, with subject clearly stated, I think we should not do this. the original question related to this ticket was the missing accessors in OpenSSL 1.1. I fully agree that OpenSSL should not add support for pre-RFC3820 proxy, but it should allow others to write code to support it. That's the way OpenSSL 0.9.x and 1.0.x did it: the Globus and Voms people added their own handlers to the OpenSSL callbacks in order to support GT2, GT3 and RFC3820 (aka GT4) proxies. With OpenSSL 1.1, some of these handlers/callbacks seem to have been removed. If OpenSSL 1.1 does not allow this, then the existing grid codebase is "stuck" with OpenSSL 1.0.x until all users start using RFC3820 proxies. Again, I support the notion that people should have started using these back in 2008 but the reality is that we in "Grid land" are stuck with "legacy" proxies for some time. It would be a shame if we cannot use OpenSSL 1.1+ on the grid. JM2CW, JJK / Jan Just Keijser PS I'm a co-worker of Mischa Salle -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4602] Missing accessors
Hi Richard, On 20/07/16 17:14, Richard Levitte via RT wrote: > On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote: >> I guess having a more restrictive accessor that only sets the >> EXFLAG_PROXY bit could work. I suggested the more general solution of >> having set/clear accessors for arbitrary flags since it was - well >> more >> general. > So let me ask this in a different manner, does OpenSSL 1.1 still not set the > EXFLAG_PROXY flag correctly? In what situations does that happen? That may be > worth a bug report of its own. > this ties into my earlier question and example of verifying proxy certificates. What if I want to explicitly *set* the EXFLAG_PROXY for a stack of certificates? how would I do that? how can I ensure that OpenSSL 1.1 will automagically trigger this flag for me? Is there a 'get_*' function to determine which flags were set during certificate verification? thanks for any pointers or advice, JJK / Jan Just Keijser -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4602] Missing accessors
Hi Richard, On 20/07/16 17:14, Richard Levitte via RT wrote: On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote: I guess having a more restrictive accessor that only sets the EXFLAG_PROXY bit could work. I suggested the more general solution of having set/clear accessors for arbitrary flags since it was - well more general. So let me ask this in a different manner, does OpenSSL 1.1 still not set the EXFLAG_PROXY flag correctly? In what situations does that happen? That may be worth a bug report of its own. this ties into my earlier question and example of verifying proxy certificates. What if I want to explicitly *set* the EXFLAG_PROXY for a stack of certificates? how would I do that? how can I ensure that OpenSSL 1.1 will automagically trigger this flag for me? Is there a 'get_*' function to determine which flags were set during certificate verification? thanks for any pointers or advice, JJK / Jan Just Keijser -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4617] openssl Issue/Bug
Hi Harold, On 18/07/16 21:31, Lapprich, Harold via RT wrote: > JJK, > > Thanks for the quick response, it is really appreciated. Can I ask where you > picked up the syntax for this command line (familiar with the various shells > and /dev/null but couldn't put this together)? this is off-topic for this list, but I cannot email you directly. You could try reading up at http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-3.html or any other hit that comes up when searching for "linux shell stderr redirect" HTH, JJK > -Original Message----- > From: Jan Just Keijser via RT [mailto:r...@openssl.org] > Sent: Monday, July 18, 2016 2:26 PM > To: Lapprich, Harold (GE Aviation, US) > Cc: openssl-dev@openssl.org > Subject: EXT: Re: [openssl-dev] [openssl.org #4617] openssl Issue/Bug > > Hi, > > On 18/07/16 18:39, Lapprich, Harold via RT wrote: >> To Whom It May Concern, >> >> openssl version -a: >> >> OpenSSL 1.0.2a 19 Mar 2015 >> >> built on: reproducible build, date unspecified >> >> platform: linux-ppc >> >> options: bn(64,32) rc4(ptr,char) des(idx,risc1,16,long) blowfish(idx) >> >> compiler: >> /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/us >> r/bin/ccache >> /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/us >> r/bin/powerpc-e500v2-linux-uclibc-gcc -I. -I.. -I../include -fPIC >> -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT >> -DDSO_DLFCN -DHAVE_DLFCN_H -DB_ENDIAN -D_LARGEFILE_SOURCE >> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -mcpu=8540 -pipe -O2 >> -Wall -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM >> -DAES_ASM -DVPAES_ASM >> >> OPENSSLDIR: "/etc/ssl" >> >> >> >> OS Name, Version, Hardware platform: >> >> uname -a >> >> Linux ahmu-iop-devel 3.10.76 #1 SMP PREEMPT Fri Jul 8 11:18:12 EDT >> 2016 ppc GNU/Linux >> >> >> >> >> Using 'openssl' in a Linux design and since it is a command line application >> it is always outputting content to the screen, for example: >> >> >> openssl req -new -x509 -nodes -days 365 -subj >> "/C=US/ST=Ohio/L=Cincinnati/O=www.ge.com/OU=AHMU-UNIT/CN=AHMU-UNIT" >> -keyout start -out start >> >> Generating a 2048 bit RSA private key >> >> .. >> ...+++ >> >> .+++ >> >> writing new private key to 'start' >> >> - >> >> >> Trying to find a way to prevent the output being output to 'stdout' but have >> not found a parameter (can redirect to a file but the .+ characters are >> still written to the console). >> >> >> There either has to be a missed parameter or bug exist? >> > This is not a bug or lacking feature. > The + characters are written to stderr, so if you use > openssl .> stdout 2> stderr > the characters disappear (into the file 'stderr'; use '2> /dev/null' to send > then straight to bit-heaven). This depends slightly on the shell you use, > BTW. The above syntax is for bash/zsh/ksh; for csh/tcsh a different syntax > applies. > > HTH, > > JJK > > > -- > Ticket here: > https://urldefense.proofpoint.com/v2/url?u=http-3A__rt.openssl.org_Ticket_Display.html-3Fid-3D4617=CwIDaQ=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=i74Dd1YgazOdjUqZ7H6RwfJnspP534048ulHQI_l8Lg=hC-ePxGkl2IKC2iYTHYFk1qfc32xU_KzR5R3duyHaIM=G81nAuvPiu8kBUwgddPaVgh_UkoNVeOvf7Q4veAdNVo= > Please log in as guest with password guest if prompted > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4617 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4617] openssl Issue/Bug
Hi Harold, On 18/07/16 21:31, Lapprich, Harold via RT wrote: JJK, Thanks for the quick response, it is really appreciated. Can I ask where you picked up the syntax for this command line (familiar with the various shells and /dev/null but couldn't put this together)? this is off-topic for this list, but I cannot email you directly. You could try reading up at http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-3.html or any other hit that comes up when searching for "linux shell stderr redirect" HTH, JJK -Original Message----- From: Jan Just Keijser via RT [mailto:r...@openssl.org] Sent: Monday, July 18, 2016 2:26 PM To: Lapprich, Harold (GE Aviation, US) Cc: openssl-dev@openssl.org Subject: EXT: Re: [openssl-dev] [openssl.org #4617] openssl Issue/Bug Hi, On 18/07/16 18:39, Lapprich, Harold via RT wrote: To Whom It May Concern, openssl version -a: OpenSSL 1.0.2a 19 Mar 2015 built on: reproducible build, date unspecified platform: linux-ppc options: bn(64,32) rc4(ptr,char) des(idx,risc1,16,long) blowfish(idx) compiler: /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/us r/bin/ccache /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/us r/bin/powerpc-e500v2-linux-uclibc-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DB_ENDIAN -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -mcpu=8540 -pipe -O2 -Wall -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DVPAES_ASM OPENSSLDIR: "/etc/ssl" OS Name, Version, Hardware platform: uname -a Linux ahmu-iop-devel 3.10.76 #1 SMP PREEMPT Fri Jul 8 11:18:12 EDT 2016 ppc GNU/Linux Using 'openssl' in a Linux design and since it is a command line application it is always outputting content to the screen, for example: openssl req -new -x509 -nodes -days 365 -subj "/C=US/ST=Ohio/L=Cincinnati/O=www.ge.com/OU=AHMU-UNIT/CN=AHMU-UNIT" -keyout start -out start Generating a 2048 bit RSA private key .. ...+++ .+++ writing new private key to 'start' - Trying to find a way to prevent the output being output to 'stdout' but have not found a parameter (can redirect to a file but the .+ characters are still written to the console). There either has to be a missed parameter or bug exist? This is not a bug or lacking feature. The + characters are written to stderr, so if you use openssl .> stdout 2> stderr the characters disappear (into the file 'stderr'; use '2> /dev/null' to send then straight to bit-heaven). This depends slightly on the shell you use, BTW. The above syntax is for bash/zsh/ksh; for csh/tcsh a different syntax applies. HTH, JJK -- Ticket here: https://urldefense.proofpoint.com/v2/url?u=http-3A__rt.openssl.org_Ticket_Display.html-3Fid-3D4617=CwIDaQ=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=i74Dd1YgazOdjUqZ7H6RwfJnspP534048ulHQI_l8Lg=hC-ePxGkl2IKC2iYTHYFk1qfc32xU_KzR5R3duyHaIM=G81nAuvPiu8kBUwgddPaVgh_UkoNVeOvf7Q4veAdNVo= Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4617] openssl Issue/Bug
Hi, On 18/07/16 18:39, Lapprich, Harold via RT wrote: > To Whom It May Concern, > > openssl version -a: > > OpenSSL 1.0.2a 19 Mar 2015 > > built on: reproducible build, date unspecified > > platform: linux-ppc > > options: bn(64,32) rc4(ptr,char) des(idx,risc1,16,long) blowfish(idx) > > compiler: > /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/usr/bin/ccache > > /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/usr/bin/powerpc-e500v2-linux-uclibc-gcc > -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB > -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DB_ENDIAN > -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -mcpu=8540 > -pipe -O2 -Wall -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM > -DAES_ASM -DVPAES_ASM > > OPENSSLDIR: "/etc/ssl" > > > > OS Name, Version, Hardware platform: > > uname -a > > Linux ahmu-iop-devel 3.10.76 #1 SMP PREEMPT Fri Jul 8 11:18:12 EDT 2016 ppc > GNU/Linux > > > > > Using 'openssl' in a Linux design and since it is a command line application > it is always outputting content to the screen, for example: > > > openssl req -new -x509 -nodes -days 365 -subj > "/C=US/ST=Ohio/L=Cincinnati/O=www.ge.com/OU=AHMU-UNIT/CN=AHMU-UNIT" -keyout > start -out start > > Generating a 2048 bit RSA private key > > .+++ > > .+++ > > writing new private key to 'start' > > - > > > Trying to find a way to prevent the output being output to 'stdout' but have > not found a parameter (can redirect to a file but the .+ characters are > still written to the console). > > > There either has to be a missed parameter or bug exist? > This is not a bug or lacking feature. The + characters are written to stderr, so if you use openssl .> stdout 2> stderr the characters disappear (into the file 'stderr'; use '2> /dev/null' to send then straight to bit-heaven). This depends slightly on the shell you use, BTW. The above syntax is for bash/zsh/ksh; for csh/tcsh a different syntax applies. HTH, JJK -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4617 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4617] openssl Issue/Bug
Hi, On 18/07/16 18:39, Lapprich, Harold via RT wrote: To Whom It May Concern, openssl version -a: OpenSSL 1.0.2a 19 Mar 2015 built on: reproducible build, date unspecified platform: linux-ppc options: bn(64,32) rc4(ptr,char) des(idx,risc1,16,long) blowfish(idx) compiler: /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/usr/bin/ccache /home/devadmin/buildserver/staging/build-output/c919/trunk-iop/host/usr/bin/powerpc-e500v2-linux-uclibc-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DB_ENDIAN -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -mcpu=8540 -pipe -O2 -Wall -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DVPAES_ASM OPENSSLDIR: "/etc/ssl" OS Name, Version, Hardware platform: uname -a Linux ahmu-iop-devel 3.10.76 #1 SMP PREEMPT Fri Jul 8 11:18:12 EDT 2016 ppc GNU/Linux Using 'openssl' in a Linux design and since it is a command line application it is always outputting content to the screen, for example: openssl req -new -x509 -nodes -days 365 -subj "/C=US/ST=Ohio/L=Cincinnati/O=www.ge.com/OU=AHMU-UNIT/CN=AHMU-UNIT" -keyout start -out start Generating a 2048 bit RSA private key .+++ .+++ writing new private key to 'start' - Trying to find a way to prevent the output being output to 'stdout' but have not found a parameter (can redirect to a file but the .+ characters are still written to the console). There either has to be a missed parameter or bug exist? This is not a bug or lacking feature. The + characters are written to stderr, so if you use openssl .> stdout 2> stderr the characters disappear (into the file 'stderr'; use '2> /dev/null' to send then straight to bit-heaven). This depends slightly on the shell you use, BTW. The above syntax is for bash/zsh/ksh; for csh/tcsh a different syntax applies. HTH, JJK -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] build issue with openssl 1.1.0-pre5
hi all, I'm the maintainer of grid-proxy-verify, a grid-tool that uses "plain" openssl to verify a grid proxy (either RFC3820 or legacy Globus proxy). This tool http://www.nikhef.nl/~janjust/proxy-verify/ and http://www.nikhef.nl/~janjust/proxy-verify/grid-proxy-verify.c builds without any warnings with openssl 0.9.8 and 1.0.x, e.g. using gcc -Wall -pedantic -c -o grid-proxy-verify.o grid-proxy-verify.c but with 1.1.0 I run into all sorts of issues (see the bottom of this email). Most of these have to do with members of structs becoming opaque but especially the disappearance of the check_issued callback is worrisome, as that callback is crucial for verifying proxy certificates. How should I modify my code so that it builds and links with openssl 1.1.0? thx for any pointers, JJK / Jan Just Keijser $ gcc -I openssl-1.1.0-pre5/include -o grid-proxy-verify.o grid-proxy-verify.c grid-proxy-verify.c: In function ‘grid_X509_check_issued_wrapper’: grid-proxy-verify.c:337:14: error: dereferencing pointer to incomplete type if (!(ctx->param->flags & X509_V_FLAG_CB_ISSUER_CHECK)) return 0; ^ grid-proxy-verify.c:341:8: error: dereferencing pointer to incomplete type ctx->error = ret; ^ grid-proxy-verify.c:342:8: error: dereferencing pointer to incomplete type ctx->current_cert = x; ^ grid-proxy-verify.c:343:8: error: dereferencing pointer to incomplete type ctx->current_issuer = issuer; ^ grid-proxy-verify.c:344:15: error: dereferencing pointer to incomplete type return ctx->verify_cb(0, ctx); ^ grid-proxy-verify.c: In function ‘grid_verifyProxy’: grid-proxy-verify.c:529:25: error: dereferencing pointer to incomplete type if (pkey->type == EVP_PKEY_RSA) ^ grid-proxy-verify.c:531:56: error: dereferencing pointer to incomplete type int key_strength = BN_num_bits(pkey->pkey.rsa->n); ^ grid-proxy-verify.c: In function ‘grid_X509_verify_callback’: grid-proxy-verify.c:593:16: error: dereferencing pointer to incomplete type ctx->error = errnum; ^ grid-proxy-verify.c:620:21: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] certstack = (STACK_OF(X509) *) X509_STORE_CTX_get_chain( ctx ); ^ grid-proxy-verify.c:627:12: error: dereferencing pointer to incomplete type ctx->error = errnum; ^ In file included from openssl-1.1.0-pre5/include/openssl/x509.h:363:0, from grid-proxy-verify.c:38: grid-proxy-verify.c: In function ‘grid_verifyCert’: openssl-1.1.0-pre5/include/openssl/x509_vfy.h:107:56: error: dereferencing pointer to incomplete type # define X509_STORE_set_verify_cb_func(ctx,func) ((ctx)->verify_cb=(func)) ^ grid-proxy-verify.c:686:5: note: in expansion of macro ‘X509_STORE_set_verify_cb_func’ X509_STORE_set_verify_cb_func (store, grid_X509_verify_callback); ^ grid-proxy-verify.c:720:10: error: dereferencing pointer to incomplete type store->check_issued = grid_X509_check_issued_wrapper; ^ grid-proxy-verify.c:783:9: error: dereferencing pointer to incomplete type cert->ex_flags |= EXFLAG_PROXY; ^ grid-proxy-verify.c:785:16: error: dereferencing pointer to incomplete type verify_ctx -> param -> depth = depth + 5; ^ grid-proxy-verify.c:794:25: error: dereferencing pointer to incomplete type ret = verify_ctx->error; ^ grid-proxy-verify.c: In function ‘main’: grid-proxy-verify.c:965:5: warning: ‘ERR_remove_state’ is deprecated (declared at openssl-1.1.0-pre5/include/openssl/err.h:363) [-Wdeprecated-declarations] ERR_remove_state(0); ^ -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4529] Output of -hash option incompatible 64-bit Linux vs 32-bit Linux
Withers John Z via RT wrote: > To whom it may concern, > > I have built OpenSSL 1.0.1s for 64-bit and 32-bit version of RHEL5.11. The > reasons for this are long and involve my employer, so I would detail them in > this message. > > I successfully built and deployed to a 64-bit RHEL 5.11 server (using a local > installation path) and was able to configure the issuer certificate cache for > my applications. I built a separate package for 32-bit RHEL 5.11 (again, > using a local installation path). After installation, I observed that the > -hash option of the openssl command (and hence the c_rehash utility) computed > incorrect subject hashes for the issuer certificates in the cache. Identical > certificates from the 64-bit installation were installed but the hash values > were different. Tracing the operation of the s_client module with strace > indicated that the hash values computed internally matched the hash values > produced on the 64-bit system. I replicated the symbolic links for the > issuer certificates from the 64-bit system to the 32-bit system and the > certificates presented by the remote server for my application were verified. > > FWIW: I've downloaded and built openssl-1.0.1s on my EL 5.11 box in both 32bit and 64bit mode (I needed to hack ./Configure for that, BTW). The resulting openssl x509 -hash command prints out the exact same hash for both the 32bit and 64bit versions. HTH, JJK / Jan Just Keijser Nikhef Amsterdam -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4529 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4529] Output of -hash option incompatible 64-bit Linux vs 32-bit Linux
Withers John Z via RT wrote: To whom it may concern, I have built OpenSSL 1.0.1s for 64-bit and 32-bit version of RHEL5.11. The reasons for this are long and involve my employer, so I would detail them in this message. I successfully built and deployed to a 64-bit RHEL 5.11 server (using a local installation path) and was able to configure the issuer certificate cache for my applications. I built a separate package for 32-bit RHEL 5.11 (again, using a local installation path). After installation, I observed that the -hash option of the openssl command (and hence the c_rehash utility) computed incorrect subject hashes for the issuer certificates in the cache. Identical certificates from the 64-bit installation were installed but the hash values were different. Tracing the operation of the s_client module with strace indicated that the hash values computed internally matched the hash values produced on the 64-bit system. I replicated the symbolic links for the issuer certificates from the 64-bit system to the 32-bit system and the certificates presented by the remote server for my application were verified. FWIW: I've downloaded and built openssl-1.0.1s on my EL 5.11 box in both 32bit and 64bit mode (I needed to hack ./Configure for that, BTW). The resulting openssl x509 -hash command prints out the exact same hash for both the 32bit and 64bit versions. HTH, JJK / Jan Just Keijser Nikhef Amsterdam -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Are you using "TLS proxy certificates"?
Hi Rich, On 27/04/16 18:45, Salz, Rich wrote: If so, please let us know. Replies to me will be summarized for the lists. what exactly do you mean by 'TLS proxy certificates' ? if you mean RFC3820 (5280) proxy certificates, then yes, we use them extensively within grid computing. regards, JJK / Jan Just Keijser Nikhef Amsterdam -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Using keys from a hardware accelerator
Hi Alexander, Alexander Gostrer wrote: Hi All, I am working on an OpenSSL modification for a hardware accelerator who generates and uses private keys internally without a way to export/import them. The standard OpenSSL approach is to use keys from files. Is there any preferred way to point to keys in the hardware? There is more and more hardware on the market that people want to use directly from the OpenSSL. There is a standard for this, PKCS#11, that is fairly well supported by OpenSSL. Numerous hardware tokens and smartcards exist that can interact with OpenSSL (via engine_pkcs11). I have personal experience with various usb hardware tokens from Feitian and Aladdin/SafeNet. The main feature of such tokens is that indeed the private key cannot be exported from the device. hope this helps, JJK / Jan Just Keijser ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3843] OpenSSL 1.0.1* and below: incorrect use of _lrotl()
Hi, r...@openssl.org via RT wrote: And linux-x86_64 won't work here, since it uses some instructions not supported by MIC. But all x86_64 modules feature run-time switch, when processor capabilities are detected [with cpuid] and code that can't be executed on any particular processor won't execute. Or do you mean that fails to *compile* it with -mmic? Or do you mean that cpuid doesn't work on mic? But I recall that there is cpuid... It fails to compile with -mmic: x86_64cpuid.s:165: Error: `pxor' is not supported on `k1om' I see, thanks. In other words, as it turns out my suggestion about run-time switch does not apply in this case, because minimum of SSE2 is actually *assumed* for x86_64 platform. And this doesn't hold true for Knights Corner. But it does hold true for Knights Landing, doesn't it? I see no point in attempting to accommodate assembler support for Knights Corner (too rare processor) and would appreciate if you could confirm if following works with 1.0.2: ./Configure linux-x86_64-icc no-asm -mmic BTW, _lrotl fix is applied to 1.0.1, but not earlier versions, which are open for security fixes only. I can confirm that a clean build of openssl 1.0.2a using the above ./Configure line works for me. The resulting binary runs without issues. JJK ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3843] OpenSSL 1.0.1* and below: incorrect use of _lrotl()
Hi, r...@openssl.org via RT wrote: And linux-x86_64 won't work here, since it uses some instructions not supported by MIC. But all x86_64 modules feature run-time switch, when processor capabilities are detected [with cpuid] and code that can't be executed on any particular processor won't execute. Or do you mean that fails to *compile* it with -mmic? Or do you mean that cpuid doesn't work on mic? But I recall that there is cpuid... It fails to compile with -mmic: x86_64cpuid.s:165: Error: `pxor' is not supported on `k1om' I see, thanks. In other words, as it turns out my suggestion about run-time switch does not apply in this case, because minimum of SSE2 is actually *assumed* for x86_64 platform. And this doesn't hold true for Knights Corner. But it does hold true for Knights Landing, doesn't it? I see no point in attempting to accommodate assembler support for Knights Corner (too rare processor) and would appreciate if you could confirm if following works with 1.0.2: ./Configure linux-x86_64-icc no-asm -mmic BTW, _lrotl fix is applied to 1.0.1, but not earlier versions, which are open for security fixes only. I can confirm that a clean build of openssl 1.0.2a using the above ./Configure line works for me. The resulting binary runs without issues. JJK ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: Single-Makefile Build Experiment report
Nathan Typanski wrote: On 08/14, Tim Hollebeek wrote: Have you considered moving to CMake? It makes lots of the issues you discuss in the document just go away. cmake should work on the vast majority of supported operating systems, if not all of them ... Cmake has disadvantages. I haven't actually used it enough to comment on what it's like to use, but I can link to a project that has: https://wiki.openoffice.org/wiki/Build_System_Analysis#CMake OpenOffice was trying to solve the recursive make problem in their project, much like OpenSSL is attempting. They ultimately decided against CMake and gave a good writeup of their reasoning. There's also a nice debate at LWN.net about GNU Make/CMake and the related tradeoffs. http://lwn.net/Articles/466137/ Also, consider the scenario: - I'm an embedded developer and I want to compile OpenSSL on my embedded system (or any platform that isn't my workstation). It doesn't have CMake, I can't get CMake on it or don't have the resources (or desire) to get CMake installed on the target platform. - To solve this, I download OpenSSL on my workstation and tell CMake to generate a GNU Makefile for me. I copy the source over to the platform I want to build OpenSSL on. - I do `./configure make make install` and pray. - The build fails and dumps and unhelpful error message. I go digging into the generated Makefile looking for the build error and realize CMake has built absolute paths into everything. - I go on the CMake wiki and read this: http://www.cmake.org/Wiki/CMake_FAQ#Why_does_CMake_use_full_paths.2C_or_can_I_copy_my_build_tree.3F where the answer is basically no, you can't use CMake like that. Go install CMake on your embedded device, or figure out how the hell to cross-compile a CMake build. - Researching cross-compiling CMake turns up this: http://blog.beuc.net/posts/Cross-compiling_with_CMake/ - I come complain on this mailing list because OpenSSL has rejected both GNU and UNIX-like standards in favor of this stupid more advanced build system. Maybe I'm biased, but from what I've seen with projects using CMake, CMake is only portable in the sense that KDE is portable: yes, if you're willing to enforce complete buy-in from the users/packagers/maintainers, people can build OpenSSL easily on more than one system. But from my eyes it doesn't look like a low-level, relatively tiny C library has any good reason to switch to CMake. FWIW: my experience with CMake is quite negative. A few years ago I had to package some software for scientific grid computing and the cmake based ones were always the hardest ones. If a cmake build was working then it wasn't so bad but if you need to debug it or if you need to cross-compile then it is (IMHO) an absolute nightmare. I'd consider it a step backwards if openssl moved in the direction of cmake. JM2CW, JJK / Jan Just Keijser __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3451] patch for x509.c
Hi Richard,
On 15/07/14 10:56, Richard Levitte via RT wrote:
I do like the idea, and definitely see the need for this.
A nit pick, though '-valid' as a option name is a bit confusing, I'd
personally expect it to take a full blown time argument -- something like
DDD-HH:MM -- and not just hours and minutes. Maybe '-time' or something like
that. That or actually have '-valid' take the full blown argument (thereby
replacing '-days' in the long run).
thanks for picking this up; the name '-valid' as well as the format
HH:MM came from the Globus Toolkit 'grid-proxy-init' command, which
uses the same syntax. I agree that the name might be a bit confusing. If
I understand you correctly you're suggesting to use
-valid DDD-HH:MM
(I'm using '-valid' here for lack of a better name right now) where
anything before the hyphen is the number of days, and anything after it
is the time in HH:MM format? It should be possible to specify HH 24,
and we could also support MM 60 (e.g -valid 0-0:1440 == -valid 0-24:00
== -valid 1-0:00 == -days 1)
but then the syntax
-valid 0-24:00
seems confusing as well ... or we could use logic as follows:
if arg contains hyphen then anything before it is #days, anything after
it is time in HH:MM format
if arg contains no hyphen and no colon then it's the number of days
if arg contains no hyphen but it does contain a colon then #days = 0 and
the entire argument is a time in HH:MM format
suggestions?
JJK / Jan Just Keijser
Nikhef
Amsterdam
On Sun Jul 13 20:13:28 2014, janj...@nikhef.nl wrote:
hi ,
attached is a minor patch to apps/x509.c. The patch allows the user to
specify the validity of a certificate in hours and minutes (next to
days). This is esp useful when creating grid/RFC3820 proxies which
typically have a duration of 12 hours.
regards,
JJK / Jan Just Keijser
--- openssl-1.0.1c/apps/x509.c 2011-10-10 01:13:46.0 +0200
+++ openssl-1.0.1c-jjk/apps/x509.c 2012-08-09 09:17:37.783134860 +0200
@@ -128,6 +128,7 @@
-addreject arg - reject certificate for a given purpose\n,
-setalias arg - set certificate alias\n,
-days arg - How long till expiry of a signed certificate -
def 30 days\n,
+ -valid HH:MM - How long till expiry of a signed certificate\n,
-checkend arg - check whether the cert expires in the next arg
seconds\n,
exit 1 if so, 0 if not\n,
-signkey arg - self sign cert with arg\n,
@@ -154,12 +155,12 @@
};
static int MS_CALLBACK callb(int ok, X509_STORE_CTX *ctx);
-static int sign (X509 *x, EVP_PKEY *pkey,int days,int clrext, const
EVP_MD *digest,
+static int sign (X509 *x, EVP_PKEY *pkey,int minutes,int clrext,
const EVP_MD *digest,
CONF *conf, char *section);
static int x509_certify (X509_STORE *ctx,char *CAfile,const EVP_MD
*digest,
X509 *x,X509 *xca,EVP_PKEY *pkey,
STACK_OF(OPENSSL_STRING) *sigopts,
- char *serial, int create ,int days, int clrext,
+ char *serial, int create ,int minutes, int clrext,
CONF *conf, char *section, ASN1_INTEGER *sno);
static int purpose_print(BIO *bio, X509 *cert, X509_PURPOSE *pt);
static int reqfile=0;
@@ -194,7 +195,7 @@
int ocsp_uri=0;
int trustout=0,clrtrust=0,clrreject=0,aliasout=0,clrext=0;
int C=0;
- int x509req=0,days=DEF_DAYS,modulus=0,pubkey=0;
+ int x509req=0,days=DEF_DAYS,minutes=0,modulus=0,pubkey=0;
int pprint = 0;
const char **pp;
X509_STORE *ctx=NULL;
@@ -292,6 +293,26 @@
goto bad;
}
}
+ else if (strcmp(*argv,-valid) == 0)
+ {
+ if (--argc 1) goto bad;
+
+ char *delim = strchr(*(++argv), ':');
+ if (delim)
+ {
+ *delim = '\0';
+ delim++;
+ minutes = atoi( delim );
+ }
+ int hours = atoi( *argv );
+ minutes = 60 * hours + minutes;
+
+ if (minutes == 0)
+ {
+ BIO_printf(STDout,bad -valid specification\n);
+ goto bad;
+ }
+ }
else if (strcmp(*argv,-passin) == 0)
{
if (--argc 1) goto bad;
@@ -511,6 +532,10 @@
goto end;
}
+ if (minutes == 0)
+ {
+ minutes = 24*60*days;
+ }
if (!X509_STORE_set_default_paths(ctx))
{
ERR_print_errors(bio_err);
@@ -964,7 +989,7 @@
}
assert(need_rand);
- if (!sign(x,Upkey,days,clrext,digest,
+ if (!sign(x,Upkey,minutes,clrext,digest,
extconf, extsect)) goto end;
}
else if (CA_flag == i)
@@ -982,7 +1007,7 @@
assert(need_rand);
if (!x509_certify(ctx,CAfile,digest,x,xca,
CApkey, sigopts,
- CAserial,CA_createserial,days, clrext,
+ CAserial,CA_createserial,minutes, clrext,
extconf, extsect, sno))
goto end;
}
@@ -1148,7 +1173,7 @@
X509 *x, X509 *xca, EVP_PKEY *pkey,
STACK_OF(OPENSSL_STRING) *sigopts,
char *serialfile, int create,
- int days, int clrext, CONF *conf, char *section,
+ int minutes, int clrext, CONF *conf, char *section,
ASN1_INTEGER *sno)
{
int ret=0;
@@ -1191,7 +1216,7 @@
goto end;
/* hardwired expired */
- if (X509_time_adj_ex(X509_get_notAfter(x),days, 0, NULL) == NULL)
+ if (X509_gmtime_adj(X509_get_notAfter(x),(long)60*minutes) == NULL)
goto end;
if (clrext)
@@ -1251,7 +1276,7 @@
}
/* self sign */
-static int sign(X509 *x, EVP_PKEY *pkey, int days, int clrext, const
Re: [openssl.org #3451] patch for x509.c
Hi Richard,
On 15/07/14 10:56, Richard Levitte via RT wrote:
I do like the idea, and definitely see the need for this.
A nit pick, though '-valid' as a option name is a bit confusing, I'd
personally expect it to take a full blown time argument -- something like
DDD-HH:MM -- and not just hours and minutes. Maybe '-time' or something like
that. That or actually have '-valid' take the full blown argument (thereby
replacing '-days' in the long run).
thanks for picking this up; the name '-valid' as well as the format
HH:MM came from the Globus Toolkit 'grid-proxy-init' command, which
uses the same syntax. I agree that the name might be a bit confusing. If
I understand you correctly you're suggesting to use
-valid DDD-HH:MM
(I'm using '-valid' here for lack of a better name right now) where
anything before the hyphen is the number of days, and anything after it
is the time in HH:MM format? It should be possible to specify HH 24,
and we could also support MM 60 (e.g -valid 0-0:1440 == -valid 0-24:00
== -valid 1-0:00 == -days 1)
but then the syntax
-valid 0-24:00
seems confusing as well ... or we could use logic as follows:
if arg contains hyphen then anything before it is #days, anything after
it is time in HH:MM format
if arg contains no hyphen and no colon then it's the number of days
if arg contains no hyphen but it does contain a colon then #days = 0 and
the entire argument is a time in HH:MM format
suggestions?
JJK / Jan Just Keijser
Nikhef
Amsterdam
On Sun Jul 13 20:13:28 2014, janj...@nikhef.nl wrote:
hi ,
attached is a minor patch to apps/x509.c. The patch allows the user to
specify the validity of a certificate in hours and minutes (next to
days). This is esp useful when creating grid/RFC3820 proxies which
typically have a duration of 12 hours.
regards,
JJK / Jan Just Keijser
--- openssl-1.0.1c/apps/x509.c 2011-10-10 01:13:46.0 +0200
+++ openssl-1.0.1c-jjk/apps/x509.c 2012-08-09 09:17:37.783134860 +0200
@@ -128,6 +128,7 @@
-addreject arg - reject certificate for a given purpose\n,
-setalias arg - set certificate alias\n,
-days arg - How long till expiry of a signed certificate -
def 30 days\n,
+ -valid HH:MM - How long till expiry of a signed certificate\n,
-checkend arg - check whether the cert expires in the next arg
seconds\n,
exit 1 if so, 0 if not\n,
-signkey arg - self sign cert with arg\n,
@@ -154,12 +155,12 @@
};
static int MS_CALLBACK callb(int ok, X509_STORE_CTX *ctx);
-static int sign (X509 *x, EVP_PKEY *pkey,int days,int clrext, const
EVP_MD *digest,
+static int sign (X509 *x, EVP_PKEY *pkey,int minutes,int clrext,
const EVP_MD *digest,
CONF *conf, char *section);
static int x509_certify (X509_STORE *ctx,char *CAfile,const EVP_MD
*digest,
X509 *x,X509 *xca,EVP_PKEY *pkey,
STACK_OF(OPENSSL_STRING) *sigopts,
- char *serial, int create ,int days, int clrext,
+ char *serial, int create ,int minutes, int clrext,
CONF *conf, char *section, ASN1_INTEGER *sno);
static int purpose_print(BIO *bio, X509 *cert, X509_PURPOSE *pt);
static int reqfile=0;
@@ -194,7 +195,7 @@
int ocsp_uri=0;
int trustout=0,clrtrust=0,clrreject=0,aliasout=0,clrext=0;
int C=0;
- int x509req=0,days=DEF_DAYS,modulus=0,pubkey=0;
+ int x509req=0,days=DEF_DAYS,minutes=0,modulus=0,pubkey=0;
int pprint = 0;
const char **pp;
X509_STORE *ctx=NULL;
@@ -292,6 +293,26 @@
goto bad;
}
}
+ else if (strcmp(*argv,-valid) == 0)
+ {
+ if (--argc 1) goto bad;
+
+ char *delim = strchr(*(++argv), ':');
+ if (delim)
+ {
+ *delim = '\0';
+ delim++;
+ minutes = atoi( delim );
+ }
+ int hours = atoi( *argv );
+ minutes = 60 * hours + minutes;
+
+ if (minutes == 0)
+ {
+ BIO_printf(STDout,bad -valid specification\n);
+ goto bad;
+ }
+ }
else if (strcmp(*argv,-passin) == 0)
{
if (--argc 1) goto bad;
@@ -511,6 +532,10 @@
goto end;
}
+ if (minutes == 0)
+ {
+ minutes = 24*60*days;
+ }
if (!X509_STORE_set_default_paths(ctx))
{
ERR_print_errors(bio_err);
@@ -964,7 +989,7 @@
}
assert(need_rand);
- if (!sign(x,Upkey,days,clrext,digest,
+ if (!sign(x,Upkey,minutes,clrext,digest,
extconf, extsect)) goto end;
}
else if (CA_flag == i)
@@ -982,7 +1007,7 @@
assert(need_rand);
if (!x509_certify(ctx,CAfile,digest,x,xca,
CApkey, sigopts,
- CAserial,CA_createserial,days, clrext,
+ CAserial,CA_createserial,minutes, clrext,
extconf, extsect, sno))
goto end;
}
@@ -1148,7 +1173,7 @@
X509 *x, X509 *xca, EVP_PKEY *pkey,
STACK_OF(OPENSSL_STRING) *sigopts,
char *serialfile, int create,
- int days, int clrext, CONF *conf, char *section,
+ int minutes, int clrext, CONF *conf, char *section,
ASN1_INTEGER *sno)
{
int ret=0;
@@ -1191,7 +1216,7 @@
goto end;
/* hardwired expired */
- if (X509_time_adj_ex(X509_get_notAfter(x),days, 0, NULL) == NULL)
+ if (X509_gmtime_adj(X509_get_notAfter(x),(long)60*minutes) == NULL)
goto end
Re: [openssl.org #3451] patch for x509.c
On 15/07/14 15:20, Daniel Kahn Gillmor wrote: On 07/15/2014 07:58 AM, Salz, Rich via RT wrote: The Globus syntax is strange. :) We should support the ISO date/time standard, and use that throughout and not invent yet another syntax, or yet another flag. It's fairly simple to parse, and handles timezones, relative times, date/time mixing, and so on. The XML XSD spec, for example, has a reasonable explanation. Agreed here. also, the presence of a hyphen in a time marker is too easily misunderstood as a minus sign. If we're talking about the duration of a certificate, we could use something like the ISO-8601 duration syntax: https://en.wikipedia.org/wiki/ISO-8601#Durations e.g. PT1800S is 1800 seconds I like the idea, but I won't have time to rewrite the patch right now. Implementing full ISO8061 timestamps will take some effort. I'd also propose to rename '-valid' to '-duration' . I'll get back on this in mid August. cheers, JJK / Jan Just Keijser Nikhef Amsterdam __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3451] patch for x509.c
hi ,
attached is a minor patch to apps/x509.c. The patch allows the user to
specify the validity of a certificate in hours and minutes (next to
days). This is esp useful when creating grid/RFC3820 proxies which
typically have a duration of 12 hours.
regards,
JJK / Jan Just Keijser
--- openssl-1.0.1c/apps/x509.c 2011-10-10 01:13:46.0 +0200
+++ openssl-1.0.1c-jjk/apps/x509.c 2012-08-09 09:17:37.783134860 +0200
@@ -128,6 +128,7 @@
-addreject arg - reject certificate for a given purpose\n,
-setalias arg - set certificate alias\n,
-days arg - How long till expiry of a signed certificate - def 30
days\n,
+ -valid HH:MM- How long till expiry of a signed certificate\n,
-checkend arg - check whether the cert expires in the next arg seconds\n,
exit 1 if so, 0 if not\n,
-signkey arg- self sign cert with arg\n,
@@ -154,12 +155,12 @@
};
static int MS_CALLBACK callb(int ok, X509_STORE_CTX *ctx);
-static int sign (X509 *x, EVP_PKEY *pkey,int days,int clrext, const EVP_MD
*digest,
+static int sign (X509 *x, EVP_PKEY *pkey,int minutes,int clrext, const EVP_MD
*digest,
CONF *conf, char *section);
static int x509_certify (X509_STORE *ctx,char *CAfile,const EVP_MD *digest,
X509 *x,X509 *xca,EVP_PKEY *pkey,
STACK_OF(OPENSSL_STRING) *sigopts,
-char *serial, int create ,int days, int clrext,
+char *serial, int create ,int minutes, int clrext,
CONF *conf, char *section, ASN1_INTEGER *sno);
static int purpose_print(BIO *bio, X509 *cert, X509_PURPOSE *pt);
static int reqfile=0;
@@ -194,7 +195,7 @@
int ocsp_uri=0;
int trustout=0,clrtrust=0,clrreject=0,aliasout=0,clrext=0;
int C=0;
- int x509req=0,days=DEF_DAYS,modulus=0,pubkey=0;
+ int x509req=0,days=DEF_DAYS,minutes=0,modulus=0,pubkey=0;
int pprint = 0;
const char **pp;
X509_STORE *ctx=NULL;
@@ -292,6 +293,26 @@
goto bad;
}
}
+ else if (strcmp(*argv,-valid) == 0)
+ {
+ if (--argc 1) goto bad;
+
+ char *delim = strchr(*(++argv), ':');
+ if (delim)
+ {
+ *delim = '\0';
+ delim++;
+ minutes = atoi( delim );
+ }
+ int hours = atoi( *argv );
+ minutes = 60 * hours + minutes;
+
+ if (minutes == 0)
+ {
+ BIO_printf(STDout,bad -valid specification\n);
+ goto bad;
+ }
+ }
else if (strcmp(*argv,-passin) == 0)
{
if (--argc 1) goto bad;
@@ -511,6 +532,10 @@
goto end;
}
+ if (minutes == 0)
+ {
+ minutes = 24*60*days;
+ }
if (!X509_STORE_set_default_paths(ctx))
{
ERR_print_errors(bio_err);
@@ -964,7 +989,7 @@
}
assert(need_rand);
- if (!sign(x,Upkey,days,clrext,digest,
+ if (!sign(x,Upkey,minutes,clrext,digest,
extconf, extsect)) goto end;
}
else if (CA_flag == i)
@@ -982,7 +1007,7 @@
assert(need_rand);
if (!x509_certify(ctx,CAfile,digest,x,xca,
CApkey, sigopts,
- CAserial,CA_createserial,days, clrext,
+ CAserial,CA_createserial,minutes,
clrext,
extconf, extsect, sno))
goto end;
}
@@ -1148,7 +1173,7 @@
X509 *x, X509 *xca, EVP_PKEY *pkey,
STACK_OF(OPENSSL_STRING) *sigopts,
char *serialfile, int create,
- int days, int clrext, CONF *conf, char *section,
+ int minutes, int clrext, CONF *conf, char *section,
ASN1_INTEGER *sno)
{
int ret=0;
@@ -1191,7 +1216,7 @@
goto end;
/* hardwired expired */
- if (X509_time_adj_ex(X509_get_notAfter(x),days, 0, NULL) == NULL)
+ if (X509_gmtime_adj
patch for x509.c
hi ,
attached is a minor patch to apps/x509.c. The patch allows the user to
specify the validity of a certificate in hours and minutes (next to
days). This is esp useful when creating grid/RFC3820 proxies which
typically have a duration of 12 hours.
regards,
JJK / Jan Just Keijser
--- openssl-1.0.1c/apps/x509.c 2011-10-10 01:13:46.0 +0200
+++ openssl-1.0.1c-jjk/apps/x509.c 2012-08-09 09:17:37.783134860 +0200
@@ -128,6 +128,7 @@
-addreject arg - reject certificate for a given purpose\n,
-setalias arg - set certificate alias\n,
-days arg - How long till expiry of a signed certificate - def 30 days\n,
+ -valid HH:MM- How long till expiry of a signed certificate\n,
-checkend arg - check whether the cert expires in the next arg seconds\n,
exit 1 if so, 0 if not\n,
-signkey arg- self sign cert with arg\n,
@@ -154,12 +155,12 @@
};
static int MS_CALLBACK callb(int ok, X509_STORE_CTX *ctx);
-static int sign (X509 *x, EVP_PKEY *pkey,int days,int clrext, const EVP_MD *digest,
+static int sign (X509 *x, EVP_PKEY *pkey,int minutes,int clrext, const EVP_MD *digest,
CONF *conf, char *section);
static int x509_certify (X509_STORE *ctx,char *CAfile,const EVP_MD *digest,
X509 *x,X509 *xca,EVP_PKEY *pkey,
STACK_OF(OPENSSL_STRING) *sigopts,
- char *serial, int create ,int days, int clrext,
+ char *serial, int create ,int minutes, int clrext,
CONF *conf, char *section, ASN1_INTEGER *sno);
static int purpose_print(BIO *bio, X509 *cert, X509_PURPOSE *pt);
static int reqfile=0;
@@ -194,7 +195,7 @@
int ocsp_uri=0;
int trustout=0,clrtrust=0,clrreject=0,aliasout=0,clrext=0;
int C=0;
- int x509req=0,days=DEF_DAYS,modulus=0,pubkey=0;
+ int x509req=0,days=DEF_DAYS,minutes=0,modulus=0,pubkey=0;
int pprint = 0;
const char **pp;
X509_STORE *ctx=NULL;
@@ -292,6 +293,26 @@
goto bad;
}
}
+ else if (strcmp(*argv,-valid) == 0)
+ {
+ if (--argc 1) goto bad;
+
+ char *delim = strchr(*(++argv), ':');
+ if (delim)
+{
+*delim = '\0';
+delim++;
+minutes = atoi( delim );
+ }
+ int hours = atoi( *argv );
+ minutes = 60 * hours + minutes;
+
+ if (minutes == 0)
+{
+BIO_printf(STDout,bad -valid specification\n);
+goto bad;
+}
+ }
else if (strcmp(*argv,-passin) == 0)
{
if (--argc 1) goto bad;
@@ -511,6 +532,10 @@
goto end;
}
+ if (minutes == 0)
+ {
+ minutes = 24*60*days;
+ }
if (!X509_STORE_set_default_paths(ctx))
{
ERR_print_errors(bio_err);
@@ -964,7 +989,7 @@
}
assert(need_rand);
-if (!sign(x,Upkey,days,clrext,digest,
+if (!sign(x,Upkey,minutes,clrext,digest,
extconf, extsect)) goto end;
}
else if (CA_flag == i)
@@ -982,7 +1007,7 @@
assert(need_rand);
if (!x509_certify(ctx,CAfile,digest,x,xca,
CApkey, sigopts,
- CAserial,CA_createserial,days, clrext,
+ CAserial,CA_createserial,minutes, clrext,
extconf, extsect, sno))
goto end;
}
@@ -1148,7 +1173,7 @@
X509 *x, X509 *xca, EVP_PKEY *pkey,
STACK_OF(OPENSSL_STRING) *sigopts,
char *serialfile, int create,
- int days, int clrext, CONF *conf, char *section,
+ int minutes, int clrext, CONF *conf, char *section,
ASN1_INTEGER *sno)
{
int ret=0;
@@ -1191,7 +1216,7 @@
goto end;
/* hardwired expired */
- if (X509_time_adj_ex(X509_get_notAfter(x),days, 0, NULL) == NULL)
+ if (X509_gmtime_adj(X509_get_notAfter(x),(long)60*minutes) == NULL)
goto end;
if (clrext)
@@ -1251,7 +1276,7 @@
}
/* self sign */
-static int sign(X509 *x, EVP_PKEY *pkey, int days, int clrext, const EVP_MD *digest,
+static int sign(X509 *x, EVP_PKEY *pkey, int minutes, int clrext, const EVP_MD *digest,
CONF *conf, char *section)
{
@@ -1269,7 +1294,7 @@
/* memcpy(x-cert_info-validity-notBefore,70010112Z,13); */
/* 28 days to be certified */
- if (X509_gmtime_adj(X509_get_notAfter(x),(long)60*60*24*days) == NULL)
+ if (X509_gmtime_adj(X509_get_notAfter(x),(long)60*minutes) == NULL)
goto err;
if (!X509_set_pubkey(x,pkey)) goto err;
Re: Upgrading OpenSSL on RHEL5
On 24/04/14 01:46, Peter Waltenberg wrote: rpm -q --changelog openssl | grep CVE AFAIU RedHat backports CVE's to the version of openssl included in RHEL5 (0.9.8e) FWIW: this is the changelog from a Scientific Linux 5 box: rpm -q --changelog openssl | grep CVE - fix for CVE-2013-0169 - SSL/TLS CBC timing attack (#907589) - fix for CVE-2013-0166 - DoS in OCSP signatures checking (#908052) environment variable is set (fixes CVE-2012-4929 #857051) - fix for CVE-2012-2333 - improper checking for record length in DTLS (#820686) - fix for CVE-2012-2110 - memory corruption in asn1_d2i_read_bio() (#814185) - fix for CVE-2012-0884 - MMA weakness in CMS and PKCS#7 code (#802725) - fix for CVE-2012-1165 - NULL read dereference on bad MIME headers (#802489) - fix for CVE-2011-4108 CVE-2012-0050 - DTLS plaintext recovery - fix for CVE-2011-4109 - double free in policy checks (#771771) - fix for CVE-2011-4576 - uninitialized SSL 3.0 padding (#771775) - fix for CVE-2011-4619 - SGC restart DoS attack (#771780) - fix CVE-2010-4180 - completely disable code for - fix CVE-2009-3245 - add missing bn_wexpand return checks (#570924) - fix CVE-2010-0433 - do not pass NULL princ to krb5_kt_get_entry which - fix CVE-2009-3555 - support the safe renegotiation extension and - fix CVE-2009-2409 - drop MD2 algorithm from EVP tables (#510197) - fix CVE-2009-4355 - do not leak memory when CRYPTO_cleanup_all_ex_data() - fix CVE-2009-1386 CVE-2009-1387 (DTLS DoS problems) - fix CVE-2009-1377 CVE-2009-1378 CVE-2009-1379 - fix CVE-2009-0590 - reject incorrectly encoded ASN.1 strings (#492304) - fix CVE-2008-5077 - incorrect checks for malformed signatures (#476671) - fix CVE-2007-3108 - side channel attack on private keys (#250581) - fix CVE-2007-5135 - off-by-one in SSL_get_shared_ciphers (#309881) - fix CVE-2007-4995 - out of order DTLS fragments buffer overflow (#321221) - CVE-2006-2940 fix was incorrect (#208744) - fix CVE-2006-2937 - mishandled error on ASN.1 parsing (#207276) - fix CVE-2006-2940 - parasitic public keys DoS (#207274) - fix CVE-2006-3738 - buffer overflow in SSL_get_shared_ciphers (#206940) - fix CVE-2006-4343 - sslv2 client DoS (#206940) - fix CVE-2006-4339 - prevent attack on PKCS#1 v1.5 signatures (#205180) - fix for CVE-2013-0169 - SSL/TLS CBC timing attack (#907589) - fix for CVE-2013-0166 - DoS in OCSP signatures checking (#908052) environment variable is set (fixes CVE-2012-4929 #857051) - fix for CVE-2012-2333 - improper checking for record length in DTLS (#820686) - fix for CVE-2012-2110 - memory corruption in asn1_d2i_read_bio() (#814185) - fix for CVE-2012-0884 - MMA weakness in CMS and PKCS#7 code (#802725) - fix for CVE-2012-1165 - NULL read dereference on bad MIME headers (#802489) - fix for CVE-2011-4108 CVE-2012-0050 - DTLS plaintext recovery - fix for CVE-2011-4109 - double free in policy checks (#771771) - fix for CVE-2011-4576 - uninitialized SSL 3.0 padding (#771775) - fix for CVE-2011-4619 - SGC restart DoS attack (#771780) - fix CVE-2010-4180 - completely disable code for - fix CVE-2009-3245 - add missing bn_wexpand return checks (#570924) - fix CVE-2010-0433 - do not pass NULL princ to krb5_kt_get_entry which - fix CVE-2009-3555 - support the safe renegotiation extension and - fix CVE-2009-2409 - drop MD2 algorithm from EVP tables (#510197) - fix CVE-2009-4355 - do not leak memory when CRYPTO_cleanup_all_ex_data() - fix CVE-2009-1386 CVE-2009-1387 (DTLS DoS problems) - fix CVE-2009-1377 CVE-2009-1378 CVE-2009-1379 - fix CVE-2009-0590 - reject incorrectly encoded ASN.1 strings (#492304) - fix CVE-2008-5077 - incorrect checks for malformed signatures (#476671) - fix CVE-2007-3108 - side channel attack on private keys (#250581) - fix CVE-2007-5135 - off-by-one in SSL_get_shared_ciphers (#309881) - fix CVE-2007-4995 - out of order DTLS fragments buffer overflow (#321221) - CVE-2006-2940 fix was incorrect (#208744) - fix CVE-2006-2937 - mishandled error on ASN.1 parsing (#207276) - fix CVE-2006-2940 - parasitic public keys DoS (#207274) - fix CVE-2006-3738 - buffer overflow in SSL_get_shared_ciphers (#206940) - fix CVE-2006-4343 - sslv2 client DoS (#206940) - fix CVE-2006-4339 - prevent attack on PKCS#1 v1.5 signatures (#205180) it will be very hard to upgrade to a newer version of openssl (1.0? I'd say forget it) , as many packages depend on either openssl, libssl.so.6 and or libcrypto.so.6 (don't ask me where the 6 came from). The best you could achieve is to download the latest 0.9.8 release, build an RPM for that based on the RHEL5 spec file and try to upgrade your openssl library that way. HTH, JJK __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Openssl generating 1024 bit keys when default_bits is set to 4096 bit
Hi Ralf, Ralf Skyper Kaiser wrote: Hi, OpenSSL 1.0.1e 11 Feb 2013 $ grep bits openssl.cnf default_bits= 4096 = Note that the default_bits are set to 4096. $ openssl req -config openssl.cnf -nodes -newkey rsa -keyout testkey.pem -keyform PEM -out testreq.pem -outform PEM Generating a 4096 bit RSA private key ..++ ...++ writing new private key to 'testkey.pem' = Note that Openssl tells us that it is generating a 4096 bit key. $ openssl rsa -text testkey.pem | less | grep Key Private-Key: (1024 bit) = ...but openssl generated a 1024 bit key instead. (The workaround is to force openssl with -newkey rsa:4096.) Two concerns: 1. Openssl should create a 4096 bit key if the default setting is 4096 bit. 2. Openssl should not show that a 4096 bit key is generated and then generate something much weaker. the output of the command you gave is indeed confusing, but if you use $ openssl req -config openssl.cnf -nodes -new -keyout testkey.pem -keyform PEM -out testreq.pem to generate the key+request the correct value *is* picked up from the openssl.cnf file. I don't yet understand why the 'req' command does pick up the setting from the openssl.cnf file yet it generates the private key using the default key size. HTH, JJK __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Using Windows certificate store through OpenSSL
Perrow, Graeme wrote: I'd like to add the ability for my (client) application to use the Windows certificate store to verify a server's certificate during an SSL handshake. I've created a callback and set it using SSL_CTX_set_verify( ctx, SSL_VERIFY_PEER, mycallback ). Inside that callback, I can retrieve information about the server's certificate and can also enumerate through the certificates in the certificate store. But then what? Is there a way to tell OpenSSL Please verify the server's certificate using this trusted certificate? In the case when the client supplies the trusted certificate in advance, I can pass it to X509_STORE_add_cert before the handshake but can I do that *during* the handshake? Can I simply get the PEM / DER information for both certificates and memcpy them? wasn't support for this added via the crypto engine 'capieng' ? Rebuild openssl using ./config enable-capieng and use the CAPI engine. HTH, JJK
Re: CPU Software Engine
Hi, Costas Stasimos wrote: Hi Jan By applying the cryptodev patch in openssl, all the applications that use openssl (postfix, tomcat etc) are automatically executed at hardware. As far as it concerns the openssl speed, we can avoid the hardware acceleration by using the evp parameter. My wonder is how we can avoid the hardware acceleration from application side? Is there an engine name that we can use to run the application at software? the fact that 'openssl engine -t' shows an engine as available does not mean that it is automagically *used*; on my openssl 1.0.1e build I see 'rsax' and 'gost' as available engines but I am quite certain that they are not used unless I specify them on the command line OR if I load them in my code using something like ENGINE_load_builtin_engines(); HTH, JJK 2013/3/22 Jan Just Keijser janj...@nikhef.nl mailto:janj...@nikhef.nl Hi Costas, Costas Stasimos wrote: Hello! I'm currently using the cryptodev framework-engine with openssl-1.0.1e. By run the command # openssl engine -t (cryptodev) cryptodev engine [ available ] (dynamic) Dynamic engine loading support [ unavailable ] we can see that the cryptodev is the active-chosen engine. So it seems that all the cryptographic load is directed automatically to /dev/crypto via the cryptodev engine. My question is, how i can use the CPU instead of cryptodev, or with other words how i can disable the cryptodev from application level? Is there an engine id-name in order to change the activated cryptodev engine and send the execution to the Software-CPU? AFAIK the cryptodev engine won't be used unless you actually specify it on the command line, e.g. openssl speed -engine cryptodev -evp etc.
Re: CPU Software Engine
Hi Costas, Costas Stasimos wrote: Hello! I'm currently using the cryptodev framework-engine with openssl-1.0.1e. By run the command # openssl engine -t (cryptodev) cryptodev engine [ available ] (dynamic) Dynamic engine loading support [ unavailable ] we can see that the cryptodev is the active-chosen engine. So it seems that all the cryptographic load is directed automatically to /dev/crypto via the cryptodev engine. My question is, how i can use the CPU instead of cryptodev, or with other words how i can disable the cryptodev from application level? Is there an engine id-name in order to change the activated cryptodev engine and send the execution to the Software-CPU? AFAIK the cryptodev engine won't be used unless you actually specify it on the command line, e.g. openssl speed -engine cryptodev -evp etc. HTH, JJK
Re: Use TLS over UDP connection
Hi, saurav barik wrote: Hello, I am trying to implement TLS security (in the client side) over a UDP connection. I have a parallel TCP connection(to the same server) over which TLS is already done and it works fine. In the same session of my application I am creating a UDP connection to the same server (UDP socket) and am trying to do a TLS handshake. When I call SSL_connect() over UDP connection, it fails with SSL_ERROR_SYSCALL error. When I checked the error with ERR_get_error() I get a value of 0. Can I use TLS over a UDP connection(I understand DTLS can be used but my project needs TLS)? Please share some pointers. Thanks for your time. read the openvpn source code http://swupdate.openvpn.org/community/releases/openvpn-2.3.0.tar.gz the control channel is implemented using TLS over UDP (with a few extra's). HTH, JJK __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: SHA-256 implementation improvement
Andy Polyakov wrote: Now I agree ;) 1.8 version is best-balanced for all architectures. I'm not sure I agree: I've grabbed the 1.8 version and rebuilt openssl 1.0.1c and tested it on an i5 i5 says exactly nothing, please don't use it. Say Nehalem, Sandy Bridge, whatever, but not i5! and a Core 2 Duo; performance is better than the non-patched version but it is WORSE compared to the original version of the sha256-586.pl script that was posted here before on May 11th. version 11/05/2015: sha256 39017.64k87648.54k 150106.58k 183705.94k 197330.99k version 1.8: sha256 33560.42k73153.83k 121472.43k 167948.67k 180955.23k It sounds like we're talking about Nehalem, as it's very close to difference reported by Pavel: i5 Lynnfield 1250 / 1426 / 1271 / 1121 / 1033 more results: i5-560M (Arrandale): no patch 34040.33k74466.07k 124345.23k 152376.03k 162949.09k patch 11/05 38922.49k88027.86k 151124.68k 184797.07k 197566.93k patch-1.833525.23k73799.17k 122710.39k 169429.19k 182747.58k Core2 E6550 (Conroe): no patch 23735.61k54419.78k93057.45k 115254.61k 123923.11k patch 11/05 27216.54k63764.33k 112310.44k 138860.54k 148624.73k patch-1.824118.46k55799.57k96415.49k 137738.58k 149411.16k Xeon X5660 (Westmere-EP): no patch 30288.81k69069.08k 117933.40k 145430.53k 155427.55k patch 11/05 34431.21k80946.11k 142910.72k 176818.18k 189199.82k patch-1.829587.88k67710.55k 116092.16k 161652.39k 173996.99k Xeon E5440 (Harpertown): no patch 29626.31k67556.19k 115481.26k 142789.83k 153533.32k patch 11/05 33937.95k78971.79k 138890.72k 172167.74k 184211.14k patch-1.829645.14k68659.05k 119742.60k 169329.66k 183457.25k For all 4 platforms the 11/5/2012 patch was the fastest. I don't have an Atom based box to test it on. share and enjoy, JJK / Jan Just Keijser
Re: SHA-256 implementation improvement
Hi, Pavel Semjanov wrote: As for Sandy Bridge. I don't know... I could observe nominal variations, 2-3%, on my machine, but nothing close to 10%, so this is odd... If you have energy, test with varying stack seed(*)... It was my error, because I measured it in special application. It doesn't know about OPENSSL_ia32cap_P and goes on non-shrd path. The right numbers are 1005 for small loop and 971 for unrolled one. 971 is the best value I've ever seen! Great work! Come on, apart from your Sandy Bridge result for 1.8, it's virtually equivalent. Nominal difference can be explained by environmental factors, and if not, it's really low price to pay for 40% improvement on Atom. Besides, it's actually slow architectures that need optimization more :-) Now I agree ;) 1.8 version is best-balanced for all architectures. I'm not sure I agree: I've grabbed the 1.8 version and rebuilt openssl 1.0.1c and tested it on an i5 and a Core 2 Duo; performance is better than the non-patched version but it is WORSE compared to the original version of the sha256-586.pl script that was posted here before on May 11th. version 11/05/2015: sha256 39017.64k87648.54k 150106.58k 183705.94k 197330.99k version 1.8: sha256 33560.42k73153.83k 121472.43k 167948.67k 180955.23k all my tests were done using 'openssl speed sha256' , I'm unsure how you did your testing. cheers, JJK / Jan Just Keijser __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: SHA-256 implementation improvement
Jan Just Keijser wrote: Andy Polyakov wrote: I modified the 'Configure' script to allow the compilation of a 32bit version of openssl *with* the assembly routines. What does it mean? Configure supports 32-bit builds *with* assembly as it is. To build 32-bit version on 64-bit Linux, run './Configure linux-elf -m32'. ah, I did not know about that option - I was looking for a specific ./Configure target ... The results for this version are on various Intel CPUs Core2 E6550 (Conroe): 22 - 32 % speed up Xeon E5440 (Harpertown): 24 - 33% speed up Xeon X5660 (Westmere-EP): 19 - 27% speed up i5-560M (Arrandale): 18 - 23 % speed up What are the ranges? If we assume that largest coefficient is for largest block size, then these are too high. What is the base line exactly? Is it possible that you compare to compiler-generated code? here are the raw 'openssl speed sha256' results with and without the patch; all I did was tar xzf openssl-1.0.0j.tar.gz cd openssl-1.0.0j.tar.gz apply patch or not ./Configure linux-elf -m32 make cd apps ./openssl speed -evp sha256 | grep ^sha ./openssl speed sha256 | grep ^sha This result is on a Core2duo T9300 laptop: no patch: sha256-evp1572142178 84527113902127184 sha2562685158249 97794119593127668 patch: sha256-evp 1817851411108741150649169099 sha25634380 76627130753159497171054 116% 122% 129% 132% 133% 128% 132% 134% 133% 134% arrrgh, the output got mangled on my first post: here's a second attempt: no patch: sha256-evp1572142178 84527113902127184 sha2562685158249 97794119593127668 patch: sha256-evp1817851411108741150649169099 sha2563438076627130753159497171054 116% 122% 129% 132% 133% 128% 132% 134% 133% 134% JJK __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: SHA-256 implementation improvement
Hi Pavel, Pavel Semjanov wrote: Hello again, as I promised, here is the optimized code for SHA-256 hash, x86 platform. Should work faster on Core 2/iX up to 20%. This code you are free to use (or modify) in any form on OpenSSL and GRYPTOGAMS. I guess you should make it PIC, as any other code for x86 (I didn't make it because I don't need it in my projects). FWIW: I've grabbed this .pl file , downloaded openssl 1.0.0j and compared the performance of 'openssl speed sha256' with and without the patch; initially I found *NO* noticable performance difference on any of the 64bit machines I tested . Then it occurred to me that the patch was for the 32bit version only (the file sha512-x86_64.pl also covers sha256); I modified the 'Configure' script to allow the compilation of a 32bit version of openssl *with* the assembly routines. The results for this version are on various Intel CPUs Core2 E6550 (Conroe): 22 - 32 % speed up Xeon E5440 (Harpertown): 24 - 33% speed up Xeon X5660 (Westmere-EP): 19 - 27% speed up i5-560M (Arrandale): 18 - 23 % speed up Note that for the i5-560M the unpatched 64bit version still outperforms the patched 32bit version How can the sha256 patch be applied to the 64bit code base? cheers, JJK / Jan Just Keijser __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
question about ecdh functions
hello list, we're trying to add ECDH/ECDSA support to OpenVPN and we have run into a question we cannot easily answer ourselves: we're using SSL_CTX_set_tmp_ecdh to add an ECDH curve to your server-side SSL CTX object; this is very similar to the DH parameters which are added using SSL_CTX_set_tmp_dh. We do *not* add a 'set_tmp_dh_callback' to the server SSL CTX , as the DH parameter file is static. The question is: does the same apply to the SSL_CTX_set_tmp_ecdh/SSL_CTX_set_tmp_ecdh_callback function? Or do we need to add callbacks , similar to the way RSA callbacks are added, as done in the s_server.c code? A more general question is where we can read up on all this :) ? many thanks in advance, JJK / Jan Just Keijser __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
small openssl x509 patch for short lived certificates/proxies
hi all,
attached is a small patch to x509.c to allow short lived certificates
(proxies) to be generated. Currently the 'openssl x509' command only
support 1-day certificates (or n days, where n is an integer). With
this patch it is possible to specify the certificate validity in minutes
and hours e.g.
openssl x509 -valid 4:00
We use this patch to x509 to generate grid proxies from an Aladdin
eToken, using the openssl engine support.
regards,
Jan Just Keijser
System Integrator
Nikhef
Amsterdam
--- openssl-0.9.8d/apps/x509.c 2005-07-16 13:13:03.0 +0200
+++ openssl-0.9.8d-jjk/apps/x509.c 2007-05-24 13:19:11.0 +0200
@@ -121,6 +121,7 @@
-addreject arg - reject certificate for a given purpose\n,
-setalias arg - set certificate alias\n,
-days arg - How long till expiry of a signed certificate - def
30 days\n,
+ -valid HH:MM- How long till expiry of a signed certificate\n,
-checkend arg - check whether the cert expires in the next arg
seconds\n,
exit 1 if so, 0 if not\n,
-signkey arg- self sign cert with arg\n,
@@ -147,11 +148,11 @@
};
static int MS_CALLBACK callb(int ok, X509_STORE_CTX *ctx);
-static int sign (X509 *x, EVP_PKEY *pkey,int days,int clrext, const
EVP_MD *digest,
+static int sign (X509 *x, EVP_PKEY *pkey,int minutes,int clrext, const
EVP_MD *digest,
CONF *conf, char *section);
static int x509_certify (X509_STORE *ctx,char *CAfile,const EVP_MD *digest,
X509 *x,X509 *xca,EVP_PKEY *pkey,char *serial,
-int create,int days, int clrext, CONF *conf,
char *section,
+int create,int minutes, int clrext, CONF *conf,
char *section,
ASN1_INTEGER *sno);
static int purpose_print(BIO *bio, X509 *cert, X509_PURPOSE *pt);
static int reqfile=0;
@@ -181,7 +182,7 @@
int noout=0,sign_flag=0,CA_flag=0,CA_createserial=0,email=0;
int trustout=0,clrtrust=0,clrreject=0,aliasout=0,clrext=0;
int C=0;
- int x509req=0,days=DEF_DAYS,modulus=0,pubkey=0;
+ int x509req=0,days=DEF_DAYS,minutes=0,modulus=0,pubkey=0;
int pprint = 0;
const char **pp;
X509_STORE *ctx=NULL;
@@ -270,6 +271,26 @@
goto bad;
}
}
+ else if (strcmp(*argv,-valid) == 0)
+ {
+ if (--argc 1) goto bad;
+
+ char *delim = strchr(*(++argv), ':');
+ if (delim)
+ {
+ *delim = '\0';
+ delim++;
+ minutes = atoi( delim );
+ }
+ int hours = atoi( *argv );
+ minutes = 60 * hours + minutes;
+
+ if (minutes == 0)
+ {
+ BIO_printf(STDout,bad -valid
specification\n);
+ goto bad;
+ }
+ }
else if (strcmp(*argv,-passin) == 0)
{
if (--argc 1) goto bad;
@@ -479,6 +500,10 @@
goto end;
}
+ if (minutes == 0)
+ {
+ minutes = 24*60*days;
+ }
if (!X509_STORE_set_default_paths(ctx))
{
ERR_print_errors(bio_err);
@@ -622,7 +647,7 @@
if (!X509_set_subject_name(x,req-req_info-subject))
goto end;
X509_gmtime_adj(X509_get_notBefore(x),0);
- X509_gmtime_adj(X509_get_notAfter(x),(long)60*60*24*days);
+ X509_gmtime_adj(X509_get_notAfter(x),(long)60*minutes);
pkey = X509_REQ_get_pubkey(req);
X509_set_pubkey(x,pkey);
@@ -922,7 +947,7 @@
#endif
assert(need_rand);
- if (!sign(x,Upkey,days,clrext,digest,
+ if (!sign(x,Upkey,minutes,clrext,digest,
extconf, extsect)) goto
end;
}
else if (CA_flag == i)
@@ -947,7 +972,7 @@
assert(need_rand);
if (!x509_certify(ctx,CAfile,digest,x,xca,
- CApkey,
CAserial,CA_createserial,days, clrext,
+ CApkey,
CAserial,CA_createserial,minutes, clrext,
extconf, extsect, sno))
goto end;
}
@@ -1119,7 +1144,7 @@
static int x509_certify(X509_STORE *ctx, char *CAfile, const EVP_MD
*digest,
X509 *x, X509 *xca, EVP_PKEY *pkey, char
