From norm.green at gemtalksystems.com Thu Mar 1 00:46:38 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Wed, 28 Feb 2018 16:46:38 -0800 Subject: [openssl-users] OpenSSL 1.1.1pre2 alpha build error: MS Windows 32 bit Message-ID: <542fe65d-dc91-573b-b831-4049e6283863@gemtalksystems.com> It looks like 32 bit builds set the -WX flag (treat warnings as errors) while the 64 bit builds don't. ??????? cl? -W3 -wd4090 -Gs0 -GF -Gy -nologo /MDd /Od -WX /Zi /Fdossl_static /I "." /I "crypto\include" /I "include" /I "crypto\ec\curve448\arch_32" /I "crypto\ec\curve448" -DDSO_WIN32 -DOPENSSL_SYS_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -D_WINSOCK_DEPRECATED_NO_WARNINGS -DUNICODE -D_UNICODE -DDEBUG -D_DEBUG -DOPENSSL_USE_APPLINK -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM "-DOPENSSLDIR=\"C:\\Program Files (x86)\\Common Files\\SSL\"" "-DENGINESDIR=\"C:\\checkouts\\install11\\lib\\engines-1_1\"" -c /Focrypto\ec\curve448\f_generic.obj @C:\cygwin64\tmp\nmA13D.tmp f_generic.c crypto\ec\curve448\f_generic.c(125) : error C2220: warning treated as error - no 'object' file generated crypto\ec\curve448\f_generic.c(125) : warning C4244: 'function' : conversion from 'dsword_t' to 'uint32_t', possible loss of data crypto\ec\curve448\f_generic.c(125) : warning C4244: 'function' : conversion from 'dsword_t' to 'uint32_t', possible loss of data crypto\ec\curve448\f_generic.c(138) : warning C4244: 'function' : conversion from 'dword_t' to 'uint32_t', possible loss of data NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\cl.EXE"' : return code '0x2' Stop. NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\nmake.exe"' : return code '0x2' Stop. perl configdata.pm --dump Use of uninitialized value $prefix in concatenation (.) or string at configdata.pm line 15114. Use of uninitialized value $prefix in concatenation (.) or string at configdata.pm line 15114. Use of uninitialized value $prefix in concatenation (.) or string at configdata.pm line 15114. Use of uninitialized value $prefix in concatenation (.) or string at configdata.pm line 15114. Use of uninitialized value $prefix in concatenation (.) or string at configdata.pm line 15114. Use of uninitialized value $prefix in concatenation (.) or string at configdata.pm line 15114. Use of uninitialized value $prefix in concatenation (.) or string at configdata.pm line 15114. Use of uninitialized value $prefix in concatenation (.) or string at configdata.pm line 15114. Command line (with current working directory = .): ??? C:\Perl64\bin\perl.exe Configure --prefix=C:\checkouts\install11 debug-VC-WIN32 Perl information: ??? C:\Perl64\bin\perl.exe ??? 5.24.0 for MSWin32-x64-multi-thread Enabled features: ??? aria ??? asm ??? async ??? autoalginit ??? autoerrinit ??? bf ??? blake2 ??? camellia ??? capieng ??? cast ??? chacha ??? cmac ??? cms ??? comp ??? ct ??? deprecated ??? des ??? dgram ??? dh ??? dsa ??? dso ??? dtls ??? dynamic-engine ??? ec ??? ec2m ??? ecdh ??? ecdsa ??? engine ??? err ??? filenames ??? gost ??? hw(-.+)? ??? idea ??? makedepend ??? md4 ??? mdc2 ??? multiblock ??? nextprotoneg ??? ocb ??? ocsp ??? pic ??? poly1305 ??? posix-io ??? psk ??? rc2 ??? rc4 ??? rdrand ??? rfc3779 ??? rmd160 ??? scrypt ??? seed ??? shared ??? siphash ??? sm3 ??? sm4 ??? sock ??? srp ??? srtp ??? sse2 ??? ssl ??? static-engine ??? stdio ??? tests ??? threads ??? tls ??? ts ??? ui-console ??? whirlpool ??? tls1 ??? tls1-method ??? tls1_1 ??? tls1_1-method ??? tls1_2 ??? tls1_2-method ??? tls1_3 ??? dtls1 ??? dtls1-method ??? dtls1_2 ??? dtls1_2-method Disabled features: ??? afalgeng??????????????? [not-linux] ??? asan??????????????????? [default]?? OPENSSL_NO_ASAN ??? crypto-mdebug?????????? [default] OPENSSL_NO_CRYPTO_MDEBUG ??? crypto-mdebug-backtrace [default] OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE ??? devcryptoeng??????????? [default] OPENSSL_NO_DEVCRYPTOENG ??? ec_nistp_64_gcc_128???? [default] OPENSSL_NO_EC_NISTP_64_GCC_128 ??? egd???????????????????? [default]?? OPENSSL_NO_EGD ??? external-tests????????? [default] OPENSSL_NO_EXTERNAL_TESTS ??? fuzz-libfuzzer????????? [default] OPENSSL_NO_FUZZ_LIBFUZZER ??? fuzz-afl??????????????? [default]?? OPENSSL_NO_FUZZ_AFL ??? heartbeats????????????? [default] OPENSSL_NO_HEARTBEATS ??? md2???????????????????? [default]?? OPENSSL_NO_MD2 (skip crypto\md2) ??? msan??????????????????? [default]?? OPENSSL_NO_MSAN ??? rc5???????????????????? [default]?? OPENSSL_NO_RC5 (skip crypto\rc5) ??? sctp??????????????????? [default]?? OPENSSL_NO_SCTP ??? ssl-trace?????????????? [default] OPENSSL_NO_SSL_TRACE ??? tls13downgrade????????? [default] OPENSSL_NO_TLS13DOWNGRADE ??? ubsan?????????????????? [default]?? OPENSSL_NO_UBSAN ??? unit-test?????????????? [default] OPENSSL_NO_UNIT_TEST ??? weak-ssl-ciphers??????? [default] OPENSSL_NO_WEAK_SSL_CIPHERS ??? zlib??????????????????? [default] ??? zlib-dynamic??????????? [default] ??? ssl3??????????????????? [default]?? OPENSSL_NO_SSL3 ??? ssl3-method???????????? [default] OPENSSL_NO_SSL3_METHOD Config target attributes: ??? aes_asm_src => "aes-586.s vpaes-x86.s aesni-x86.s", ??? aes_obj => "aes-586.o vpaes-x86.o aesni-x86.o", ??? apps_aux_src => "win32_init.c", ??? apps_init_src => "../ms/applink.c", ??? apps_obj => "win32_init.o", ??? ar => "lib", ??? arflags => "/nologo", ??? aroutflag => "/out:", ??? as => "nasm", ??? asflags => "-f win32", ??? asoutflag => "-o", ??? bf_asm_src => "bf-586.s", ??? bf_obj => "bf-586.o", ??? bin_cflags => "/Zi /Fdapp /MDd", ??? bin_lflags => "/subsystem:console /opt:ref", ??? bn_asm_src => "bn-586.s co-586.s x86-mont.s x86-gf2m.s", ??? bn_obj => "bn-586.o co-586.o x86-mont.o x86-gf2m.o", ??? bn_ops => "BN_LLONG EXPORT_VAR_AS_FN", ??? build_file => "makefile", ??? build_scheme => [ "unified", "windows", "VC-W32" ], ??? cast_asm_src => "c_enc.c", ??? cast_obj => "c_enc.o", ??? cc => "cl", ??? cflags => "-W3 -wd4090 -Gs0 -GF -Gy -nologo /MDd /Od -WX", ??? chacha_asm_src => "chacha-x86.s", ??? chacha_obj => "chacha-x86.o", ??? cmll_asm_src => "cmll-x86.s", ??? cmll_obj => "cmll-x86.o", ??? coutflag => "/Fo", ??? cpp => "\$(CC) /EP /C", ??? cppflags => "", ??? cpuid_asm_src => "x86cpuid.s", ??? cpuid_obj => "x86cpuid.o", ??? defines => [ "DSO_WIN32", "OPENSSL_SYS_WIN32", "WIN32_LEAN_AND_MEAN", "L_ENDIAN", "_CRT_SECURE_NO_DEPRECATE", "_WINSOCK_DEPRECATED_NO_WARNINGS", "UNICODE", "_UNICODE", "DEBUG", "_DEBUG", "OPENSSL_USE_APPLINK", "OPENSSL_NO_STATIC_ENGINE", "OPENSSL_PIC", "OPENSSL_CPUID_OBJ", "OPENSSL_BN_ASM_PART_WORDS", "OPENSSL_IA32_SSE2", "OPENSSL_BN_ASM_MONT", "OPENSSL_BN_ASM_GF2m", "SHA1_ASM", "SHA256_ASM", "SHA512_ASM", "RC4_ASM", "MD5_ASM", "RMD160_ASM", "AES_ASM", "VPAES_ASM", "WHIRLPOOL_ASM", "GHASH_ASM", "ECP_NISTZ256_ASM", "PADLOCK_ASM", "POLY1305_ASM" ], ??? des_asm_src => "des-586.s crypt586.s", ??? des_obj => "des-586.o crypt586.o", ??? disable => [? ], ??? dso_cflags => "/Zi /Fddso", ??? dso_cxxflags => "", ??? dso_extension => "", ??? dso_lflags => "/dll", ??? dso_scheme => "WIN32", ??? ec_asm_src => "ecp_nistz256.c ecp_nistz256-x86.s", ??? ec_obj => "ecp_nistz256.o ecp_nistz256-x86.o", ??? enable => [? ], ??? ex_libs => "ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib", ??? exe_extension => "", ??? hashbangperl => "/usr/bin/env perl", ??? includes => [? ], ??? ld => "link", ??? lflags => "/nologo /debug", ??? lib_cflags => "/Zi /Fdossl_static", ??? loutflag => "/out:", ??? md5_asm_src => "md5-586.s", ??? md5_obj => "md5-586.o", ??? modes_asm_src => "ghash-x86.s", ??? modes_obj => "ghash-x86.o", ??? mt => "mt", ??? mtflags => "-nologo", ??? mtinflag => "-manifest ", ??? mtoutflag => "-outputresource:", ??? padlock_asm_src => "e_padlock-x86.s", ??? padlock_obj => "e_padlock-x86.o", ??? perlasm_scheme => "win32n", ??? poly1305_asm_src => "poly1305-x86.s", ??? poly1305_obj => "poly1305-x86.o", ??? ranlib => "CODE(0x48e7f0)", ??? rc => "rc", ??? rc4_asm_src => "rc4-586.s", ??? rc4_obj => "rc4-586.o", ??? rc5_asm_src => "rc5-586.s", ??? rc5_obj => "rc5-586.o", ??? rcoutflag => "/fo", ??? rmd160_asm_src => "rmd-586.s", ??? rmd160_obj => "rmd-586.o", ??? sha1_asm_src => "sha1-586.s sha256-586.s sha512-586.s", ??? sha1_obj => "sha1-586.o sha256-586.o sha512-586.o", ??? shared_cflag => "", ??? shared_defines => [? ], ??? shared_extension => "", ??? shared_extension_simple => "", ??? shared_ldflag => "/dll", ??? shared_rcflag => "", ??? shared_target => "win-shared", ?? sys_id => "WIN32", ??? thread_defines => [? ], ??? thread_scheme => "winthreads", ??? unistd => "", ??? uplink_aux_src => "../ms/uplink.c", ??? uplink_obj => "../ms/uplink.o", ??? wp_asm_src => "wp_block.c wp-mmx.s", ??? wp_obj => "wp_block.o wp-mmx.o", Recorded environment: ??? AR = ??? ARFLAGS = ??? AS = ??? ASFLAGS = ??? BUILDFILE = ??? CC = cl ??? CFLAGS = ??? CPP = ??? CPPDEFINES = ??? CPPFLAGS = ??? CPPINCLUDES = ??? CROSS_COMPILE = ??? CXX = ??? CXXFLAGS = ??? HASHBANGPERL = ??? LD = link ??? LDFLAGS = ??? LDLIBS = ??? MT = ??? MTFLAGS = ??? OPENSSL_LOCAL_CONFIG_DIR = ??? PERL = perl ??? RANLIB = ??? RC = ??? RCFLAGS = ??? RM = ??? WINDRES = Makevars: ??? AR????????????? = lib ??? ARFLAGS???????? = /nologo ??? AS????????????? = nasm ??? ASFLAGS???????? = -f win32 ??? CC????????????? = cl ??? CFLAGS????????? = -W3 -wd4090 -Gs0 -GF -Gy -nologo /MDd /Od -WX ??? CPP???????????? = $(CC) /EP /C ??? CPPDEFINES????? = DSO_WIN32 OPENSSL_SYS_WIN32 WIN32_LEAN_AND_MEAN L_ENDIAN _CRT_SECURE_NO_DEPRECATE _WINSOCK_DEPRECATED_NO_WARNINGS UNICODE _UNICODE DEBUG _DEBUG OPENSSL_USE_APPLINK OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_CPUID_OBJ OPENSSL_BN_ASM_PART_WORDS OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM RC4_ASM MD5_ASM RMD160_ASM AES_ASM VPAES_ASM WHIRLPOOL_ASM GHASH_ASM ECP_NISTZ256_ASM PADLOCK_ASM POLY1305_ASM ??? CPPFLAGS??????? = ??? CPPINCLUDES???? = ?? CXXFLAGS??????? = ??? HASHBANGPERL??? = perl ??? LD????????????? = link ??? LDFLAGS???????? = /nologo /debug ??? LDLIBS????????? = ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib ??? MT????????????? = mt ??? MTFLAGS???????? = -nologo ??? RANLIB????????? = ranlib ??? RC????????????? = rc NOTE: These variables only represent the configuration view.? The build file template may have processed these variables further, please have a look at the build file for more exact data: ??? makefile build file: ??? makefile build file templates: ??? Configurations\windows-makefile.tmpl ??? Configurations\common.tmpl From guru at unixarea.de Thu Mar 1 12:07:46 2018 From: guru at unixarea.de (Matthias Apitz) Date: Thu, 1 Mar 2018 13:07:46 +0100 Subject: [openssl-users] compiling cups-1.4.3 w/ OpenSSL 1.10 && BIO_METHOD Message-ID: <20180301120746.GA5829@sh4-5.1blu.de> Hello, Compiling cups-1.4.3 against OpenSSL 1.10 gives the following error: ... Compiling http.c... http.c:216: error: variable `http_bio_methods' has initializer but incomplete type the code in question is: #if defined(HAVE_SSL) && defined(HAVE_LIBSSL) /* * BIO methods for OpenSSL... */ static int http_bio_write(BIO *h, const char *buf, int num); static int http_bio_read(BIO *h, char *buf, int size); static int http_bio_puts(BIO *h, const char *str); static long http_bio_ctrl(BIO *h, int cmd, long arg1, void *arg2); static int http_bio_new(BIO *h); static int http_bio_free(BIO *data); static BIO_METHOD http_bio_methods = { BIO_TYPE_SOCKET, "http", http_bio_write, http_bio_read, http_bio_puts, NULL, /* http_bio_gets, */ http_bio_ctrl, http_bio_new, http_bio_free, NULL, }; Can I fix this somehow within the cups' code? Thanks matthias -- Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/ ? +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From appro at openssl.org Thu Mar 1 12:27:17 2018 From: appro at openssl.org (Andy Polyakov) Date: Thu, 1 Mar 2018 13:27:17 +0100 Subject: [openssl-users] OpenSSL 1.1.1pre2 alpha build error: MS Windows 32 bit In-Reply-To: <542fe65d-dc91-573b-b831-4049e6283863@gemtalksystems.com> References: <542fe65d-dc91-573b-b831-4049e6283863@gemtalksystems.com> Message-ID: <43540d7c-7f6a-1a7a-8c2d-2fb46d94ef4f@openssl.org> On 03/01/18 01:46, Norm Green wrote: > It looks like 32 bit builds set the -WX flag (treat warnings as errors) > while the 64 bit builds don't. > > > ??????? cl? -W3 -wd4090 -Gs0 -GF -Gy -nologo /MDd /Od -WX /Zi > /Fdossl_static /I "." /I "crypto\include" /I "include" /I > "crypto\ec\curve448\arch_32" /I "crypto\ec\curve448" -DDSO_WIN32 > -DOPENSSL_SYS_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN > -D_CRT_SECURE_NO_DEPRECATE -D_WINSOCK_DEPRECATED_NO_WARNINGS -DUNICODE > -D_UNICODE -DDEBUG -D_DEBUG -DOPENSSL_USE_APPLINK > -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ > -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT > -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM > -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM > -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM > "-DOPENSSLDIR=\"C:\\Program Files (x86)\\Common Files\\SSL\"" > "-DENGINESDIR=\"C:\\checkouts\\install11\\lib\\engines-1_1\"" -c > /Focrypto\ec\curve448\f_generic.obj @C:\cygwin64\tmp\nmA13D.tmp > f_generic.c > crypto\ec\curve448\f_generic.c(125) : error C2220: warning treated as > error - no 'object' file generated > crypto\ec\curve448\f_generic.c(125) : warning C4244: 'function' : > conversion from 'dsword_t' to 'uint32_t', possible loss of data > crypto\ec\curve448\f_generic.c(125) : warning C4244: 'function' : > conversion from 'dsword_t' to 'uint32_t', possible loss of data > crypto\ec\curve448\f_generic.c(138) : warning C4244: 'function' : > conversion from 'dword_t' to 'uint32_t', possible loss of data > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual > Studio 10.0\VC\bin\cl.EXE"' : return code '0x2' > Stop. > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual > Studio 10.0\VC\bin\nmake.exe"' : return code '0x2' > Stop. Hmmm... Appveyor CI doesn't have problems with it, but of course it ought to be newer version. Newer than 10.0 that is, judging from reference C:\Program Files (x86)\Microsoft Visual Studio 10.0\ above. And I can't reproduce it with 10.0... Oh wait! It's actually specific to --debug build! I mean it might happen that it's not version-specific... From rsalz at akamai.com Thu Mar 1 13:01:04 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 1 Mar 2018 13:01:04 +0000 Subject: [openssl-users] compiling cups-1.4.3 w/ OpenSSL 1.10 && BIO_METHOD In-Reply-To: <20180301120746.GA5829@sh4-5.1blu.de> References: <20180301120746.GA5829@sh4-5.1blu.de> Message-ID: <6E00C4D7-EB40-4C58-B703-8CC76590AD0F@akamai.com> Yes, you will have to create the BIO object at run-time and use the settor methods. From norm.green at gemtalksystems.com Thu Mar 1 19:34:36 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Thu, 1 Mar 2018 11:34:36 -0800 Subject: [openssl-users] OpenSSL 1.1.1pre2 alpha build error: MS Windows 32 bit In-Reply-To: <43540d7c-7f6a-1a7a-8c2d-2fb46d94ef4f@openssl.org> References: <542fe65d-dc91-573b-b831-4049e6283863@gemtalksystems.com> <43540d7c-7f6a-1a7a-8c2d-2fb46d94ef4f@openssl.org> Message-ID: <9756e862-b974-0ad3-b1ae-8416e317bf08@gemtalksystems.com> SSL version-specific?? SSL 1.1.0 builds clean on the same machine.... I'm wondering if the solution is code changes or On 3/1/18 04:27, Andy Polyakov wrote: > I mean it might happen that it's not version-specific... From Zeke.Evans at microfocus.com Thu Mar 1 23:28:09 2018 From: Zeke.Evans at microfocus.com (Zeke Evans) Date: Thu, 1 Mar 2018 23:28:09 +0000 Subject: [openssl-users] FIPS 140-2 key wrapping transition In-Reply-To: References: Message-ID: I am trying to understand how validation #1747 is affected by the key wrapping transition. As far as I can tell, the FIPS module does not contain a key wrapping algorithm per se but only provides approved methods that a key wrapping algorithm could use. Does FIPS 2.0 contain approved methods in order to implement a key wrapping algorithm compliant with SP 800-38f? Is FIPS_evp_des_ede3_cbc not sufficient? If not, why would the absence of that push validation #1747 to the Historical list? I am not seeing a claim the key wrapping is covered in validation #1747 or any code inside the module that implements something that is now deprecated. Is it at all possible to implement a compliant key wrapping method in the FIPS capable code using approved methods? I realize if this was possible it probably would have been done already. I am just hoping to understand the issues surrounding this. Thanks for your help! Zeke Evans Senior Software Engineer Micro Focus From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich via openssl-users Sent: Friday, February 02, 2018 5:26 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] FIPS 140-2 key wrapping transition The OpenSSL FIPS Validation #1747 is affected by the key wrapping transition and will therefore be moved to Historical at some point. As we?ve said, FIPS will be the focus of our next feature release after 1.1.1 (TLS 1.3). -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe at felipegasper.com Fri Mar 2 03:39:30 2018 From: felipe at felipegasper.com (Felipe Gasper) Date: Thu, 1 Mar 2018 22:39:30 -0500 Subject: [openssl-users] renegotiate across exec() Message-ID: Hi all, I?ve got a project where I?m trying to send a Hello Request from the server immediately before an exec(), then renegotiate the SSL connection. What is the easiest way to send *just* a Hello Request from a server? Thanks! -Felipe Gasper Mississauga, Ontario From openssl-users at dukhovni.org Fri Mar 2 05:44:31 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 2 Mar 2018 00:44:31 -0500 Subject: [openssl-users] renegotiate across exec() In-Reply-To: References: Message-ID: <492D52A4-7FFF-412B-8780-E70CACB27810@dukhovni.org> > On Mar 1, 2018, at 10:39 PM, Felipe Gasper wrote: > > Hi all, > > I?ve got a project where I?m trying to send a Hello Request from the server immediately before an exec(), then renegotiate the SSL connection. > > What is the easiest way to send *just* a Hello Request from a server? You actually have a more severe problem. The session is already established and so the renegotiation must happen over an already encrypted channel. But there's no API to export the cryptographic state for use in the new executable. I believe you're out of luck. I believe that OpenSSL does not support migration of live connections between address spaces. -- Viktor. From jb-openssl at wisemo.com Fri Mar 2 07:44:50 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 2 Mar 2018 08:44:50 +0100 Subject: [openssl-users] renegotiate across exec() In-Reply-To: <492D52A4-7FFF-412B-8780-E70CACB27810@dukhovni.org> References: <492D52A4-7FFF-412B-8780-E70CACB27810@dukhovni.org> Message-ID: <4c5848d8-756f-3dd6-8774-e3414a155ddc@wisemo.com> On 02/03/2018 06:44, Viktor Dukhovni wrote: > >> On Mar 1, 2018, at 10:39 PM, Felipe Gasper wrote: >> >> Hi all, >> >> I?ve got a project where I?m trying to send a Hello Request from the server immediately before an exec(), then renegotiate the SSL connection. >> >> What is the easiest way to send *just* a Hello Request from a server? > You actually have a more severe problem. The session is already established > and so the renegotiation must happen over an already encrypted channel. But > there's no API to export the cryptographic state for use in the new executable. > > I believe you're out of luck. I believe that OpenSSL does not support migration > of live connections between address spaces. > One workaround could be to do a fork()/exec(), then have the exec-ed address space talk to the un-forked() parent address space in order to get the renegotiation encrypted with the previously negotiated keys. Another option could be to do a fork()/exec() with the parent process maintaining full control of the SSL/TLS encryption, passing the plaintext data to/from the child via pipes.? Perhaps the parent process (or other piped process) could be a special process dedicated to doing encryption/decryption, thus completely shielding the keys (long term and short term) from any vulnerabilities in the data handling process. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From matt at openssl.org Fri Mar 2 09:40:08 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 2 Mar 2018 09:40:08 +0000 Subject: [openssl-users] compiling cups-1.4.3 w/ OpenSSL 1.10 && BIO_METHOD In-Reply-To: <20180301120746.GA5829@sh4-5.1blu.de> References: <20180301120746.GA5829@sh4-5.1blu.de> Message-ID: <8ef9112a-344a-59f2-0402-6cdb8130e438@openssl.org> On 01/03/18 12:07, Matthias Apitz wrote: > > Hello, > > Compiling cups-1.4.3 against OpenSSL 1.10 gives the following error: > > ... > Compiling http.c... > http.c:216: error: variable `http_bio_methods' has initializer but > incomplete type > > the code in question is: > > #if defined(HAVE_SSL) && defined(HAVE_LIBSSL) > /* > * BIO methods for OpenSSL... > */ > > static int http_bio_write(BIO *h, const char *buf, int num); > static int http_bio_read(BIO *h, char *buf, int size); > static int http_bio_puts(BIO *h, const char *str); > static long http_bio_ctrl(BIO *h, int cmd, long arg1, void *arg2); > static int http_bio_new(BIO *h); > static int http_bio_free(BIO *data); > > static BIO_METHOD http_bio_methods = > { > BIO_TYPE_SOCKET, > "http", > http_bio_write, > http_bio_read, > http_bio_puts, > NULL, /* http_bio_gets, */ > http_bio_ctrl, > http_bio_new, > http_bio_free, > NULL, > }; > > Can I fix this somehow within the cups' code? > Thanks Yes, construct the BIO_METHOD at run time using the functions here: https://www.openssl.org/docs/man1.1.0/crypto/BIO_meth_new.html Matt From Marcus.Schafheutle at gmx.de Fri Mar 2 11:48:35 2018 From: Marcus.Schafheutle at gmx.de (Marcus.Schafheutle at gmx.de) Date: Fri, 2 Mar 2018 12:48:35 +0100 Subject: [openssl-users] Assertion in ssl_free_wbio_buffer() fails after unfinished handshake since OpenSSL 1.1.0 Message-ID: An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Mar 2 11:54:54 2018 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 2 Mar 2018 11:54:54 +0000 Subject: [openssl-users] renegotiate across exec() In-Reply-To: <492D52A4-7FFF-412B-8780-E70CACB27810@dukhovni.org> References: <492D52A4-7FFF-412B-8780-E70CACB27810@dukhovni.org> Message-ID: > I believe you're out of luck. I believe that OpenSSL does not support migration of live connections between address spaces. Yeah, the closest you can come is using TLS sessions or tickets. From ccampetto at sogei.it Fri Mar 2 14:49:33 2018 From: ccampetto at sogei.it (CAMPETTO CLAUDIO) Date: Fri, 2 Mar 2018 14:49:33 +0000 Subject: [openssl-users] openssl verify command doesn't work Message-ID: <88EE2699A9396045B08CCE0E622AC56516315BF3@SIA-MBXHAC02.domus.ad.sogei.it> >>>>openssl version openssl 1.0.2k-fips >>>>man verify VERIFY(1) OpenSSL VERIFY(1) NAME verify - Utility to verify certificates. SYNOPSIS openssl verify [-CApath directory] [-CAfile file] [-trusted_first] [-purpose purpose] [-policy arg] [-ignore_critical] [-attime timestamp] [-check_ss_sig] [-crlfile file] [-crl_download] [-crl_check] [-crl_check_all] [-policy_check] [-explicit_policy] [-inhibit_any] [-inhibit_map] [-x509_strict] [-extended_crl] [-use_deltas] [-policy_print] [-no_alt_chains] [-allow_proxy_certs] [-untrusted file] [-help] [-issuer_checks] [-trusted file] [-verbose] [-] [certificates] >>>>openssl verify -CAfile CATest2.cacert.pem -crl_check -crlfile CATest2.crl.pem testrinnovo1_nuovo.pem usage: verify [-verbose] [-CApath path] [-CAfile file] [-trusted_first] [-purpose purpose] [-crl_check] [-no_alt_chains] [-attime timestamp] [-engine e] cert1 cert2 ... It seems a lot of options are missing... ________________________________ Le informazioni contenute in questo messaggio di posta elettronica sono da considerarsi riservate e confidenziali. Il loro utilizzo ? consentito esclusivamente al destinatario in indirizzo e ne ? vietata la diffusione in qualunque modo eseguita, salvo che ne sia data espressa autorizzazione dal mittente. Nel caso in cui il messaggio Le fosse pervenuto per errore, La invitiamo gentilmente ad eliminarlo in modo permanente dopo averne dato tempestiva comunicazione al mittente e a non utilizzare in alcun caso il suo contenuto. Qualsivoglia utilizzo non autorizzato di questo messaggio e dei suoi eventuali allegati espone il responsabile alle relative conseguenze civili e penali. This communication is confidential and the use of the contained information is allowed solely for the intended recipient. Its disclosure, distribution or copying is prohibited, unless expressly authorized by the sender. If you receive this communication by mistake please notify us and delete the message and its attachments. Anyone responsible for the unauthorized use of this message and its attachments is liable to face legal consequences. From felipe at felipegasper.com Fri Mar 2 15:24:59 2018 From: felipe at felipegasper.com (Felipe Gasper) Date: Fri, 2 Mar 2018 10:24:59 -0500 Subject: [openssl-users] renegotiate across exec() In-Reply-To: <492D52A4-7FFF-412B-8780-E70CACB27810@dukhovni.org> References: <492D52A4-7FFF-412B-8780-E70CACB27810@dukhovni.org> Message-ID: > On Mar 2, 2018, at 12:44 AM, Viktor Dukhovni wrote: > >> On Mar 1, 2018, at 10:39 PM, Felipe Gasper wrote: >> >> Hi all, >> >> I?ve got a project where I?m trying to send a Hello Request from the server immediately before an exec(), then renegotiate the SSL connection. >> >> What is the easiest way to send *just* a Hello Request from a server? > > You actually have a more severe problem. The session is already established > and so the renegotiation must happen over an already encrypted channel. But > there's no API to export the cryptographic state for use in the new executable. > > I believe you're out of luck. I believe that OpenSSL does not support migration > of live connections between address spaces. Doh! Eh well. Thank you for clarifying. -Felipe From openssl-users at dukhovni.org Fri Mar 2 15:37:43 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 2 Mar 2018 10:37:43 -0500 Subject: [openssl-users] openssl verify command doesn't work In-Reply-To: <88EE2699A9396045B08CCE0E622AC56516315BF3@SIA-MBXHAC02.domus.ad.sogei.it> References: <88EE2699A9396045B08CCE0E622AC56516315BF3@SIA-MBXHAC02.domus.ad.sogei.it> Message-ID: > On Mar 2, 2018, at 9:49 AM, CAMPETTO CLAUDIO wrote: > >>>>> openssl verify -CAfile CATest2.cacert.pem -crl_check -crlfile CATest2.crl.pem testrinnovo1_nuovo.pem > > usage: verify [-verbose] [-CApath path] [-CAfile file] [-trusted_first] [-purpose purpose] [-crl_check] [-no_alt_chains] [-attime timestamp] [-engine e] cert1 cert2 ... Thanks for the report. The documentation is slated to be fixed via https://github.com/openssl/openssl/pull/5492 In the meantime, use "-CRLfile", which is the correction option name (case convention analogous to "-CAfile" and "-CApath", ...). -- Viktor. From mark at fips.pro Fri Mar 2 16:12:36 2018 From: mark at fips.pro (Mark Minnoch) Date: Fri, 2 Mar 2018 08:12:36 -0800 Subject: [openssl-users] FIPS 140-2 key wrapping transition Message-ID: <7088B87C-6CC1-4C7B-87E1-425D1ADBA96F@fips.pro> The OpenSSL FOM Cert. #1747 will not be moved to the CMVP Historical List since it does not implement a non-compliant AES key wrapping service in the defined cryptographic boundary. All of the FIPS modules that implement a non-compliant AES key wrapping service have already been moved to the Historical List. Mark J. Minnoch Co-Founder, CISSP, CISA KeyPair Consulting Inc. +1 (805) 550-3231 mobile https://KeyPair.us https://www.linkedin.com/in/minnoch We expertly guide technology companies in achieving their FIPS goals -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From ccampetto at sogei.it Fri Mar 2 17:16:39 2018 From: ccampetto at sogei.it (CAMPETTO CLAUDIO) Date: Fri, 2 Mar 2018 17:16:39 +0000 Subject: [openssl-users] R: openssl verify command doesn't work In-Reply-To: References: <88EE2699A9396045B08CCE0E622AC56516315BF3@SIA-MBXHAC02.domus.ad.sogei.it> Message-ID: <88EE2699A9396045B08CCE0E622AC56516315C84@SIA-MBXHAC02.domus.ad.sogei.it> Thanks -----Messaggio originale----- Da: openssl-users [mailto:openssl-users-bounces at openssl.org] Per conto di Viktor Dukhovni Inviato: venerd? 2 marzo 2018 16:38 A: openssl-users at openssl.org Oggetto: Re: [openssl-users] openssl verify command doesn't work > On Mar 2, 2018, at 9:49 AM, CAMPETTO CLAUDIO wrote: > >>>>> openssl verify -CAfile CATest2.cacert.pem -crl_check -crlfile >>>>> CATest2.crl.pem testrinnovo1_nuovo.pem > > usage: verify [-verbose] [-CApath path] [-CAfile file] [-trusted_first] [-purpose purpose] [-crl_check] [-no_alt_chains] [-attime timestamp] [-engine e] cert1 cert2 ... Thanks for the report. The documentation is slated to be fixed via https://github.com/openssl/openssl/pull/5492 In the meantime, use "-CRLfile", which is the correction option name (case convention analogous to "-CAfile" and "-CApath", ...). -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ________________________________ Le informazioni contenute in questo messaggio di posta elettronica sono da considerarsi riservate e confidenziali. Il loro utilizzo ? consentito esclusivamente al destinatario in indirizzo e ne ? vietata la diffusione in qualunque modo eseguita, salvo che ne sia data espressa autorizzazione dal mittente. Nel caso in cui il messaggio Le fosse pervenuto per errore, La invitiamo gentilmente ad eliminarlo in modo permanente dopo averne dato tempestiva comunicazione al mittente e a non utilizzare in alcun caso il suo contenuto. Qualsivoglia utilizzo non autorizzato di questo messaggio e dei suoi eventuali allegati espone il responsabile alle relative conseguenze civili e penali. This communication is confidential and the use of the contained information is allowed solely for the intended recipient. Its disclosure, distribution or copying is prohibited, unless expressly authorized by the sender. If you receive this communication by mistake please notify us and delete the message and its attachments. Anyone responsible for the unauthorized use of this message and its attachments is liable to face legal consequences. From adamkshannon at gmail.com Sun Mar 4 02:22:18 2018 From: adamkshannon at gmail.com (Adam Shannon) Date: Sat, 3 Mar 2018 18:22:18 -0800 Subject: [openssl-users] x509: recent change in Subject and Issuer printing? Message-ID: Was there a change included in the 1.1.0 series which prints names differently? I've looked, but been unable to narrow down what in specific changed. $ /usr/local/opt/openssl/bin/openssl version OpenSSL 1.0.2n 7 Dec 2017 $ /usr/local/opt/openssl/bin/openssl x509 -in thawte.pem -noout -text | grep -E 'Issuer:|Subject:' Issuer: C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA Subject: C=US, O=Thawte, Inc., CN=Thawte SSL CA $ openssl version OpenSSL 1.1.0f 25 May 2017 $ openssl x509 -in thawte.pem -noout -text | grep -E 'Issuer:|Subject:' Issuer: C = US, O = "thawte, Inc.", OU = Certification Services Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN = thawte Primary Root CA Subject: C = US, O = "Thawte, Inc.", CN = Thawte SSL CA -------------- next part -------------- An HTML attachment was scrubbed... URL: From gksalil at gmail.com Mon Mar 5 05:58:28 2018 From: gksalil at gmail.com (salil GK) Date: Mon, 5 Mar 2018 11:28:28 +0530 Subject: [openssl-users] MTLS verification fails Message-ID: Hi I am new to certificate management domain. We have a MTLS server. I am trying to debug the issues between the certificate validation between client and server. I used openssl s_client and s_server command to verify if the certificates are in good shape. But while doing so - I am getting the following error. #$ openssl s_client -cert tomcat.pem -key tomcat_priv.pem -CAfile ca.pem -connect lrc1.cisco.com:8446 ----- #$ openssl s_server -key privkey.pem -cert server.pem -accept 8446 -verify ca.pem verify depth is 0 Using default temp DH parameters ACCEPT depth=2 O = Cisco Systems, CN = trca-4096-sha2 verify error:num=19:self signed certificate in certificate chain ERROR verify error:self signed certificate in certificate chain 140011871301248:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed:s3_srvr.c:3427: shutting down SSL CONNECTION CLOSED What is the meaning of this error and how do I correct this - ? Thanks ~S -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Mar 5 06:21:01 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 5 Mar 2018 01:21:01 -0500 Subject: [openssl-users] MTLS verification fails In-Reply-To: References: Message-ID: > On Mar 5, 2018, at 12:58 AM, salil GK wrote: > > openssl s_client -cert tomcat.pem -key tomcat_priv.pem -CAfile ca.pem -connect lrc1.cisco.com:8446 > > ----- > > #$ openssl s_server -key privkey.pem -cert server.pem -accept 8446 -verify ca.pem > verify depth is 0 > Using default temp DH parameters > ACCEPT > depth=2 O = Cisco Systems, CN = trca-4096-sha2 > verify error:num=19:self signed certificate in certificate chain > ERROR > verify error:self signed certificate in certificate chain > 140011871301248:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed:s3_srvr.c:3427: > shutting down SSL > CONNECTION CLOSED > > What is the meaning of this error and how do I correct this - ? You have not specified a "-CAfile" or "-CApath" option telling "s_server" where to look for the "O = Cisco Systems, CN = trca-4096-sha2" trusted issuer CA certificate. You've also incorrectly specified the "-verify" option, which certainly does not help. https://www.openssl.org/docs/man1.0.2/apps/openssl-s_server.html -verify depth, -Verify depth The verify depth to use. This specifies the maximum length of the client certificate chain and makes the server request a certificate from the client. With the -verify option a certificate is requested but the client does not have to send one, with the -Verify option the client must supply a certificate or an error occurs. If the ciphersuite cannot request a client certificate (for example an anonymous ciphersuite or PSK) this option has no effect. -- Viktor. From aerowolf at gmail.com Mon Mar 5 07:12:47 2018 From: aerowolf at gmail.com (Kyle Hamilton) Date: Sun, 4 Mar 2018 23:12:47 -0800 Subject: [openssl-users] MTLS verification fails In-Reply-To: References: Message-ID: > #$ openssl s_server -key privkey.pem -cert server.pem -accept 8446 -verify ca.pem Change the '-verify' to '-CAfile' and it might work. -Kyle H On Sun, Mar 4, 2018 at 9:58 PM, salil GK wrote: > > #$ openssl s_client -cert tomcat.pem -key tomcat_priv.pem -CAfile > ca.pem -connect lrc1.cisco.com:8446 > From matt at openssl.org Mon Mar 5 09:07:32 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 5 Mar 2018 09:07:32 +0000 Subject: [openssl-users] x509: recent change in Subject and Issuer printing? In-Reply-To: References: Message-ID: On 04/03/18 02:22, Adam Shannon wrote: > Was there a change included in the 1.1.0 series which prints names > differently? I've looked, but been unable to narrow down what in > specific changed. This was changed by commit f1cece554d. The default "nameopt" setting for the x509 app (and a few others) changed from "compat" to "oneline". See the man page here for descriptions of these options: https://www.openssl.org/docs/man1.1.0/apps/x509.html If you add "-nameopt compat" to your 1.1.0 command line you should see the old behaviour. Matt > > $ /usr/local/opt/openssl/bin/openssl version > OpenSSL 1.0.2n? 7 Dec 2017 > > $ /usr/local/opt/openssl/bin/openssl x509 -in thawte.pem -noout -text | > grep -E 'Issuer:|Subject:' > ??????? Issuer: C=US, O=thawte, Inc., OU=Certification Services > Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte > Primary Root CA > ??????? Subject: C=US, O=Thawte, Inc., CN=Thawte SSL CA > > $ openssl version > OpenSSL 1.1.0f? 25 May 2017 > > $ openssl x509 -in thawte.pem -noout -text | grep -E 'Issuer:|Subject:' > ??????? Issuer: C = US, O = "thawte, Inc.", OU = Certification Services > Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN = > thawte Primary Root CA > ??????? Subject: C = US, O = "Thawte, Inc.", CN = Thawte SSL CA > > From alandean888 at gmail.com Mon Mar 5 09:46:11 2018 From: alandean888 at gmail.com (Alan Dean) Date: Mon, 5 Mar 2018 01:46:11 -0800 Subject: [openssl-users] Enable the FIPS mode in the library level Message-ID: Hi All: I am working on a project to integrate the OpenSSL FIPS capable library into our product platform. (We will be doing our own FIPS 140-2 level 1 certification) There are a large number of third party applications/ library (e.g. wget, libcurl, postfix, etc) run on our platform which use OpenSSL library, and based on the OpenSSL FIPS Library User Guide, it seems like the only way to make all these third party applications capable of running on FIPS mode will require modifying all these software to inject the FIPS_mode_set() API into the appropriate spots, so that FIPS mode can be explicitly enabled. This solution, however, may not be scalable since we would need to modify tens (if not hundreds) of different open source applications/ libraries in order to make them FIPS capable. Another potential option I am investigating is, instead of having to invoke the FIPS_mode_set API from each application, maybe (or maybe not) it's feasible to make the FIPS_mode_set API to be invoked in an entry point of the OpenSSL library so that the library itself will always be operating on FIPS mode, and in that case we won't need to inject the FIPS_mode_set API into all these third party software in order to make them FIPS capable. Of course there will be something like OpenSSH which will still require a lot of changes in order to make it able to run on FIPS mode without issue, but I will assume most of the other third party software will probably require no changes if we can enable the FIPS mode in the library level? Question 1: Is it even feasible to make the FIPS mode always enabled for the whole OpenSSL library (i.e. for both libcrypto and libssl), so that most the applications which dynamically linked to libcrypto and libssl will be automatically use OpenSSL FIPS mode without the need of changes to add the FIPS_mode_set invocation (with some exception such as OpenSSH which may still need some fixes). (Assuming from certification's perspective we are ok if we may these changes) Question 2: If the above idea is feasible, where in the OpenSSL library will be the best entry to invoke FIPS_mode_set API, so that we can make the whole OpenSSL library always in FIPS mode? Any potebtial issues for this solution? Any suggestions will be greatly appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Mon Mar 5 10:57:40 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Mon, 5 Mar 2018 11:57:40 +0100 Subject: [openssl-users] Enable the FIPS mode in the library level In-Reply-To: References: Message-ID: <2da02e99-1a62-6ee0-d147-69fb8fe0981d@ncp-e.com> On 05.03.2018 10:46, Alan Dean wrote: > Question 1: Is it even feasible to make the FIPS mode always enabled > for the whole OpenSSL library (i.e. for both libcrypto and libssl), so > that most the applications which dynamically linked to libcrypto and > libssl will be automatically use OpenSSL FIPS mode without the need of > changes to add the FIPS_mode_set invocation (with some exception such > as OpenSSH which may still need some fixes). (Assuming from > certification's perspective we are ok if we may these changes) > > > Question 2: If the above idea is feasible, where in the OpenSSL > library will be the best entry to invoke FIPS_mode_set API, so that we > can make the whole OpenSSL library always in FIPS mode? Any potebtial > issues for this solution? > > > Any suggestions will be greatly appreciated. > The optimal location for inserting the FIPS_mode_set(1) call is probably OPENSSL_init()? (openssl-1.0.2/crypto/o_fips.c), see code snippet below. void OPENSSL_init(void) { ??? static int done = 0; ??? if (done) ??????? return; ??? done = 1; #ifdef OPENSSL_FIPS ??? FIPS_set_locking_callbacks(CRYPTO_lock, CRYPTO_add_lock); # ifndef OPENSSL_NO_DEPRECATED ??? FIPS_crypto_set_id_callback(CRYPTO_thread_id); # endif ??? FIPS_set_error_callbacks(ERR_put_error, ERR_add_error_vdata); ??? FIPS_set_malloc_callbacks(CRYPTO_malloc, CRYPTO_free); ??? RAND_init_fips(); ??? FIPS_mode_set(1);?? <<< ENABLE FIPS MODE HERE <<< #endif #if 0 ??? fprintf(stderr, "Called OPENSSL_init\n"); #endif However, I am sceptical whether this approach will be accepted, because there are (at least) two potential problems: * Normally, it is mandatory to check the result of FIPS_mode_set() or FIPS_mode() to ensure that the FIPS initialization succeeded. However, an application which is not FIPS-aware won't check the result. * It can happen that applications which have their own configuration and enable/disable FIPS mode explicitely, call FIPS_mode_set(0) afterwards. HTH, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Mon Mar 5 11:04:43 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Mon, 5 Mar 2018 12:04:43 +0100 Subject: [openssl-users] Enable the FIPS mode in the library level In-Reply-To: <2da02e99-1a62-6ee0-d147-69fb8fe0981d@ncp-e.com> References: <2da02e99-1a62-6ee0-d147-69fb8fe0981d@ncp-e.com> Message-ID: <8dfc51a9-3397-e62b-ef08-1f9762c3f00b@ncp-e.com> On 05.03.2018 11:57, Dr. Matthias St. Pierre wrote: > > However, I am sceptical whether this approach will be accepted, > because there are (at least) two potential problems: > > * Normally, it is mandatory to check the result of FIPS_mode_set() or > FIPS_mode() to ensure that the FIPS initialization succeeded. However, > an application which is not FIPS-aware won't check the result. > * It can happen that applications which have their own configuration > and enable/disable FIPS mode explicitely, call FIPS_mode_set(0) > afterwards. > > > HTH, > Matthias > One more obstacle: In FIPS mode it is not allowed to use low level crypto algorithms, only the EVP interface is allowed. So most of your non-fips-aware applications will malfunction when forced into FIPS mode. The consequence is: it's probably not possible to do it. Matthias From matt at openssl.org Mon Mar 5 16:34:51 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 5 Mar 2018 16:34:51 +0000 Subject: [openssl-users] Looking for Christophe Renou Message-ID: <8096e4c7-5372-6b72-52a6-24f624f0bb7a@openssl.org> Hi all As many of you know we are looking to change the licence for OpenSSL to the Apache Licence. To do that we are trying to trace all previous committers. We have a small number of people left to find. See: https://license.openssl.org/trying-to-find Of these one stands out as being a particularly large commit. We are very keen to track down one of the authors of this commit: 57 +5105 -602 edc032b5 2011-03-12 Add SRP support. https://github.com/openssl/openssl/commit/edc032b5 If anyone can help us find Christophe that would be much appreciated. Please send any information you might have on how we can contact Christophe (or any of the other people in the above trying-to-find list) to license at openssl.org (please don't reply to this list). Thanks Matt From mcr at sandelman.ca Mon Mar 5 18:10:49 2018 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 05 Mar 2018 13:10:49 -0500 Subject: [openssl-users] Enable the FIPS mode in the library level In-Reply-To: <2da02e99-1a62-6ee0-d147-69fb8fe0981d@ncp-e.com> References: <2da02e99-1a62-6ee0-d147-69fb8fe0981d@ncp-e.com> Message-ID: <19085.1520273449@obiwan.sandelman.ca> Dr. Matthias St. Pierre wrote: > On 05.03.2018 10:46, Alan Dean wrote: >> Question 1: Is it even feasible to make the FIPS mode always enabled >> for the whole OpenSSL library (i.e. for both libcrypto and libssl), so > The optimal location for inserting the FIPS_mode_set(1) call is probably > OPENSSL_init()? (openssl-1.0.2/crypto/o_fips.c), see code snippet below. > void OPENSSL_init(void) ... > However, I am sceptical whether this approach will be accepted, because > there are (at least) two potential problems: > * Normally, it is mandatory to check the result of FIPS_mode_set() or > FIPS_mode() to ensure that the FIPS initialization succeeded. However, > an application which is not FIPS-aware won't check the result. I think that Mr. Dean should check FIPS_mode_set() in OPENSSL_Init(), and should probably do something like core dump if it fails to turn on properly. Perhaps his system has a better way to get attention. > * It can happen that applications which have their own configuration and > enable/disable FIPS mode explicitely, call FIPS_mode_set(0) afterwards. That should probably also cause a core dump. Dr. Matthias St. Pierre wrote: > One more obstacle: In FIPS mode it is not allowed to use low level > crypto algorithms, only the EVP interface is allowed. So most of your > non-fips-aware applications will malfunction when forced into FIPS mode. > The consequence is: it's probably not possible to do it. That should also cause a core dump. At the end, Mr. Dean will have a much reduced list of applications that he needs to either fix (sending patches upstream), or replace. And the core dumps will point directly into the application code that made the calls. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From alandean888 at gmail.com Mon Mar 5 18:55:02 2018 From: alandean888 at gmail.com (Alan Dean) Date: Mon, 5 Mar 2018 10:55:02 -0800 Subject: [openssl-users] Enable the FIPS mode in the library level In-Reply-To: <2da02e99-1a62-6ee0-d147-69fb8fe0981d@ncp-e.com> References: <2da02e99-1a62-6ee0-d147-69fb8fe0981d@ncp-e.com> Message-ID: Thanks a lot Matthias for the suggestion. I have few follow-up questions below: On Mon, Mar 5, 2018 at 2:57 AM, Dr. Matthias St. Pierre < Matthias.St.Pierre at ncp-e.com> wrote: > > > On 05.03.2018 10:46, Alan Dean wrote: > > Question 1: Is it even feasible to make the FIPS mode always enabled for > the whole OpenSSL library (i.e. for both libcrypto and libssl), so that > most the applications which dynamically linked to libcrypto and libssl will > be automatically use OpenSSL FIPS mode without the need of changes to add > the FIPS_mode_set invocation (with some exception such as OpenSSH which may > still need some fixes). (Assuming from certification's perspective we are > ok if we may these changes) > > > Question 2: If the above idea is feasible, where in the OpenSSL library > will be the best entry to invoke FIPS_mode_set API, so that we can make the > whole OpenSSL library always in FIPS mode? Any potebtial issues for this > solution? > > > Any suggestions will be greatly appreciated. > > > > The optimal location for inserting the FIPS_mode_set(1) call is probably > OPENSSL_init() (openssl-1.0.2/crypto/o_fips.c), see code snippet below. > > void OPENSSL_init(void) > { > static int done = 0; > if (done) > return; > done = 1; > #ifdef OPENSSL_FIPS > FIPS_set_locking_callbacks(CRYPTO_lock, CRYPTO_add_lock); > # ifndef OPENSSL_NO_DEPRECATED > FIPS_crypto_set_id_callback(CRYPTO_thread_id); > # endif > FIPS_set_error_callbacks(ERR_put_error, ERR_add_error_vdata); > FIPS_set_malloc_callbacks(CRYPTO_malloc, CRYPTO_free); > RAND_init_fips(); > FIPS_mode_set(1); <<< ENABLE FIPS MODE HERE <<< > #endif > #if 0 > fprintf(stderr, "Called OPENSSL_init\n"); > #endif > Currently OPENSSL_init() is actually invoked from within FIPS_mode_set(). If we put FIPS_mode_set() inside OPENSSL_init, then it makes OPENSSL_init to call itself recursively. In that case would it be ok to just remove OPENSSL_init from within FIPS_mode_set? > > > However, I am sceptical whether this approach will be accepted, because > there are (at least) two potential problems: > > * Normally, it is mandatory to check the result of FIPS_mode_set() or > FIPS_mode() to ensure that the FIPS initialization succeeded. However, an > application which is not FIPS-aware won't check the result. > Did you mean if FIPS_mode_set is invoked in the library level, then applications won't be checking the return results of FIPS_mode_set and could cause problem if FIPS_mode_set didn't finish successfully? > * It can happen that applications which have their own configuration and > enable/disable FIPS mode explicitely, call FIPS_mode_set(0) afterwards. > > > HTH, > Matthias > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alandean888 at gmail.com Mon Mar 5 19:02:01 2018 From: alandean888 at gmail.com (Alan Dean) Date: Mon, 5 Mar 2018 11:02:01 -0800 Subject: [openssl-users] Enable the FIPS mode in the library level In-Reply-To: <8dfc51a9-3397-e62b-ef08-1f9762c3f00b@ncp-e.com> References: <2da02e99-1a62-6ee0-d147-69fb8fe0981d@ncp-e.com> <8dfc51a9-3397-e62b-ef08-1f9762c3f00b@ncp-e.com> Message-ID: On Mon, Mar 5, 2018 at 3:04 AM, Dr. Matthias St. Pierre < Matthias.St.Pierre at ncp-e.com> wrote: > > > On 05.03.2018 11:57, Dr. Matthias St. Pierre wrote: > > > > However, I am sceptical whether this approach will be accepted, > > because there are (at least) two potential problems: > > > > * Normally, it is mandatory to check the result of FIPS_mode_set() or > > FIPS_mode() to ensure that the FIPS initialization succeeded. However, > > an application which is not FIPS-aware won't check the result. > > * It can happen that applications which have their own configuration > > and enable/disable FIPS mode explicitely, call FIPS_mode_set(0) > > afterwards. > > > > > > HTH, > > Matthias > > > > One more obstacle: In FIPS mode it is not allowed to use low level > crypto algorithms, only the EVP interface is allowed. So most of your > non-fips-aware applications will malfunction when forced into FIPS mode. > The consequence is: it's probably not possible to do it. > Did you mean if an application uses the low level crypto algorithm functions (e.g. SHA256_Init/ SHA256_Update/ SHA256_Final) then they won't work under FIPS mode (and hence may cause unpredictable issues)? > > Matthias > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Mar 5 19:07:45 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 5 Mar 2018 19:07:45 +0000 Subject: [openssl-users] Enable the FIPS mode in the library level In-Reply-To: References: <2da02e99-1a62-6ee0-d147-69fb8fe0981d@ncp-e.com> <8dfc51a9-3397-e62b-ef08-1f9762c3f00b@ncp-e.com> Message-ID: <03032CD8-B5E6-425F-BB8B-B0C5FFCB3706@akamai.com> * Did you mean if an application uses the low level crypto algorithm functions (e.g. SHA256_Init/ SHA256_Update/ SHA256_Final) then they won't work under FIPS mode (and hence may cause unpredictable issues)? Yes. It?s not unpredictable issues, but rather that your application cannot claim to be FIPS validated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Mon Mar 5 19:20:40 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Mon, 5 Mar 2018 20:20:40 +0100 Subject: [openssl-users] Enable the FIPS mode in the library level In-Reply-To: <03032CD8-B5E6-425F-BB8B-B0C5FFCB3706@akamai.com> References: <2da02e99-1a62-6ee0-d147-69fb8fe0981d@ncp-e.com> <8dfc51a9-3397-e62b-ef08-1f9762c3f00b@ncp-e.com> <03032CD8-B5E6-425F-BB8B-B0C5FFCB3706@akamai.com> Message-ID: Am 05.03.2018 um 20:07 schrieb Salz, Rich via openssl-users: > > * Did you mean if an application uses the low level crypto algorithm > functions (e.g. SHA256_Init/ SHA256_Update/ SHA256_Final) then > they won't work under FIPS mode (and hence may cause unpredictable > issues)? > > > > Yes. > > > > It?s not unpredictable issues, but rather that your application cannot > claim to be FIPS validated. > > > > > It's even worse: If you force an application which is not fips-aware into FIPS mode and that application uses low level algorithms, then it will be aborted by OpenSSL, because it is forbidden to use the low level algorithms directly. To understand how this happens, search the source code for 'fips_md_init' and 'fips_cipher_abort'. They are defined in crypto.h, see end of mail. Changing applications from the low level api is not a simple bugfix. It's a nontrivial task. So the situation is hopeless, I would say. Matthias crypto.h: ======= # define fips_md_init(alg) fips_md_init_ctx(alg, alg) # ifdef OPENSSL_FIPS # define fips_md_init_ctx(alg, cx) \ int alg##_Init(cx##_CTX *c) \ { \ if (FIPS_mode()) OpenSSLDie(__FILE__, __LINE__, \ "Low level API call to digest " #alg " forbidden in FIPS mode!"); \ return private_##alg##_Init(c); \ } \ int private_##alg##_Init(cx##_CTX *c) # define fips_cipher_abort(alg) \ if (FIPS_mode()) OpenSSLDie(__FILE__, __LINE__, \ "Low level API call to cipher " #alg " forbidden in FIPS mode!") # else # define fips_md_init_ctx(alg, cx) \ int alg##_Init(cx##_CTX *c) # define fips_cipher_abort(alg) while(0) # endif From Matthias.St.Pierre at ncp-e.com Mon Mar 5 19:21:43 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Mon, 5 Mar 2018 20:21:43 +0100 Subject: [openssl-users] Enable the FIPS mode in the library level In-Reply-To: References: <2da02e99-1a62-6ee0-d147-69fb8fe0981d@ncp-e.com> Message-ID: <2af2e0b0-b11a-f583-3f79-192259e44637@ncp-e.com> Am 05.03.2018 um 19:55 schrieb Alan Dean: > Thanks a lot Matthias for the suggestion. > > I have few follow-up questions below: > Please see my other replies. From alandean888 at gmail.com Mon Mar 5 19:39:41 2018 From: alandean888 at gmail.com (Alan Dean) Date: Mon, 5 Mar 2018 11:39:41 -0800 Subject: [openssl-users] Enable the FIPS mode in the library level In-Reply-To: <2af2e0b0-b11a-f583-3f79-192259e44637@ncp-e.com> References: <2da02e99-1a62-6ee0-d147-69fb8fe0981d@ncp-e.com> <2af2e0b0-b11a-f583-3f79-192259e44637@ncp-e.com> Message-ID: Thanks Matthias for your response. I have a different question: Per your suggestion in the previous email, FIPS_mode_set() can be moved inside of OPENSSL_init(), in order to force the FIPS mode enabled in the library level. However currently OPENSSL_init() is actually invoked from within FIPS_mode_set(). If we put FIPS_mode_set() inside OPENSSL_init, then it makes OPENSSL_init to call itself recursively. In that case would it be ok to just remove OPENSSL_init from within FIPS_mode_set? On Mon, Mar 5, 2018 at 11:21 AM, Dr. Matthias St. Pierre < Matthias.St.Pierre at ncp-e.com> wrote: > > Am 05.03.2018 um 19:55 schrieb Alan Dean: > > Thanks a lot Matthias for the suggestion. > > > > I have few follow-up questions below: > > > > Please see my other replies. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgoldman at us.ibm.com Mon Mar 5 21:51:49 2018 From: kgoldman at us.ibm.com (Ken Goldman) Date: Mon, 5 Mar 2018 16:51:49 -0500 Subject: [openssl-users] FIPS_mode_set(1) failing Message-ID: This call fails on two platforms with: fips.c(143): OpenSSL internal error, assertion failed: FATAL FIPS SELFTEST FAILURE (or line 139) The openssl installs are: OpenSSL 1.0.1e-fips 11 Feb 2013 OpenSSL 1.0.2g-fips 1 Mar 2016 Any hints? Do I have to call a self test before entering FIPS mode? From murugesh.pitchaiah at gmail.com Tue Mar 6 06:36:27 2018 From: murugesh.pitchaiah at gmail.com (murugesh pitchaiah) Date: Tue, 6 Mar 2018 12:06:27 +0530 Subject: [openssl-users] FIPS_mode_set(1) failing In-Reply-To: References: Message-ID: Hi, On invoking FIPS_mode_set(1), the self test would be run internally first. The test would be run for all modules like dsa, rsa, rng, etc. This error indicates a failure in any of these self test run. Try to view the "FIPSerr" which could show you which module's test actually failed; so you can take necessary action. Thanks, Murugesh P. On 3/6/18, Ken Goldman wrote: > This call fails on two platforms with: > > fips.c(143): OpenSSL internal error, assertion failed: FATAL FIPS > SELFTEST FAILURE > > (or line 139) > > The openssl installs are: > > OpenSSL 1.0.1e-fips 11 Feb 2013 > OpenSSL 1.0.2g-fips 1 Mar 2016 > > Any hints? Do I have to call a self test before entering FIPS mode? > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From Michael.Wojcik at microfocus.com Tue Mar 6 15:21:56 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 6 Mar 2018 15:21:56 +0000 Subject: [openssl-users] FIPS_mode_set(1) failing In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of murugesh pitchaiah > > On 3/6/18, Ken Goldman wrote: > > This call fails on two platforms with: > > > > fips.c(143): OpenSSL internal error, assertion failed: FATAL FIPS > > SELFTEST FAILURE > > On invoking FIPS_mode_set(1), the self test would be run internally > first. The test would be run for all modules like dsa, rsa, rng, etc. > This error indicates a failure in any of these self test run. Also note that the OpenSSL FIPS validations are for specific platforms. OpenSSL FIPS has not been validated on every platform that OpenSSL can be built on (that would be infeasible). The FIPS 140-2 Level 1 self-test is sensitive to build and load conditions, so it's entirely possible that it fails on some platforms where the work hasn't been done to get the FIPS container to the state where it will pass validation. At least that's my understanding; I'm not a FIPS 140 expert. In any case, if OpenSSL doesn't have an active FIPS 140-2 validation for the "two platforms" Ken mentioned, then there's not much point in getting the self-test to pass. Even in FIPS mode OpenSSL won't be FIPS-validated on that platform and products using it can't claim they have FIPS-validated cryptography. That said, I know some developers and customers want "FIPS mode" even when there is no FIPS validation, sometimes to suppress algorithms they don't want used, and sometimes just to check a tickbox. While I don't approve (FIPS 140-2 is badly outdated and ill-suited to software implementations, and a distraction from real security), this is sometimes a requirement. -- Michael Wojcik Distinguished Engineer, Micro Focus From Matthias.St.Pierre at ncp-e.com Tue Mar 6 22:24:26 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 6 Mar 2018 23:24:26 +0100 Subject: [openssl-users] Enable the FIPS mode in the library level In-Reply-To: References: <2da02e99-1a62-6ee0-d147-69fb8fe0981d@ncp-e.com> <2af2e0b0-b11a-f583-3f79-192259e44637@ncp-e.com> Message-ID: <6483e64c-e2f7-83c9-c204-9104d0a350e3@ncp-e.com> Am 05.03.2018 um 20:39 schrieb Alan Dean: > Thanks Matthias for your response. > > I have a different question: > > Per your suggestion in the previous email, FIPS_mode_set() can be > moved inside of OPENSSL_init(), in order to force the FIPS mode > enabled in the library level. > > However currently OPENSSL_init() is actually invoked from within > FIPS_mode_set(). If we put FIPS_mode_set() inside OPENSSL_init, then > it makes OPENSSL_init to call itself recursively. In that case would > it be ok to just remove OPENSSL_init from within FIPS_mode_set? > It is not a problem if OPENSSL_init() is reentered, because the 'done' flag at the beginning of the function is set on first call to prevent the body from being executed more than once. (Well, there is a potential race condition if the first call to OPENSSL_init() happens concurrently, but let's assume that on your first call to OPENSSL_init() your application is still single-threaded.) So you can put the FIPS_mode_set() call where I indicated without risking an infinite recursion. Having said that, I consider this change an interesting 'hack' if you want to see what happens, but not more. I would like to emphasize once more that it is a quite ambitious and almost impossible task to make all these third party applications you were talking about conforming to the FIPS regulations. Turning on FIPS mode is the smallest part of the problem, you have to make the entire applications conform to the FIPS rules. It's not only that you have to convert all the calls into low level algorithms to using the EVP interface. Also, you have to prevent the applications from using non-fipsed algorithms, like e.g. md5. So in many cases you will have to make deep changes to the application's logic. Matthias void OPENSSL_init(void) { static int done = 0; if (done) return; done = 1; #ifdef OPENSSL_FIPS FIPS_set_locking_callbacks(CRYPTO_lock, CRYPTO_add_lock); # ifndef OPENSSL_NO_DEPRECATED FIPS_crypto_set_id_callback(CRYPTO_thread_id); # endif FIPS_set_error_callbacks(ERR_put_error, ERR_add_error_vdata); FIPS_set_malloc_callbacks(CRYPTO_malloc, CRYPTO_free); RAND_init_fips(); FIPS_mode_set(1); <<< ENABLE FIPS MODE HERE <<< #endif #if 0 fprintf(stderr, "Called OPENSSL_init\n"); #endif } From binod_bvb at yahoo.co.in Thu Mar 8 13:14:05 2018 From: binod_bvb at yahoo.co.in (binod kumar) Date: Thu, 8 Mar 2018 13:14:05 +0000 (UTC) Subject: [openssl-users] Need help regarding openssl errror References: <432818972.10262776.1520514845313.ref@mail.yahoo.com> Message-ID: <432818972.10262776.1520514845313@mail.yahoo.com> Hello openssl users, Need you help understanding the openssl error "error:140760FC:lib(20):func(118):reason(252)".? I am using SSL server on Windows machine and am successfully able to connect and make requests to this server from other Windows machine.?But when requests are being made with same set of certificates? from Solaris amd 64 machine I am getting this error. While debugging I identified that this error is being thrown by SSL server during?SSL_accept() call. I tries searching about this error on Web but could not find meaningful answer. Please help me understand the issue and fix it or point me to the right forum where I can get answer for this. Thanks & Regards,Binod Kumar -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Mar 8 13:25:11 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 8 Mar 2018 13:25:11 +0000 Subject: [openssl-users] Need help regarding openssl errror In-Reply-To: <432818972.10262776.1520514845313@mail.yahoo.com> References: <432818972.10262776.1520514845313.ref@mail.yahoo.com> <432818972.10262776.1520514845313@mail.yahoo.com> Message-ID: <6a947844-3a0d-6f3e-6909-db16f89fd8d7@openssl.org> On 08/03/18 13:14, binod kumar via openssl-users wrote: > Hello openssl users, > > Need you help understanding the openssl error > "*error:140760FC:lib(20):func(118):reason(252)*".? I am using SSL server > on Windows machine and am successfully able to connect and make requests > to this server from other Windows machine.? > But when requests are being made with same set of certificates? from > Solaris amd 64 machine I am getting this error. > > While debugging I identified that this error is being thrown by SSL > server during?SSL_accept() call. > > I tries searching about this error on Web but could not find meaningful > answer. Please help me understand the issue and fix it or point me to > the right forum where I can get answer for this. You don't say what version of OpenSSL you are using. But I'm going to assume OpenSSL 1.0.2: $ openssl errstr 140760FC error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol So what you are getting is an "unknown protocol" error when processing the initial message from the client. This means the server received something from the client but it doesn't look like SSL/TLS. You might want to use wireshark to see what is actually being sent. Matt From wouter.verhelst at bosa.fgov.be Thu Mar 8 13:25:49 2018 From: wouter.verhelst at bosa.fgov.be (Wouter Verhelst) Date: Thu, 8 Mar 2018 14:25:49 +0100 Subject: [openssl-users] Need help regarding openssl errror In-Reply-To: <432818972.10262776.1520514845313@mail.yahoo.com> References: <432818972.10262776.1520514845313.ref@mail.yahoo.com> <432818972.10262776.1520514845313@mail.yahoo.com> Message-ID: <11f261c4-8ed9-2ee9-f1d8-a739ba9b0c3a@bosa.fgov.be> This type of error message is shown when the error strings haven't been loaded. You can fix that by way of the ERR_load_crypto_strings() call. On 08-03-18 14:14, binod kumar via openssl-users wrote: > Hello openssl users, > > Need you help understanding the openssl error > "*error:140760FC:lib(20):func(118):reason(252)*".? I am using SSL > server on Windows machine and am successfully able to connect and make > requests to this server from other Windows machine.? > But when requests are being made with same set of certificates? from > Solaris amd 64 machine I am getting this error. > > While debugging I identified that this error is being thrown by SSL > server during?SSL_accept() call. > > I tries searching about this error on Web but could not find > meaningful answer. Please help me understand the issue and fix it or > point me to the right forum where I can get answer for this. > > Thanks & Regards, > Binod Kumar > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From etc at coderhacks.com Thu Mar 8 16:25:52 2018 From: etc at coderhacks.com (etc at coderhacks.com) Date: Thu, 8 Mar 2018 17:25:52 +0100 Subject: [openssl-users] Payload-checksum in PEM? Message-ID: <89e1b770-bec1-6fde-f8fe-d87b94ab73c0@coderhacks.com> Hi! I have a verification-error in a SMIME-message and I try to check manually the checksums of the payload. Here is my strategy - but I do not know it is even possible. # openssl cms -sign -in myfile.txt -md md5 -signer cer.txt -inkey key.txt -outform PEM > pem.txt # md5sum myfile.txt Can I expect to find the md5sum checksum somewhere in the ASN1 of pem.txt??? # openssl asn1parse -in pem.txt As far I see it is not there - but maybe it is just a quick step to it? Thanks for help! Chris From openssl-users at dukhovni.org Thu Mar 8 16:31:19 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 8 Mar 2018 11:31:19 -0500 Subject: [openssl-users] Payload-checksum in PEM? In-Reply-To: <89e1b770-bec1-6fde-f8fe-d87b94ab73c0@coderhacks.com> References: <89e1b770-bec1-6fde-f8fe-d87b94ab73c0@coderhacks.com> Message-ID: > On Mar 8, 2018, at 11:25 AM, etc at coderhacks.com wrote: > > # openssl cms -sign -in myfile.txt -md md5 -signer cer.txt -inkey key.txt -outform PEM > pem.txt > > # md5sum myfile.txt > > Can I expect to find the md5sum checksum somewhere in the ASN1 of pem.txt??? > > # openssl asn1parse -in pem.txt > > As far I see it is not there - but maybe it is just a quick step to it? When signing, the checksum is part of the signature, so you'd have to decrypt the signature block with the signer's public key via: openssl rsautl -pubin -raw -encrypt -inkey pubkey.pem and find the message digest there. -- Viktor. From binod_bvb at yahoo.co.in Thu Mar 8 16:39:33 2018 From: binod_bvb at yahoo.co.in (binod kumar) Date: Thu, 8 Mar 2018 16:39:33 +0000 (UTC) Subject: [openssl-users] Need help regarding openssl errror In-Reply-To: <11f261c4-8ed9-2ee9-f1d8-a739ba9b0c3a@bosa.fgov.be> References: <432818972.10262776.1520514845313.ref@mail.yahoo.com> <432818972.10262776.1520514845313@mail.yahoo.com> <11f261c4-8ed9-2ee9-f1d8-a739ba9b0c3a@bosa.fgov.be> Message-ID: <1894870820.10324884.1520527173563@mail.yahoo.com> Thanks a lot Matt and Wouter for taking time to look in to this problem and decoding this error code for me. I will try to analyze wireshark log and find that what is causing this error. Will also try to use??ERR_load_crypto_strings() in the code. Thanks again for quick help :) . Regards,Binod Kumar On Thursday, March 8, 2018, 7:12:31 PM GMT+5:30, Wouter Verhelst wrote: This type of error message is shown when the error strings haven't been loaded. You can fix that by way of the ERR_load_crypto_strings() call. On 08-03-18 14:14, binod kumar via openssl-users wrote: Hello openssl users, Need you help understanding the openssl error "error:140760FC:lib(20):func(118):reason(252)".? I am using SSL server on Windows machine and am successfully able to connect and make requests to this server from other Windows machine.? But when requests are being made with same set of certificates? from Solaris amd 64 machine I am getting this error. While debugging I identified that this error is being thrown by SSL server during?SSL_accept() call. I tries searching about this error on Web but could not find meaningful answer. Please help me understand the issue and fix it or point me to the right forum where I can get answer for this. Thanks & Regards, Binod Kumar -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From etc at coderhacks.com Thu Mar 8 16:52:56 2018 From: etc at coderhacks.com (etc at coderhacks.com) Date: Thu, 8 Mar 2018 17:52:56 +0100 Subject: [openssl-users] Payload-checksum in PEM? In-Reply-To: References: <89e1b770-bec1-6fde-f8fe-d87b94ab73c0@coderhacks.com> Message-ID: Thanks for your help! But I am not sure I do fully understand that - not doing that every day. Please one more hint - thanks. I have a certificate (cer.txt; content is enclosed with ---BEGIN/END CERTIFICATE---). I can get the public-key out of that. (pubkey.txt; content is enclosed ---BEGIN/END PUBLIC KEY---). I have the PEM (pem.txt; content is enclosed with ---BEGIN/END CMS---). This is what I call the signature and I would expect to have a hash of my original file somewhere inside of it. If I do openssl rsautl -pubin -raw -encrypt -inkey pubkey.txt -in pem.txt I get an error (...rsa routines:RSA_padding_add_none:data too large for key size...). Am I doing something wrong or do I have the wrong ingredients? I try to find the hashvalue that any other tool gives me when hashing the original payload (myfile.txt). Thanks Chris On 2018-03-08 17:31, Viktor Dukhovni wrote: > >> On Mar 8, 2018, at 11:25 AM, etc at coderhacks.com wrote: >> >> # openssl cms -sign -in myfile.txt -md md5 -signer cer.txt -inkey key.txt -outform PEM > pem.txt >> >> # md5sum myfile.txt >> >> Can I expect to find the md5sum checksum somewhere in the ASN1 of pem.txt??? >> >> # openssl asn1parse -in pem.txt >> >> As far I see it is not there - but maybe it is just a quick step to it? > When signing, the checksum is part of the signature, so you'd have to > decrypt the signature block with the signer's public key via: > > openssl rsautl -pubin -raw -encrypt -inkey pubkey.pem > > and find the message digest there. > From openssl-users at dukhovni.org Thu Mar 8 17:37:18 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 8 Mar 2018 12:37:18 -0500 Subject: [openssl-users] Payload-checksum in PEM? In-Reply-To: References: <89e1b770-bec1-6fde-f8fe-d87b94ab73c0@coderhacks.com> Message-ID: > On Mar 8, 2018, at 11:52 AM, etc at coderhacks.com wrote: > > I have a certificate (cer.txt; content is enclosed with ---BEGIN/END CERTIFICATE---). > I can get the public-key out of that. (pubkey.txt; content is enclosed ---BEGIN/END PUBLIC KEY---). > I have the PEM (pem.txt; content is enclosed with ---BEGIN/END CMS---). That's a CMS message, it may contains a signature, but it is not (just) a signature. > This is what I call the signature and I would expect to have a hash of my original file somewhere inside of it. See above. > If I do > > openssl rsautl -pubin -raw -encrypt -inkey pubkey.txt -in pem.txt The raw RSA signed payload is not textual PEM data, it is a binary element of the CMS structure (when the structure contains a signature). -- Viktor. From erik at efca.com Mon Mar 12 18:39:25 2018 From: erik at efca.com (Erik Forsberg) Date: Mon, 12 Mar 2018 11:39:25 -0700 Subject: [openssl-users] Compilation error in ssl/t1_trce.c Message-ID: There are missing comma's in ssl/t1_trce.c that causes compilation to fail. You have to configure with enable-ssl-trace to see it though. gcc -I. -Iinclude -I../src -I../src/include -fPIC -std=gnu90 -march=core2 -Wall -O3 -fomit-frame-pointer -pthread -DFILIO_H -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/ssl/lib/engines-1.1\"" -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DNDEBUG -MMD -MF ssl/t1_trce.d.tmp -MT ssl/t1_trce.o -c -o ssl/t1_trce.o ../src/ssl/t1_trce.c ../src/ssl/t1_trce.c:484:5: error: expected '}' before '{' token {TLSEXT_TYPE_signature_algorithms_cert, "signature_algorithms_cert"} ^ *** Error code 1 From matt at openssl.org Mon Mar 12 19:48:11 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 12 Mar 2018 19:48:11 +0000 Subject: [openssl-users] Compilation error in ssl/t1_trce.c In-Reply-To: References: Message-ID: On 12/03/18 18:39, Erik Forsberg wrote: > > There are missing comma's in ssl/t1_trce.c that causes compilation to fail. > You have to configure with enable-ssl-trace to see it though. > > gcc -I. -Iinclude -I../src -I../src/include -fPIC -std=gnu90 -march=core2 -Wall -O3 -fomit-frame-pointer -pthread -DFILIO_H -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/ssl/lib/engines-1.1\"" -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DNDEBUG -MMD -MF ssl/t1_trce.d.tmp -MT ssl/t1_trce.o -c -o ssl/t1_trce.o ../src/ssl/t1_trce.c > ../src/ssl/t1_trce.c:484:5: error: expected '}' before '{' token > {TLSEXT_TYPE_signature_algorithms_cert, "signature_algorithms_cert"} > ^ > *** Error code 1 > Yes, I independently discovered this myself earlier today. I just pushed the fix to master. Matt From chris.bare at gmail.com Mon Mar 12 22:53:42 2018 From: chris.bare at gmail.com (Chris Bare) Date: Mon, 12 Mar 2018 18:53:42 -0400 Subject: [openssl-users] how to control the cipher list of an openssl server Message-ID: I have a fairly basic server set up based on various examples I've seen. I run an nmap script I found against it and see only 16 ciphers listed, none of which are supported by modern web browsers. Yet when I run "openssl ciphers I get a list of 97. I realize some of these are old and deprecated etc, but where does the default list come from? I tried this code to set it to use one of the more modern ciphers shown in the the openssl ciphers output: char *ssl_cipher = "ECDHE-ECDSA-AES128-GCM-SHA256"; if(!SSL_CTX_set_cipher_list(jav->ctx, ssl_cipher)) return (false); but after that the nmap script doesn't find any ciphers. Any suggestions? -- Chris Bare -------------- next part -------------- An HTML attachment was scrubbed... URL: From smadwin at adobe.com Mon Mar 12 21:49:47 2018 From: smadwin at adobe.com (Steven Madwin) Date: Mon, 12 Mar 2018 21:49:47 +0000 Subject: [openssl-users] RSA-PSS Param File Message-ID: Hi All, My ultimate goal is to generate an RSA-PSS key that will have the PSS parameters in the subjectPublicKey section of the TBSCertificate. In order to do that the first need is a paramfile. Here's the command being used to to generate the parameter file: OpenSSL> genpkey -genparam -paramfile .\pem\rsapssParams.pem -pkeyopt rsa_keygen_bits:2048 -pkeyopt rsa_pss_keygen_md:sha256 -pkeyopt rsa_pss_keygen_mgf1_md:sha256 -pkeyopt rsa_pss_keygen_saltlen:120 But, it returns the error: NB: options order may be important! See the manual page. error in genpkey The genpkey man page says for the -genparam option, "If used this option must precede any -algorithm, -paramfile or -pkeyopt options. With regard to the -paramfile option it says, "If used this option must precede any -pkeyopt options. Thus, with -genparam first followed by the -paramfile option and capped off with the -pkeyopt options it looks to me that the order is correct. If anyone has any enlightenment for me I'd be eternally grateful. Thanks, Steve Steven Madwin Software QA Engineer Adobe Systems Incorporated 345 Park Avenue, MS-W15 San Jose, CA 95110-2704 USA Phone: 408.536.4343 Fax: 408.536.6024 Steven.Madwin at adobe.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 1089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 1200 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5451 bytes Desc: not available URL: From matt at openssl.org Tue Mar 13 00:09:54 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 13 Mar 2018 00:09:54 +0000 Subject: [openssl-users] how to control the cipher list of an openssl server In-Reply-To: References: Message-ID: <5fca3bf5-a6c1-cca8-38ae-b58f08f5c7a0@openssl.org> On 12/03/18 22:53, Chris Bare wrote: > I have a fairly basic server set up based on various examples I've seen. > > I run an nmap script I found against it and see only 16 ciphers listed, > none of which are supported by modern web browsers. > Yet when I run "openssl ciphers I get a list of 97. > > I realize some of these are old and deprecated etc, but where does the > default list come from? > > I tried this code to set it to use one of the more modern ciphers shown > in the the openssl ciphers output: > > char *ssl_cipher = "ECDHE-ECDSA-AES128-GCM-SHA256"; > if(!SSL_CTX_set_cipher_list(jav->ctx, ssl_cipher)) > ???????? return (false); > > but after that the nmap script doesn't find any ciphers. > > Any suggestions? When you run "openssl ciphers" without other arguments it will give you the default set of ciphersuites. Not all of those will be useable by your server depending on other aspects of its configuration. For example PSK ciphersuites will only be available if you have configured a pre-shared-key (PSK). Most important is the type of certificate that your server is using, with typical types being RSA, ECDSA or DSA. It is possible to configure a server with more than one type of certificate - but if you've only got one then only ciphersuites compatible with that certificate will be used. In your example the ECDHE-ECDSA-AES128-GCM-SHA256 requires an ECDSA certificate to be present. If you haven't go one, and that's the only ciphersuite configured, then you won't be able to successfully make connections. Hope that helps, Matt From wangqun at alumni.nus.edu.sg Tue Mar 13 09:13:56 2018 From: wangqun at alumni.nus.edu.sg (Wang) Date: Tue, 13 Mar 2018 02:13:56 -0700 (MST) Subject: [openssl-users] OpenSSL 1.0.2n Build Failed on Windows 32bit Platform Message-ID: <1520932436738-0.post@n7.nabble.com> Hello, When I build OpenSSL1.0.2n, I hit the following error on Windows 32bit platform. [exec] o_init.c [exec] .\crypto\o_init.c(77) : error C2220: warning treated as error - no 'object' file generated [exec] .\crypto\o_init.c(77) : warning C4013: 'FIPS_crypto_set_id_callback' undefined; assuming extern returning int [exec] NMAKE : fatal error U1077: '"D:\engapps\Microsoft Visual Studio 8\VC \BIN\cl.EXE"' : return code '0x2' [exec] Stop. [exec] Result: 2 This failure only occurs on Windows 32bit. Building OpenSSL 1.0.2n on Windows 64bit, Solaris 32/64bit, Linux 32/64bit and hpia 32/64bit is OK. In addition, building OpenSSL1.0.2k on Windows 32bit is OK too. I saw a link (http://openssl.6102.n7.nabble.com/openssl-org-4685-PATCH-Add-missing-prototype-for-FIPS-callback-tt68511.html) which suggested a possible fix to this issue, but it brings another build failure below. [exec] o_init.c [exec] .\crypto\o_init.c(78) : error C2143: syntax error : missing ';' befo re 'type' [exec] .\crypto\o_init.c(79) : warning C4013: 'FIPS_crypto_set_id_callback' undefined; assuming extern returning int [exec] NMAKE : fatal error U1077: '"D:\engapps\Microsoft Visual Studio 8\VC\BIN\cl.EXE"' : return code '0x2' [exec] Stop. [exec] Result: 2 Anyone knows how to fix this issue? Any help is appreciated. Thank you in advance, Wang -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From Matthias.St.Pierre at ncp-e.com Tue Mar 13 14:22:12 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 13 Mar 2018 14:22:12 +0000 Subject: [openssl-users] OpenSSL 1.0.2n Build Failed on Windows 32bit Platform Message-ID: Hi, this issue was fixed in the OpenSSL 1.0.2 stable branch in commit https://github.com/openssl/openssl/commit/18df0adda98f8f21cc494b4835c2817bcadbeb8a, which will be part oft he next letter release. If you need it right away, you can get it from the current stable branch on github. https://github.com/openssl/openssl/commits/OpenSSL_1_0_2-stable Regards, Matthias > -----Urspr?ngliche Nachricht----- > Von: openssl-users Im Auftrag von Wang > Gesendet: Dienstag, 13. M?rz 2018 10:14 > An: openssl-users at openssl.org > Betreff: [openssl-users] OpenSSL 1.0.2n Build Failed on Windows 32bit Platform > > Hello, > > When I build OpenSSL1.0.2n, I hit the following error on Windows 32bit > platform. > > [exec] o_init.c > [exec] .\crypto\o_init.c(77) : error C2220: warning treated as error - > no 'object' file generated > [exec] .\crypto\o_init.c(77) : warning C4013: > 'FIPS_crypto_set_id_callback' undefined; assuming extern returning int > [exec] NMAKE : fatal error U1077: '"D:\engapps\Microsoft Visual Studio > 8\VC > \BIN\cl.EXE"' : return code '0x2' > [exec] Stop. > [exec] Result: 2 > > This failure only occurs on Windows 32bit. Building OpenSSL 1.0.2n on > Windows 64bit, Solaris 32/64bit, Linux 32/64bit and hpia 32/64bit is OK. In > addition, building OpenSSL1.0.2k on Windows 32bit is OK too. > > I saw a link > (http://openssl.6102.n7.nabble.com/openssl-org-4685-PATCH-Add-missing-prototype-for-FIPS-callback-tt68511.html) > which suggested a possible fix to this issue, but it brings another build > failure below. > [exec] o_init.c > [exec] .\crypto\o_init.c(78) : error C2143: syntax error : missing ';' > befo > re 'type' > [exec] .\crypto\o_init.c(79) : warning C4013: > 'FIPS_crypto_set_id_callback' undefined; assuming extern returning int > [exec] NMAKE : fatal error U1077: '"D:\engapps\Microsoft Visual Studio > 8\VC\BIN\cl.EXE"' : return code '0x2' > [exec] Stop. > [exec] Result: 2 > > Anyone knows how to fix this issue? Any help is appreciated. > > Thank you in advance, > Wang > > > > > > -- > Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4328 bytes Desc: not available URL: From Matthias.St.Pierre at ncp-e.com Tue Mar 13 14:39:57 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 13 Mar 2018 14:39:57 +0000 Subject: [openssl-users] OpenSSL 1.0.2n Build Failed on Windows 32bit Platform In-Reply-To: References: Message-ID: Note: If you don't have git available, you can download the sources as a zip archive using the following link: https://github.com/openssl/openssl/archive/OpenSSL_1_0_2-stable.zip Matthias > -----Urspr?ngliche Nachricht----- > Von: openssl-users Im Auftrag von Dr. Matthias St. Pierre > Gesendet: Dienstag, 13. M?rz 2018 15:22 > An: openssl-users at openssl.org > Betreff: Re: [openssl-users] OpenSSL 1.0.2n Build Failed on Windows 32bit Platform > > Hi, > > this issue was fixed in the OpenSSL 1.0.2 stable branch in commit > > https://github.com/openssl/openssl/commit/18df0adda98f8f21cc494b4835c2817bcadbeb8a, > > which will be part oft he next letter release. If you need it right away, you can get it from the current stable branch on github. > > https://github.com/openssl/openssl/commits/OpenSSL_1_0_2-stable > > Regards, > Matthias > > > > > -----Urspr?ngliche Nachricht----- > > Von: openssl-users Im Auftrag von Wang > > Gesendet: Dienstag, 13. M?rz 2018 10:14 > > An: openssl-users at openssl.org > > Betreff: [openssl-users] OpenSSL 1.0.2n Build Failed on Windows 32bit Platform > > > > Hello, > > > > When I build OpenSSL1.0.2n, I hit the following error on Windows 32bit > > platform. > > > > [exec] o_init.c > > [exec] .\crypto\o_init.c(77) : error C2220: warning treated as error - > > no 'object' file generated > > [exec] .\crypto\o_init.c(77) : warning C4013: > > 'FIPS_crypto_set_id_callback' undefined; assuming extern returning int > > [exec] NMAKE : fatal error U1077: '"D:\engapps\Microsoft Visual Studio > > 8\VC > > \BIN\cl.EXE"' : return code '0x2' > > [exec] Stop. > > [exec] Result: 2 > > > > This failure only occurs on Windows 32bit. Building OpenSSL 1.0.2n on > > Windows 64bit, Solaris 32/64bit, Linux 32/64bit and hpia 32/64bit is OK. In > > addition, building OpenSSL1.0.2k on Windows 32bit is OK too. > > > > I saw a link > > (http://openssl.6102.n7.nabble.com/openssl-org-4685-PATCH-Add-missing-prototype-for-FIPS-callback-tt68511.html) > > which suggested a possible fix to this issue, but it brings another build > > failure below. > > [exec] o_init.c > > [exec] .\crypto\o_init.c(78) : error C2143: syntax error : missing ';' > > befo > > re 'type' > > [exec] .\crypto\o_init.c(79) : warning C4013: > > 'FIPS_crypto_set_id_callback' undefined; assuming extern returning int > > [exec] NMAKE : fatal error U1077: '"D:\engapps\Microsoft Visual Studio > > 8\VC\BIN\cl.EXE"' : return code '0x2' > > [exec] Stop. > > [exec] Result: 2 > > > > Anyone knows how to fix this issue? Any help is appreciated. > > > > Thank you in advance, > > Wang > > > > > > > > > > > > -- > > Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4328 bytes Desc: not available URL: From alandean888 at gmail.com Tue Mar 13 21:39:04 2018 From: alandean888 at gmail.com (Alan Dean) Date: Tue, 13 Mar 2018 14:39:04 -0700 Subject: [openssl-users] =?utf-8?q?FIPS_Non=C2=AD-Approved_Cryptographic_F?= =?utf-8?q?unctions?= Message-ID: Hi All: >From the OpenSSL FIPS Security Policy chapter 4, it mentioned there are a number of non-FIPS approved algorithms/ services which are still implemented by the FIPS canister modules (e.g. RSA, DSA, DRDB, ECDSA etc). Just wondering why these algorithms are still implemented by FIPS Canister. The concern is, if these algorithms could still be used under FIPS mode, there is risk that the applications which use the FIPS canister modules may become non-FIPS compliant if these algorithms are used by mistake. Is my understanding correct and in that case is there a way to disable these non-FIPS approved algorithms? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From etc at coderhacks.com Tue Mar 13 22:46:14 2018 From: etc at coderhacks.com (etc at coderhacks.com) Date: Tue, 13 Mar 2018 23:46:14 +0100 Subject: [openssl-users] Vanilla OpenSSL uses sytems libs Message-ID: <323c64fe-c3a7-0b93-a11e-46f743b999be@coderhacks.com> Hi! I put a vanilla OpenSSL in a local folder and compiled it. ./config no-shared make I will not do a "make install" because I will keep my distros installation. But Iwill use the vanilla for tests. So I need the binary as well as the libs. After a ldd? I see that the apps/openssl as well as the libssl and libcrypto use the systems OpenSSL-libs instead of the one I just compiled. Is there an option so the makefile will produce binaries out of its own libs instead of the sytems? Thanks! From scott_n at xypro.com Tue Mar 13 23:02:21 2018 From: scott_n at xypro.com (Scott Neugroschl) Date: Tue, 13 Mar 2018 23:02:21 +0000 Subject: [openssl-users] Vanilla OpenSSL uses sytems libs In-Reply-To: <323c64fe-c3a7-0b93-a11e-46f743b999be@coderhacks.com> References: <323c64fe-c3a7-0b93-a11e-46f743b999be@coderhacks.com> Message-ID: Set LD_LIBRARY_PATH to use your compiled versions. -----Original Message----- From: openssl-users On Behalf Of etc at coderhacks.com Sent: Tuesday, March 13, 2018 3:46 PM To: openssl-users at openssl.org Subject: [openssl-users] Vanilla OpenSSL uses sytems libs Hi! I put a vanilla OpenSSL in a local folder and compiled it. ./config no-shared make I will not do a "make install" because I will keep my distros installation. But Iwill use the vanilla for tests. So I need the binary as well as the libs. After a ldd? I see that the apps/openssl as well as the libssl and libcrypto use the systems OpenSSL-libs instead of the one I just compiled. Is there an option so the makefile will produce binaries out of its own libs instead of the sytems? Thanks! -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From etc at coderhacks.com Wed Mar 14 05:59:26 2018 From: etc at coderhacks.com (etc at coderhacks.com) Date: Wed, 14 Mar 2018 06:59:26 +0100 Subject: [openssl-users] Vanilla OpenSSL uses sytems libs In-Reply-To: References: <323c64fe-c3a7-0b93-a11e-46f743b999be@coderhacks.com> Message-ID: <125434b0-7bb5-4373-5395-88902e67b97b@coderhacks.com> Thanks! It works if I export LD_LIBRARY_PATH=/my/openssl/root and recompile it. On 2018-03-14 00:02, Scott Neugroschl wrote: > Set LD_LIBRARY_PATH to use your compiled versions. > > -----Original Message----- > From: openssl-users On Behalf Of etc at coderhacks.com > Sent: Tuesday, March 13, 2018 3:46 PM > To: openssl-users at openssl.org > Subject: [openssl-users] Vanilla OpenSSL uses sytems libs > > Hi! > > I put a vanilla OpenSSL in a local folder and compiled it. > > ./config no-shared > make > > I will not do a "make install" because I will keep my distros installation. > But Iwill use the vanilla for tests. So I need the binary as well as the libs. > > After a ldd? I see that the apps/openssl as well as the libssl and libcrypto use the systems OpenSSL-libs instead of the one I just compiled. > > Is there an option so the makefile will produce binaries out of its own libs instead of the sytems? > > Thanks! > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From wangqun at alumni.nus.edu.sg Wed Mar 14 06:24:10 2018 From: wangqun at alumni.nus.edu.sg (Wang) Date: Tue, 13 Mar 2018 23:24:10 -0700 (MST) Subject: [openssl-users] OpenSSL 1.0.2n Build Failed on Windows 32bit Platform In-Reply-To: References: Message-ID: <1521008650920-0.post@n7.nabble.com> Thank you very much, Matthias. It works. Regards, Wang -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From etc at coderhacks.com Wed Mar 14 06:43:05 2018 From: etc at coderhacks.com (etc at coderhacks.com) Date: Wed, 14 Mar 2018 07:43:05 +0100 Subject: [openssl-users] MIME-canonicalization Message-ID: Hi! I am facing some problems with a SMIME where the content is binary encoded AND a linefeed (LF) (0x0a) is used for line-separator. The CMS_verify failes (CMS routines:CMS_SignerInfo_verify_content:verification failure). It works fine if CRLF (0x0d 0x0a) is line-separator or even if only CR is used - but not with LF only. It is also ok if the content is not in binary but base64 encoded. I tried with and without CMS_BINARY flag set. I think it is about the canonicalization of MIME if the content is not base64. Is OpenSSL doing this canonicalization (where?). I think CMS_BINARY should disable it - I tried to change any LF to CRLF before the verify but that did not help. Any ideas? Thanks! Chris From etc at coderhacks.com Wed Mar 14 08:33:12 2018 From: etc at coderhacks.com (etc at coderhacks.com) Date: Wed, 14 Mar 2018 09:33:12 +0100 Subject: [openssl-users] MIME-canonicalization In-Reply-To: References: Message-ID: <4d488f7b-14a6-deb6-99a8-ca864e061b7d@coderhacks.com> I think I found the reason for the problem. SMIME_read_CMS does convert any single LF to a CRLF. If I compare the input to the CMS I get out of SMIME_read_CMS then there are all LFs replaced with CRLFs. Thats the problem with the verify. If I manually replace the added CRs in the CMS and then give it to CMS_verify all is fine. So... can I disable this canonicalization in SMIME_read_CMS?? Thanks for help! On 2018-03-14 07:43, etc at coderhacks.com wrote: > Hi! > > I am facing some problems with a SMIME where the content is binary > encoded AND a linefeed (LF) (0x0a) is used for line-separator. > The CMS_verify failes (CMS > routines:CMS_SignerInfo_verify_content:verification failure). > > It works fine if CRLF (0x0d 0x0a) is line-separator or even if only CR > is used - but not with LF only. > It is also ok if the content is not in binary but base64 encoded. > > I tried with and without CMS_BINARY flag set. > > I think it is about the canonicalization of MIME if the content is not > base64. > > Is OpenSSL doing this canonicalization (where?). > > I think CMS_BINARY should disable it - I tried to change any LF to > CRLF before the verify but that did not help. > > Any ideas? > > Thanks! > Chris > From bacarozzo at gmail.com Wed Mar 14 09:20:25 2018 From: bacarozzo at gmail.com (Federico Buti) Date: Wed, 14 Mar 2018 10:20:25 +0100 Subject: [openssl-users] EVP signing Message-ID: Hi list. I'm currently implementing a signing routine and for that I'm using the high-level API EVP according to this page . I'm using openssl 1.0.2m. I need to sign with hashing SHA256 and prime256v1, with the former retrieved via "EVP_get_digestbyname". The private key is stored in a PEM file and loaded via "PEM_read_bio_PrivateKey". It is correctly loaded and correctly recognized to be of type EC (408). So far so good, I am able to sign the payload and verify it. Hence, the procedure is correctly carried out. HOWEVER, once the signed payload is sent to the server, it is rejected. I believe the issue is with "prime256v1" because, as far as I can tell, that is not the default curve for EC signing. Looking into the documentation I tried to set the correct curve like this (smart pointers used, error handling ignored for the sake of brevity): EVP_PKEY_CTX * pctx; EVP_DigestSignInit(mdctx.get(), &pctx, digestFunction, NULL, key.get())) EVP_PKEY_paramgen_init(pctx); EVP_PKEY_CTX_set_ec_paramgen_curve_nid(pctx, NID_X9_62_prime256v1); // usual steps... But that leads to errors in "EVP_DigestSignFinal" and the inability to sign the payload. Probably this is not the correct way to set the curve. So, what's the correct way to sign a payload with SHA256 and prime256v1? Is EVP api the correct one? Thanks in advance for the help. F. -------------- next part -------------- An HTML attachment was scrubbed... URL: From noreply81 at t-online.de Wed Mar 14 09:32:24 2018 From: noreply81 at t-online.de (Guido) Date: Wed, 14 Mar 2018 10:32:24 +0100 Subject: [openssl-users] (no subject) Message-ID: <1ew2ll-0vKyH20@fwd05.t-online.de> Gesendet von Mail f?r Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Mar 14 09:46:52 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 14 Mar 2018 09:46:52 +0000 Subject: [openssl-users] EVP signing In-Reply-To: References: Message-ID: <70de0ccd-48da-6a39-3790-bc8188f044e7@openssl.org> On 14/03/18 09:20, Federico Buti wrote: > Hi list. > > I'm currently implementing a signing routine and for that I'm using the > high-level API EVP according to this page > . I'm > using openssl 1.0.2m. > > I need to sign with hashing?SHA256 and?prime256v1, with the former > retrieved via "EVP_get_digestbyname". The private key is stored in a PEM > file and loaded via "PEM_read_bio_PrivateKey". It is correctly loaded > and correctly recognized to be of type EC (408). > > So far so good, I am able to sign the payload and verify it. Hence, the > procedure is correctly carried out. HOWEVER, once the signed payload is > sent to the server, it is rejected. I believe the issue is with > "prime256v1" because, as far as I can tell, that is not the default > curve for EC signing. > > Looking into the documentation I tried to set the correct curve like > this (smart pointers used, error handling ignored for the sake of brevity): > > EVP_PKEY_CTX*pctx; > > EVP_DigestSignInit(mdctx.get(), &pctx,?digestFunction,?NULL,?key.get())) > > EVP_PKEY_paramgen_init(pctx); > > EVP_PKEY_CTX_set_ec_paramgen_curve_nid(pctx,NID_X9_62_prime256v1); > > // usual steps... > > But that leads to errors in "EVP_DigestSignFinal" and the inability to > sign the payload. Probably this is not the correct way to set the curve. > > So, what's the correct way to sign a payload with SHA256 and?prime256v1? > Is EVP api the correct one? Yes, EVP is the correct API. An EC private key is tied to the curve that was used to generate it, so any signatures will be based on that curve. If your private key isn't using prime256v1 and that curve is a requirement then you'll need to generate a new key. Matt > > Thanks in advance for the help. > F. > > From levitte at openssl.org Wed Mar 14 09:54:17 2018 From: levitte at openssl.org (Richard Levitte) Date: Wed, 14 Mar 2018 10:54:17 +0100 (CET) Subject: [openssl-users] Vanilla OpenSSL uses sytems libs In-Reply-To: <323c64fe-c3a7-0b93-a11e-46f743b999be@coderhacks.com> References: <323c64fe-c3a7-0b93-a11e-46f743b999be@coderhacks.com> Message-ID: <20180314.105417.260099623859874956.levitte@openssl.org> Something here makes no sense at all... you configure with 'no-shared', and then get an apps/openssl that's linked with the system shared libraries? In message <323c64fe-c3a7-0b93-a11e-46f743b999be at coderhacks.com> on Tue, 13 Mar 2018 23:46:14 +0100, "etc at coderhacks.com" said: etc> Hi! etc> etc> I put a vanilla OpenSSL in a local folder and compiled it. etc> etc> ./config no-shared etc> make etc> etc> I will not do a "make install" because I will keep my distros etc> installation. etc> But Iwill use the vanilla for tests. So I need the binary as well as etc> the libs. etc> etc> After a ldd? I see that the apps/openssl as well as the libssl and etc> libcrypto use the systems OpenSSL-libs instead of the one I just etc> compiled. etc> etc> Is there an option so the makefile will produce binaries out of its etc> own libs instead of the sytems? etc> etc> Thanks! etc> etc> etc> etc> From etc at coderhacks.com Wed Mar 14 09:59:20 2018 From: etc at coderhacks.com (etc at coderhacks.com) Date: Wed, 14 Mar 2018 10:59:20 +0100 Subject: [openssl-users] Vanilla OpenSSL uses sytems libs In-Reply-To: <20180314.105417.260099623859874956.levitte@openssl.org> References: <323c64fe-c3a7-0b93-a11e-46f743b999be@coderhacks.com> <20180314.105417.260099623859874956.levitte@openssl.org> Message-ID: Yes... thats the same what I thought. I expected to link against the the vanilla built if I set no-shared. But it links against my systems libs. It seems config takes my no-shared correctly - because If I do a typo it will tell me about an unknown option. Only If I set LD_LIBRARY_PATH to my vanillas path then it links against the just built libs. Are there more parameters than no-shared that influence that?? Thanks! Chris On 2018-03-14 10:54, Richard Levitte wrote: > Something here makes no sense at all... you configure with > 'no-shared', and then get an apps/openssl that's linked with the > system shared libraries? > > In message <323c64fe-c3a7-0b93-a11e-46f743b999be at coderhacks.com> on Tue, 13 Mar 2018 23:46:14 +0100, "etc at coderhacks.com" said: > > etc> Hi! > etc> > etc> I put a vanilla OpenSSL in a local folder and compiled it. > etc> > etc> ./config no-shared > etc> make > etc> > etc> I will not do a "make install" because I will keep my distros > etc> installation. > etc> But Iwill use the vanilla for tests. So I need the binary as well as > etc> the libs. > etc> > etc> After a ldd? I see that the apps/openssl as well as the libssl and > etc> libcrypto use the systems OpenSSL-libs instead of the one I just > etc> compiled. > etc> > etc> Is there an option so the makefile will produce binaries out of its > etc> own libs instead of the sytems? > etc> > etc> Thanks! > etc> > etc> > etc> > etc> From Michael.Wojcik at microfocus.com Wed Mar 14 16:25:11 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 14 Mar 2018 16:25:11 +0000 Subject: [openssl-users] MIME-canonicalization In-Reply-To: <4d488f7b-14a6-deb6-99a8-ca864e061b7d@coderhacks.com> References: <4d488f7b-14a6-deb6-99a8-ca864e061b7d@coderhacks.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of etc at coderhacks.com > Sent: Wednesday, March 14, 2018 02:33 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] MIME-canonicalization > > I think I found the reason for the problem. > > SMIME_read_CMS does convert any single LF to a CRLF. Have you verified that the file actually contains bare LFs, and not CRLFs? If you're running on Windows, beware the CRLF conversions done by the C library. For example, if you write a file using a file BIO that was created using a FILE* from a text-mode fopen, that file will have LFs converted to CRLF on output. You need to open the file in binary mode, or call _setmode on the FILE* before writing to it. SMIME_read_CMS just calls SMIME_read_ASN1, which ultimately does a bunch of BIO_gets, which calls the gets method on the BIO object. A file BIO's gets method just calls fgets. So if there's translation happening, it would appear to be in the C runtime. -- Michael Wojcik Distinguished Engineer, Micro Focus From etc at coderhacks.com Wed Mar 14 16:43:10 2018 From: etc at coderhacks.com (etc at coderhacks.com) Date: Wed, 14 Mar 2018 17:43:10 +0100 Subject: [openssl-users] MIME-canonicalization In-Reply-To: References: <4d488f7b-14a6-deb6-99a8-ca864e061b7d@coderhacks.com> Message-ID: <5619dd27-e9b8-3fbc-1c65-ec930ff7f381@coderhacks.com> I have verified in comparing the orginal file that is going into SIME_read_CMS with the content of the the 2nd argument (bcont) it get out of it. I check manually. The file with a hex-editor. bcont with BIO_read and then print it to the screen. The file does have LFs, the bcont does have CRLFs. The file is going directly into SMIME_read_CMS via BIO_read_filename. So I use the filename to address the content-file - no string or something with a previous parsing. I am running a debian buster. Best regards, Chris On 2018-03-14 17:25, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of etc at coderhacks.com >> Sent: Wednesday, March 14, 2018 02:33 >> To: openssl-users at openssl.org >> Subject: Re: [openssl-users] MIME-canonicalization >> >> I think I found the reason for the problem. >> >> SMIME_read_CMS does convert any single LF to a CRLF. > Have you verified that the file actually contains bare LFs, and not CRLFs? > > If you're running on Windows, beware the CRLF conversions done by the C library. For example, if you write a file using a file BIO that was created using a FILE* from a text-mode fopen, that file will have LFs converted to CRLF on output. You need to open the file in binary mode, or call _setmode on the FILE* before writing to it. > > SMIME_read_CMS just calls SMIME_read_ASN1, which ultimately does a bunch of BIO_gets, which calls the gets method on the BIO object. A file BIO's gets method just calls fgets. So if there's translation happening, it would appear to be in the C runtime. > From openssl-users at dukhovni.org Wed Mar 14 19:30:27 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 14 Mar 2018 15:30:27 -0400 Subject: [openssl-users] MIME-canonicalization In-Reply-To: References: Message-ID: <4A33DC85-DD04-40E2-B3DC-673C2D347458@dukhovni.org> > On Mar 14, 2018, at 2:43 AM, etc at coderhacks.com wrote: > > I am facing some problems with a SMIME where the content is binary encoded AND a linefeed (LF) (0x0a) is used for line-separator. > The CMS_verify failes (CMS routines:CMS_SignerInfo_verify_content:verification failure). > > It works fine if CRLF (0x0d 0x0a) is line-separator or even if only CR is used - but not with LF only. > It is also ok if the content is not in binary but base64 encoded. > > I tried with and without CMS_BINARY flag set. S/MIME is not compatible with non-line-oriented binary MIME. Your message MUST have CRLF-terminated input lines. If you want true binary data, use CMS, not S/MIME. -- Viktor. From jmutkawoa at hackers.mu Wed Mar 14 20:07:12 2018 From: jmutkawoa at hackers.mu (Nitin Mutkawoa) Date: Thu, 15 Mar 2018 00:07:12 +0400 Subject: [openssl-users] how to control the cipher list of an openssl server In-Reply-To: <5fca3bf5-a6c1-cca8-38ae-b58f08f5c7a0@openssl.org> References: <5fca3bf5-a6c1-cca8-38ae-b58f08f5c7a0@openssl.org> Message-ID: Hello I wish to add some additional information. Perhaps it's useful to you. As Matt mentioned check out your ciphers. --> *openssl ciphers -v* You can also grep a particular cipher for example TLS. *openssl "ciphers" -v | grep i tls* So basically, you might need to check if you have the right version of openssl-libs. If you have compiled your OpenSSL from source, it will also depends which lib you are specifying which might result out old ciphers in that particular situation. Look out for the binary and use ldd to see which library it is calling. It also depends how the server is configured. Let's say its a webserver Nginx server, you will need to add the necessary ciphers to the conf. Since you have probably run an *nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 www.example.com , *i doubt that the issue might be with the server configuration. regards Nitin J Mutkawoa https://tunnelix.com https://hackers.mu Twitter: @TheTunnelix On Tue, Mar 13, 2018 at 4:09 AM, Matt Caswell wrote: > > > On 12/03/18 22:53, Chris Bare wrote: > > I have a fairly basic server set up based on various examples I've seen. > > > > I run an nmap script I found against it and see only 16 ciphers listed, > > none of which are supported by modern web browsers. > > Yet when I run "openssl ciphers I get a list of 97. > > > > I realize some of these are old and deprecated etc, but where does the > > default list come from? > > > > I tried this code to set it to use one of the more modern ciphers shown > > in the the openssl ciphers output: > > > > char *ssl_cipher = "ECDHE-ECDSA-AES128-GCM-SHA256"; > > if(!SSL_CTX_set_cipher_list(jav->ctx, ssl_cipher)) > > return (false); > > > > but after that the nmap script doesn't find any ciphers. > > > > Any suggestions? > > When you run "openssl ciphers" without other arguments it will give you > the default set of ciphersuites. Not all of those will be useable by > your server depending on other aspects of its configuration. For example > PSK ciphersuites will only be available if you have configured a > pre-shared-key (PSK). > > Most important is the type of certificate that your server is using, > with typical types being RSA, ECDSA or DSA. It is possible to configure > a server with more than one type of certificate - but if you've only got > one then only ciphersuites compatible with that certificate will be used. > > In your example the ECDHE-ECDSA-AES128-GCM-SHA256 requires an ECDSA > certificate to be present. If you haven't go one, and that's the only > ciphersuite configured, then you won't be able to successfully make > connections. > > Hope that helps, > > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Wed Mar 14 22:10:49 2018 From: levitte at openssl.org (Richard Levitte) Date: Wed, 14 Mar 2018 23:10:49 +0100 (CET) Subject: [openssl-users] Vanilla OpenSSL uses sytems libs In-Reply-To: References: <323c64fe-c3a7-0b93-a11e-46f743b999be@coderhacks.com> <20180314.105417.260099623859874956.levitte@openssl.org> Message-ID: <20180314.231049.1331000832872945511.levitte@openssl.org> BTW, which OpenSSL version are we talking about here? In message on Wed, 14 Mar 2018 10:59:20 +0100, "etc at coderhacks.com" said: etc> Yes... thats the same what I thought. etc> etc> I expected to link against the the vanilla built if I set no-shared. etc> But it links against my systems libs. etc> etc> It seems config takes my no-shared correctly - because If I do a typo etc> it will tell me about an unknown option. etc> etc> Only If I set LD_LIBRARY_PATH to my vanillas path then it links etc> against the just built libs. etc> etc> Are there more parameters than no-shared that influence that?? etc> etc> Thanks! etc> Chris etc> etc> On 2018-03-14 10:54, Richard Levitte wrote: etc> > Something here makes no sense at all... you configure with etc> > 'no-shared', and then get an apps/openssl that's linked with the etc> > system shared libraries? etc> > etc> > In message <323c64fe-c3a7-0b93-a11e-46f743b999be at coderhacks.com> on etc> > Tue, 13 Mar 2018 23:46:14 +0100, "etc at coderhacks.com" etc> > said: etc> > etc> > etc> Hi! etc> > etc> etc> > etc> I put a vanilla OpenSSL in a local folder and compiled it. etc> > etc> etc> > etc> ./config no-shared etc> > etc> make etc> > etc> etc> > etc> I will not do a "make install" because I will keep my distros etc> > etc> installation. etc> > etc> But Iwill use the vanilla for tests. So I need the binary as well etc> > as etc> > etc> the libs. etc> > etc> etc> > etc> After a ldd? I see that the apps/openssl as well as the libssl etc> > and etc> > etc> libcrypto use the systems OpenSSL-libs instead of the one I just etc> > etc> compiled. etc> > etc> etc> > etc> Is there an option so the makefile will produce binaries out of etc> > its etc> > etc> own libs instead of the sytems? etc> > etc> etc> > etc> Thanks! etc> > etc> etc> > etc> etc> > etc> etc> > etc> etc> etc> From mark at fips.pro Wed Mar 14 22:17:04 2018 From: mark at fips.pro (Mark Minnoch) Date: Wed, 14 Mar 2018 15:17:04 -0700 Subject: [openssl-users] FIPS Non?-Approved Cryptographic Functions Message-ID: > From the OpenSSL FIPS Security Policy chapter 4, it mentioned there are a > number of non-FIPS approved algorithms/ services which are still > implemented by the FIPS canister modules (e.g. RSA, DSA, DRDB, ECDSA etc). > > Just wondering why these algorithms are still implemented by FIPS Canister. > > The concern is, if these algorithms could still be used under FIPS mode, > there is risk that the applications which use the FIPS canister modules may > become non-FIPS compliant if these algorithms are used by mistake. You are correct. It is possible for an application to use the OpenSSL FOM in a non-approved way by calling a non-approved service listed in Table 4c of the OpenSSL FOM Security Policy. I'm sure it was easier for the OpenSSL team to make documentation changes (rather than making coding changes and performing additional FIPS testing) to maintain the validity of the FIPS certificate when the SP 800-131A transitions were enforced. A coding change to the FIPS canister would require review by the FIPS Laboratory. If any of the updates were found to be security relevant (from a FIPS perspective), then a FIPS revalidation effort involving additional testing would be required. As you know, there are many, many, many "Tested Configurations" (operating systems+hardware platforms) listed for the OpenSSL FOM certificates. A revalidation would result in a new OpenSSL FOM FIPS certificate and all of the previously tested configurations (that people care about) would need to be retested. Yikes. Here is some background for those interested... At the time of the original OpenSSL FOM validation, FIPS 140-2 allowed the use of an ANS X9.31 RNG. Digital signature functions could be performed using key sizes that provided an equivalent strength of 80 bits or greater. With the transition timelines documented in SP 800-131A, FIPS modules today must use only SP 800-90A DRBGs (for key generation) and >= 112 bits of equivalent strength for digital signature functions (although digital signature verification may be performed at previously allowed key sizes for legacy purposes). The services provided by the OpenSSL FOM that do not meet current SP 800-131A requirements are now listed as non-approved services in Table 4c of the OpenSSL FOM Security Policy. Mark J. Minnoch Co-Founder, CISSP, CISA KeyPair Consulting +1 (805) 550-3231 mobile https://KeyPair.us https://www.linkedin.com/in/minnoch *We expertly guide technology companies in achieving their FIPS 140 goals* *New blog post: You Have Your FIPS Certificate. Now What? * -------------- next part -------------- An HTML attachment was scrubbed... URL: From etc at coderhacks.com Wed Mar 14 23:11:35 2018 From: etc at coderhacks.com (etc at coderhacks.com) Date: Thu, 15 Mar 2018 00:11:35 +0100 Subject: [openssl-users] Vanilla OpenSSL uses sytems libs In-Reply-To: <20180314.231049.1331000832872945511.levitte@openssl.org> References: <323c64fe-c3a7-0b93-a11e-46f743b999be@coderhacks.com> <20180314.105417.260099623859874956.levitte@openssl.org> <20180314.231049.1331000832872945511.levitte@openssl.org> Message-ID: My systems (debian 10) version is 1.1.0g. The vanilla is 1.1.0f. On 2018-03-14 23:10, Richard Levitte wrote: > BTW, which OpenSSL version are we talking about here? > > In message on Wed, 14 Mar 2018 10:59:20 +0100, "etc at coderhacks.com" said: > > etc> Yes... thats the same what I thought. > etc> > etc> I expected to link against the the vanilla built if I set no-shared. > etc> But it links against my systems libs. > etc> > etc> It seems config takes my no-shared correctly - because If I do a typo > etc> it will tell me about an unknown option. > etc> > etc> Only If I set LD_LIBRARY_PATH to my vanillas path then it links > etc> against the just built libs. > etc> > etc> Are there more parameters than no-shared that influence that?? > etc> > etc> Thanks! > etc> Chris > etc> > etc> On 2018-03-14 10:54, Richard Levitte wrote: > etc> > Something here makes no sense at all... you configure with > etc> > 'no-shared', and then get an apps/openssl that's linked with the > etc> > system shared libraries? > etc> > > etc> > In message <323c64fe-c3a7-0b93-a11e-46f743b999be at coderhacks.com> on > etc> > Tue, 13 Mar 2018 23:46:14 +0100, "etc at coderhacks.com" > etc> > said: > etc> > > etc> > etc> Hi! > etc> > etc> > etc> > etc> I put a vanilla OpenSSL in a local folder and compiled it. > etc> > etc> > etc> > etc> ./config no-shared > etc> > etc> make > etc> > etc> > etc> > etc> I will not do a "make install" because I will keep my distros > etc> > etc> installation. > etc> > etc> But Iwill use the vanilla for tests. So I need the binary as well > etc> > as > etc> > etc> the libs. > etc> > etc> > etc> > etc> After a ldd? I see that the apps/openssl as well as the libssl > etc> > and > etc> > etc> libcrypto use the systems OpenSSL-libs instead of the one I just > etc> > etc> compiled. > etc> > etc> > etc> > etc> Is there an option so the makefile will produce binaries out of > etc> > its > etc> > etc> own libs instead of the sytems? > etc> > etc> > etc> > etc> Thanks! > etc> > etc> > etc> > etc> > etc> > etc> > etc> > etc> > etc> > etc> From openssl at openssl.org Tue Mar 20 14:09:13 2018 From: openssl at openssl.org (OpenSSL) Date: Tue, 20 Mar 2018 14:09:13 +0000 Subject: [openssl-users] OpenSSL version 1.1.1 pre release 3 published Message-ID: <20180320140913.GA11276@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.1.1 pre release 3 (beta) =========================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 3 has now been made available. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. The beta release is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.1-pre3.tar.gz Size: 6552052 SHA1 checksum: a9dee6b70334726420f483c496216d2b335a4510 SHA256 checksum: b541d574d8d099b0bc74ebc8174cec1dc9f426d8901d04be7874046ad72116b0 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1-pre3.tar.gz openssl sha256 openssl-1.1.1-pre3.tar.gz Please download and check this beta release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJasQkhAAoJENnE0m0OYESRf30H/1OxOdWi82Cw69+z4ly80TyR IeWQRgFh60lar3li3R6/ns57eXFo7jGOAAws1iOZll3RGR9bkp70cLXCZtMvZoEP 79pLrfUZR6s6BwGrSs7X3fHac4muUZSQLaAdCJG5Y6Sgi2XBy0rRYFxle0qND1c3 tNeh1B6oXy236cvVaDAUNYKEC/31RzupWIdLdT9UYWLU5qYdgkaOztHO2x1pDRX/ Vs18qNND5mHIrsv0QfZPP40nvsZrRoz7rXBuZdaQwLA9ZJzS0hNxwlpkodJB8kHD o29Q0fkczGnL3hw5rSi7c+qKgngXIVkB0ssisZBHgHVAA6WvvSPNG9SeGYJRgwQ= =0UFn -----END PGP SIGNATURE----- From dclarke at blastwave.org Tue Mar 20 16:48:24 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 20 Mar 2018 12:48:24 -0400 Subject: [openssl-users] testing OpenSSL version 1.1.1 pre release 3 on Sol10 sparc Message-ID: <8c7fe57a-72dd-85bb-3941-d7fea574f3dc@blastwave.org> I'll jump on that. Managed to get past the perl requirements and am now using Oracle Studio 12.6 on Solaris 10 sparc ( for some recent sparc incantation ) wherein I usually see : cc: Warning: -xarch=v9 is deprecated, use -m64 -xarch=sparc instead So the conf files need a small tweak. I'll test on Sol 10 x86_64 also. Dennis From rsalz at akamai.com Tue Mar 20 16:50:08 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 20 Mar 2018 16:50:08 +0000 Subject: [openssl-users] FIPs support on openssl 1.1.0 In-Reply-To: References: Message-ID: <8A4F056C-33DF-4363-9054-9D7D258B912F@akamai.com> * As of now, what is the latest version of openssl supporting FIPS, then? 1.0.2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbustamante at broadsoft.com Tue Mar 20 16:47:47 2018 From: jbustamante at broadsoft.com (Jorge Bustamante) Date: Tue, 20 Mar 2018 10:47:47 -0600 Subject: [openssl-users] FIPs support on openssl 1.1.0 In-Reply-To: References: Message-ID: Thanks! As of now, what is the latest version of openssl supporting FIPS, then? Regards, Jorge Bustamante On Mon, Feb 12, 2018 at 2:59 PM, Salz, Rich via openssl-users < openssl-users at openssl.org> wrote: > FIPS is not supported in 1.1.0. We will be starting a FIPS project soon, > targeted for the next release after 1.1.1 > > > > -- > openssl-users mailing list > To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta. > openssl.org_mailman_listinfo_openssl-2Dusers&d=DwICAg&c= > uiYkEnhlQB0H-gDwErXr4Q&r=RP7vLFuQAV6x9QjDD7aXNsX-833PVK9ZMODHE20KWIs&m= > baGLjagQ1M4VKFKO7KdATRKntezbZR3Ip1m3PXoFJ18&s=bG5OHX7E- > Lc267qUg6qf8FuwrvdcT1bqcD5zOq19wa0&e= > > -- This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it. Ce message confidentiel et les ?ventuelles pi?ces jointes sont ? l?usage exclusif de son ou de sa destinataire. Il est interdit, pour toute autre personne, de le distribuer, d?en d?voiler le contenu ou de le reproduire. Si vous avez re?u cette communication par erreur, veuillez en informer imm?diatement l?exp?diteur par courrier ?lectronique et d?truire l?original de ce message ainsi que toute copie. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Mar 20 17:18:32 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 20 Mar 2018 17:18:32 +0000 Subject: [openssl-users] Forthcoming OpenSSL releases Message-ID: Forthcoming OpenSSL releases ============================ The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.1.0h and 1.0.2o. These releases will be made available on 27th March 2018 between approximately 1300-1700 UTC. These are security-fix releases. The highest severity issue fixed in these releases is MODERATE. Yours The OpenSSL Project Team -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 480 bytes Desc: OpenPGP digital signature URL: From hemantha.beecherla at hpe.com Tue Mar 20 21:08:07 2018 From: hemantha.beecherla at hpe.com (Beecherla, Hemantha) Date: Tue, 20 Mar 2018 21:08:07 +0000 Subject: [openssl-users] Migrating to openssl 1.1.0 Message-ID: Hi There, I am trying to migrate my application(OpenHPI) to Openssl 1.1.0g-2, and getting few linker error when I compile my sources with openssl 1.1.0g-2. I checked the ssl header files in /usr/include/openssl/ and I can clearly see this functions visible in the header files. Also checked the openssl 1.1.0 man pages for this function and found that there are no changes to these functions. But when I compile my sources I am getting below errors, could you please guide me how to fix this errors. Thank you very much in advance. /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `SSL_CTX_free' /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `SSL_get_error' /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `SSL_get_fd' /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `SSL_read' /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `SSL_shutdown' /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `OPENSSL_init_ssl' /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `SSL_CTX_new' /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `BIO_f_ssl' /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `TLS_client_method' /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `SSL_CTX_set_default_verify_paths' /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `SSL_CTX_set_options' /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `SSL_connect' /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `SSL_free' /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `SSL_write' /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `SSL_set_fd' /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `SSL_new' collect2: error: ld returned 1 exit status make[3]: *** [openhpid] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Thanks, Hemantha Reddy -------------- next part -------------- An HTML attachment was scrubbed... URL: From dclarke at blastwave.org Tue Mar 20 21:55:20 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 20 Mar 2018 17:55:20 -0400 Subject: [openssl-users] OpenSSL version 1.1.1 pre release 3 published In-Reply-To: <20180320140913.GA11276@openssl.org> References: <20180320140913.GA11276@openssl.org> Message-ID: <0cceaa91-aba6-92e0-9eb8-4610b249973c@blastwave.org> On 20/03/18 10:09 AM, OpenSSL wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > OpenSSL version 1.1.1 pre release 3 (beta) > =========================================== > > OpenSSL - The Open Source toolkit for SSL/TLS > https://www.openssl.org/ > > OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 3 has now > been made available. For details of changes and known issues see the > release notes at: Builds and tests clean on Solaris 10 sparc with Oracle Studio 12.6 compilers and as a 64-bit build. However one must have a recent and decent perl on hand. Also this was a debug build and a I did tweak the cflags in Configurations/10-main.conf slightly. n0$ /usr/local/bin/perl ./Configure solaris64-sparcv9-cc . . . All tests successful. Files=146, Tests=1335, 341 wallclock secs ( 7.37 usr 0.94 sys + 243.40 cusr 27.79 csys = 279.50 CPU) Result: PASS gmake[1]: Leaving directory `/usr/local/build/openssl-1.1.1-pre3_SunOS5.10_sparcv9.001' n0$ uname -a SunOS node000 5.10 Generic_150400-59 sun4u sparc SUNW,SPARC-Enterprise n0$ psrinfo -pv The physical processor has 8 virtual processors (0-7) SPARC64-VII+ (portid 1024 impl 0x7 ver 0xa1 clock 2860 MHz) n0$ cc -V cc: Studio 12.6 Sun C 5.15 SunOS_sparc 2017/05/30 Resultant binary is faster than the Oracle provided bins for a few things and that is a surprise : n0$ /usr/bin/sparcv9/openssl version OpenSSL 1.0.2n 7 Dec 2017 n0$ /usr/bin/sparcv9/openssl speed rsa4096 Doing 4096 bit private rsa's for 10s: 86 4096 bit private RSA's in 10.06s Doing 4096 bit public rsa's for 10s: 5898 4096 bit public RSA's in 10.00s OpenSSL 1.0.2n 7 Dec 2017 built on: date not available options:bn(64,32) md2(int) rc4(ptr,int) des(ptr,risc1,16,int) aes(partial) blowfish(ptr) compiler: information not available sign verify sign/s verify/s rsa 4096 bits 0.116977s 0.001695s 8.5 589.8 However this big fat debug binary for 1.1.1-pre3 : n0$ n0$ LD_LIBRARY_PATH=`pwd` ./apps/openssl version OpenSSL 1.1.1-pre3 (beta) 20 Mar 2018 n0$ LD_LIBRARY_PATH=`pwd` ./apps/openssl speed rsa4096 Doing 4096 bit private rsa's for 10s: 122 4096 bit private RSA's in 10.07s Doing 4096 bit public rsa's for 10s: 8422 4096 bit public RSA's in 9.99s OpenSSL 1.1.1-pre3 (beta) 20 Mar 2018 built on: Tue Mar 20 21:08:33 2018 UTC options:bn(64,32) rc4(char) des(int) aes(partial) idea(int) blowfish(ptr) compiler: /opt/developerstudio12.6/bin/cc -KPIC -g -xs -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xarch=sparc -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -xstrconst -Xa -fast -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s -xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -xarch=sparc -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -DFILIO_H -DB_ENDIAN -DBN_DIV2W -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG -I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO sign verify sign/s verify/s rsa 4096 bits 0.082541s 0.001186s 12.1 843.0 n0$ neato. Dennis From openssl-users at dukhovni.org Wed Mar 21 00:03:33 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 20 Mar 2018 20:03:33 -0400 Subject: [openssl-users] OpenSSL version 1.1.1 pre release 3 published In-Reply-To: <0cceaa91-aba6-92e0-9eb8-4610b249973c@blastwave.org> References: <20180320140913.GA11276@openssl.org> <0cceaa91-aba6-92e0-9eb8-4610b249973c@blastwave.org> Message-ID: > On Mar 20, 2018, at 5:55 PM, Dennis Clarke wrote: > > sign verify sign/s verify/s > rsa 4096 bits 0.082541s 0.001186s 12.1 843.0 That seems remarkably slow, is that expected with this CPU? My laptop (PowerBook pro) is a 12 to 13 times faster: Doing 4096 bit private rsa's for 10s: 1566 4096 bit private RSA's in 9.99s Doing 4096 bit public rsa's for 10s: 102768 4096 bit public RSA's in 9.99s OpenSSL 1.1.1-pre4-dev xx XXX xxxx built on: Tue Mar 20 22:07:47 2018 UTC options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr) compiler: cc -fPIC -arch x86_64 -Qunused-arguments -O3 -Wall -DL_ENDIAN -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG sign verify sign/s verify/s rsa 4096 bits 0.006379s 0.000097s 156.8 10287.1 -- Viktor. -- Viktor. From pdfe at sapo.pt Wed Mar 21 00:45:45 2018 From: pdfe at sapo.pt (RTT) Date: Wed, 21 Mar 2018 00:45:45 +0000 Subject: [openssl-users] Windows shared libraries version information needs some fixes Message-ID: <8e29b843-db9a-3c9e-f71b-ad6361e0eba1@sapo.pt> Hello, Building the shared libraries (version 1.1.1 pre 3) for Windows with Visual Studio, targets VC-WIN32 or VC-WIN64A, result in DLLs with version information with outdated copyright date, i.e. "Copyright 1998-2016 The OpenSSL Authors. All rights reserved", and the file description as "OpenSSL application" instead of "OpenSSL shared library". The version information resource file seems to be generated by the script "util\mkrc.pl", that indeed has this old copyright date hardcoded, and the logic that selects the file description that seems to expect a call with a file extension (i.e. mkrc.pl libcrypto.dll, mkrc.pl openssl.exe, ...), but the build.info file is not specifying any file extension to these calls. Also, why the openssl.exe doesn't include version information? From rsalz at akamai.com Wed Mar 21 02:08:30 2018 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 21 Mar 2018 02:08:30 +0000 Subject: [openssl-users] Windows shared libraries version information needs some fixes In-Reply-To: <8e29b843-db9a-3c9e-f71b-ad6361e0eba1@sapo.pt> References: <8e29b843-db9a-3c9e-f71b-ad6361e0eba1@sapo.pt> Message-ID: <2B52A600-141A-4021-A512-44FC68CC41B1@akamai.com> Please look at https://github.com/openssl/openssl/pull/5704 and see if it fixes the issues. ?On 3/20/18, 8:52 PM, "RTT" wrote: Hello, Building the shared libraries (version 1.1.1 pre 3) for Windows with Visual Studio, targets VC-WIN32 or VC-WIN64A, result in DLLs with version information with outdated copyright date, i.e. "Copyright 1998-2016 The OpenSSL Authors. All rights reserved", and the file description as "OpenSSL application" instead of "OpenSSL shared library". The version information resource file seems to be generated by the script "util\mkrc.pl", that indeed has this old copyright date hardcoded, and the logic that selects the file description that seems to expect a call with a file extension (i.e. mkrc.pl libcrypto.dll, mkrc.pl openssl.exe, ...), but the build.info file is not specifying any file extension to these calls. Also, why the openssl.exe doesn't include version information? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From levitte at openssl.org Wed Mar 21 03:39:37 2018 From: levitte at openssl.org (Richard Levitte) Date: Wed, 21 Mar 2018 04:39:37 +0100 (CET) Subject: [openssl-users] Migrating to openssl 1.1.0 In-Reply-To: References: Message-ID: <20180321.043937.722888578003937820.levitte@openssl.org> It would help if you showed us the exact command that ended up with that bunch of errors... however, having seen this before, I'm going to venture a guess that you either didn't include '-lssl' in your linking command, or got the order between '-lcrypto' and '-lssl' wrong. However, seeing the actual command will help clear this, rather than having to guss... Cheers, Richard In message on Tue, 20 Mar 2018 21:08:07 +0000, "Beecherla, Hemantha" said: hemantha.beecherla> Hi There, hemantha.beecherla> hemantha.beecherla> I am trying to migrate my application(OpenHPI) to hemantha.beecherla> Openssl 1.1.0g-2, and getting few linker error hemantha.beecherla> when I compile my sources with openssl 1.1.0g-2. hemantha.beecherla> hemantha.beecherla> I checked the ssl header files in hemantha.beecherla> /usr/include/openssl/ and I can clearly see this hemantha.beecherla> functions visible in the header files. hemantha.beecherla> hemantha.beecherla> Also checked the openssl 1.1.0 man pages for this hemantha.beecherla> function and found that there are no changes to hemantha.beecherla> these functions. hemantha.beecherla> hemantha.beecherla> But when I compile my sources I am getting below hemantha.beecherla> errors, could you please guide me how to fix this hemantha.beecherla> errors. hemantha.beecherla> hemantha.beecherla> Thank you very much in advance. hemantha.beecherla> hemantha.beecherla> /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `SSL_CTX_free' hemantha.beecherla> hemantha.beecherla> /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `SSL_get_error' hemantha.beecherla> hemantha.beecherla> /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `SSL_get_fd' hemantha.beecherla> hemantha.beecherla> /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `SSL_read' hemantha.beecherla> hemantha.beecherla> /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `SSL_shutdown' hemantha.beecherla> hemantha.beecherla> /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to hemantha.beecherla> `OPENSSL_init_ssl' hemantha.beecherla> hemantha.beecherla> /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `SSL_CTX_new' hemantha.beecherla> hemantha.beecherla> /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `BIO_f_ssl' hemantha.beecherla> hemantha.beecherla> /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to hemantha.beecherla> `TLS_client_method' hemantha.beecherla> hemantha.beecherla> /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to hemantha.beecherla> `SSL_CTX_set_default_verify_paths' hemantha.beecherla> hemantha.beecherla> /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to hemantha.beecherla> `SSL_CTX_set_options' hemantha.beecherla> hemantha.beecherla> /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `SSL_connect' hemantha.beecherla> hemantha.beecherla> /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `SSL_free' hemantha.beecherla> hemantha.beecherla> /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `SSL_write' hemantha.beecherla> hemantha.beecherla> /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `SSL_set_fd' hemantha.beecherla> hemantha.beecherla> /home/hemanth/hemanth/trunk/ssl/.libs/libopenhpi_ssl.so: undefined reference to `SSL_new' hemantha.beecherla> hemantha.beecherla> collect2: error: ld returned 1 exit status hemantha.beecherla> hemantha.beecherla> make[3]: *** [openhpid] Error 1 hemantha.beecherla> hemantha.beecherla> make[2]: *** [all-recursive] Error 1 hemantha.beecherla> hemantha.beecherla> make[1]: *** [all-recursive] Error 1 hemantha.beecherla> hemantha.beecherla> make: *** [all] Error 2 hemantha.beecherla> hemantha.beecherla> Thanks, hemantha.beecherla> hemantha.beecherla> Hemantha Reddy hemantha.beecherla> From maddi.nivedita at gmail.com Wed Mar 21 05:30:57 2018 From: maddi.nivedita at gmail.com (Nivedita) Date: Wed, 21 Mar 2018 11:00:57 +0530 Subject: [openssl-users] DTLS over UDP In-Reply-To: References: <10616.1518547870@obiwan.sandelman.ca> <5049.1518629142@obiwan.sandelman.ca> <12591.1519065788@obiwan.sandelman.ca> Message-ID: Hi Michael, Would you please let me know whether this new release of openssl-1.1.1-pre3 supports DTLS over udp for SIP protocol using dtlsv1_accept method. Regards, Nivedita On Wed, Feb 21, 2018 at 11:54 AM, Nivedita wrote: > Hi Michael, > > Please find the response inline and also i have attached the pcap for your > reference. > > ip.src ==22.33.40.20 is the search criteria for pcap dump. > Regards, > Nivedita > > On Tue, Feb 20, 2018 at 12:13 AM, Michael Richardson > wrote: > >> >> Nivedita wrote: >> >> Nivedita wrote: >> >> >>> I am trying to establish DTLS over UDP connection by using >> >>> DTLSv1_listen method . >> >> >>> I have followed the below steps - 1. Created a server socket >> >>> and using >> >>> this socket created bio and ssl object. bio = >> >>> BIO_new_dgram(VI_sock,BIO_NOCLOSE)) SSL_set_bio >> >>> (ssl,VP_bio,VP_bio); >> >> >>> 2. Enable cookie exchange on SSL object. SSL_set_options(ssl, >> >>> SSL_OP_COOKIE_EXCHANGE); >> >> >>> 3. Then started listening using dtlsv1_listen for the new >> >>> client >> >>> connections. Once dtlsv1_listen is successful and i got the >> >>> peer >> >>> address. >> >> mcr> okay. >> >> >> >> Nivedita- All the above mentioned steps i am doing on server >> >> side . On the >> >> client side i have already initiated ssl_connect. >> >> On the server side when i am listening using dtlsv1_listen >> >> method - >> >> >>> 4. Once i got the peer address , i am creating one more socket >> >>> 5. With the new socket i tried to connect to peer address. >> >> >> Then once i got the client address from the dtlsv1_listen method, >> >> i am creating one more socket and trying to connect to this client >> >> address. >> >> >I think that I see what is wrong with your flow... you haven't taken the >> >packet off the original socket, so SSL_accept is still looking for it. >> >> >The flow is supposed to be: >> > 1) client sends ClientHello >> Nivedita- Client is sending the client hello. >> > > >> >2) DTLSv1_listen() sees it, and sends a HelloVerifyRequest >> > (I assume you have filled in the cookie callbacks. I think that >> > perhaps there should be good cryptographic defaults available in >> >the library. Maybe there are, and I'm ignorant of them) >> >> Nivedita- Yes, I have attached all the cookies and server is > responding with hello verify request. > > >> > 3) Client sends ClientHello w/cookie. >> > DTLSv1_listen() then sees that and tweaks the SSL* to indicate that >> > the cookie has been accepted. Note that the packet is *LEFT* >> > on the incoming socket so that SSL_accept() can process it. >> > This is one the places where the DTLSv1_listen() API is rather >> > hard to use in my opinion. >> > Nivedita- Now after Hello verify request is done, client sends the > client hello with cookie. > Now i have done SSL_accept on the same server > socket.[ means the same socket on which dtlsv1_listen was triggered] > >> >> > 4) You make up new sockets, etc. >> > Nivedita- After ssl_accept is done , i have created one more > socket, and tried to connect to client addr and set the bio on the new > socket. > > VI_sock_id = socket(client_addr.ss_family,SOCK_DGRAM,0); > > VI_status = connect(VI_sock_id, (struct sockaddr > *)&client_addr, sizeof(struct sockaddr_storage)); > >> > > > >> > 5) But, you need to call SSL_accept() once with the **old socket** to >> > process packet that listen() left on it, and then you can switch >> the >> > FD over! Of course, you probably want to make sure that >> SSL_accept() >> > sends the reply correctly. >> > > Nivedita- As suggested i have done the ssl_accept on the same socket > on which dtlsv1_listen was triggered. > After ssl_accept i am trying to change the fd , so > that the incoming data should come to new fd , instead of old one. But > still traffic is coming on old fd[dtlsv1 fd] > > VI_res = SSL_accept(VP_ssl); > VI_res = BIO_set_fd(SSL_get_rbio(VP_ > ssl),VI_sock_id,BIO_NOCLOSE); > VI_res = BIO_ctrl(SSL_get_rbio(VP_ssl),BIO_CTRL_DGRAM_SET_CONNECTED, > 0, &client_addr); > > Please let me know your inputs i, so that traffic has to move from > old fd to new fd. > > >> What I do in my proposed DTLSv1_accept() API is that I move the data >> From the incoming socket to the new BIO's incoming queue: >> https://github.com/mcr/openssl/blob/dtls-listen-refactor/ >> ssl/d1_lib.c#L964 >> >> /* At this point, there is a real ClientHello in serv->init_buf */ >> memcpy(rb->buf, serv->init_buf->data, serv->init_num); >> rb->offset = 0; >> rb->left = serv->init_num; >> >> and then remove the packet from the incoming socket. The situation is >> then returned like this so that the new sockets can be setup, but the >> incoming SSL_accept() BIO is stuffed with the correct (cookie-full) >> ClientHello, and replies will go to the right place with the right source >> address. I hope to get these patches accepted for the March 11 freeze, >> but you might not want to depend upon it. >> >> >> -- >> ] Never tell me the odds! | ipv6 mesh >> networks [ >> ] Michael Richardson, Sandelman Software Works | network >> architect [ >> ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on >> rails [ >> >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Mar 21 09:36:30 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 21 Mar 2018 09:36:30 +0000 Subject: [openssl-users] Windows shared libraries version information needs some fixes In-Reply-To: <8e29b843-db9a-3c9e-f71b-ad6361e0eba1@sapo.pt> References: <8e29b843-db9a-3c9e-f71b-ad6361e0eba1@sapo.pt> Message-ID: <79475988-c4de-25e7-e475-d49ed28837dd@openssl.org> On 21/03/18 00:45, RTT wrote: > Hello, > > Building the shared libraries (version 1.1.1 pre 3) for Windows with > Visual Studio, targets VC-WIN32 or VC-WIN64A, result in DLLs with > version information with outdated copyright date, i.e. "Copyright > 1998-2016 The OpenSSL Authors. All rights reserved", and the file > description as "OpenSSL application" instead of "OpenSSL shared library". > > The version information resource file seems to be generated by the > script "util\mkrc.pl", that indeed has this old copyright date > hardcoded, and the logic that selects the file description that seems to > expect a call with a file extension (i.e. mkrc.pl libcrypto.dll, mkrc.pl > openssl.exe, ...), but the build.info file is not specifying any file > extension to these calls. > > Also, why the openssl.exe doesn't include version information? > Please could you raise this as an issue on github so that it gets properly tracked? https://github.com/openssl/openssl/issues Thanks Matt From matt at openssl.org Wed Mar 21 09:55:59 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 21 Mar 2018 09:55:59 +0000 Subject: [openssl-users] Windows shared libraries version information needs some fixes In-Reply-To: <79475988-c4de-25e7-e475-d49ed28837dd@openssl.org> References: <8e29b843-db9a-3c9e-f71b-ad6361e0eba1@sapo.pt> <79475988-c4de-25e7-e475-d49ed28837dd@openssl.org> Message-ID: <5a14195b-6660-0c06-3691-b092a73990b9@openssl.org> On 21/03/18 09:36, Matt Caswell wrote: > > > On 21/03/18 00:45, RTT wrote: >> Hello, >> >> Building the shared libraries (version 1.1.1 pre 3) for Windows with >> Visual Studio, targets VC-WIN32 or VC-WIN64A, result in DLLs with >> version information with outdated copyright date, i.e. "Copyright >> 1998-2016 The OpenSSL Authors. All rights reserved", and the file >> description as "OpenSSL application" instead of "OpenSSL shared library". >> >> The version information resource file seems to be generated by the >> script "util\mkrc.pl", that indeed has this old copyright date >> hardcoded, and the logic that selects the file description that seems to >> expect a call with a file extension (i.e. mkrc.pl libcrypto.dll, mkrc.pl >> openssl.exe, ...), but the build.info file is not specifying any file >> extension to these calls. >> >> Also, why the openssl.exe doesn't include version information? >> > > Please could you raise this as an issue on github so that it gets > properly tracked? > > https://github.com/openssl/openssl/issues Ignore this. I see Rich has already created a PR to fix this. Matt From dclarke at blastwave.org Wed Mar 21 12:22:52 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Wed, 21 Mar 2018 08:22:52 -0400 Subject: [openssl-users] OpenSSL version 1.1.1 pre release 3 published In-Reply-To: References: <20180320140913.GA11276@openssl.org> <0cceaa91-aba6-92e0-9eb8-4610b249973c@blastwave.org> Message-ID: On 20/03/18 08:03 PM, Viktor Dukhovni wrote: > > >> On Mar 20, 2018, at 5:55 PM, Dennis Clarke wrote: >> >> sign verify sign/s verify/s >> rsa 4096 bits 0.082541s 0.001186s 12.1 843.0 > > That seems remarkably slow, is that expected with this CPU? > My laptop (PowerBook pro) is a 12 to 13 times faster: > > Doing 4096 bit private rsa's for 10s: 1566 4096 bit private RSA's in 9.99s > Doing 4096 bit public rsa's for 10s: 102768 4096 bit public RSA's in 9.99s > OpenSSL 1.1.1-pre4-dev xx XXX xxxx > built on: Tue Mar 20 22:07:47 2018 UTC > options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr) > compiler: cc -fPIC -arch x86_64 -Qunused-arguments -O3 -Wall -DL_ENDIAN -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -D_REENTRANT -DNDEBUG > sign verify sign/s verify/s > rsa 4096 bits 0.006379s 0.000097s 156.8 10287.1 > You want to see slow ? Let me show you slow : root at phobos:~# uname -r 4.15.9-genunix root at phobos:~# cat /etc/debian_version buster/sid root at phobos:~# /usr/bin/openssl version OpenSSL 1.1.0g 2 Nov 2017 root at phobos:~# /usr/bin/openssl speed rsa4096 Doing 4096 bit private rsa's for 10s: 12 4096 bit private RSA's in 10.74s Doing 4096 bit public rsa's for 10s: 765 4096 bit public RSA's in 10.00s OpenSSL 1.1.0g 2 Nov 2017 built on: reproducible build, date unspecified options:bn(64,32) rc4(4x,int) des(long) aes(partial) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/i386-linux-gnu/engines-1.1\"" sign verify sign/s verify/s rsa 4096 bits 0.895000s 0.013072s 1.1 76.5 Now that is slow. However I have a sparc unit that reports "inf" or infinite speed so one never really knows what one will get. Dennis From jan.m.danielsson at gmail.com Wed Mar 21 13:42:22 2018 From: jan.m.danielsson at gmail.com (Jan Danielsson) Date: Wed, 21 Mar 2018 14:42:22 +0100 Subject: [openssl-users] Hashing public keys Message-ID: Hello, Given an EVP_PKEY (can contain either RSA or EC key), is there a function to generate a hash of the public key? (I have some vague memory of having read a few years ago that there wasn't any standardized way to hashing EC keys (+parameters) yet. If so; has this been remedied?). (Storing public keys in a DHT, users need to be able to - given a public key - generate a hash to check if the hash exists in the DHT). -- Kind Regards, Jan Danielsson From Matthias.St.Pierre at ncp-e.com Wed Mar 21 20:33:03 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 21 Mar 2018 21:33:03 +0100 Subject: [openssl-users] Hashing public keys In-Reply-To: References: Message-ID: <5fe1752f-7013-ef66-9f7e-b8d9de4e5b45@ncp-e.com> Hello Jan, the canonical way to create the hash of the public key is to use d2i_PUBKEY() to save the public key in (binary) DER format and then calculate the hash of that using EVP_DigestInit()/EVP_DigestUpdate()/EVP_DigestFinal(). Hope that helps, Matthias Am 21.03.2018 um 14:42 schrieb Jan Danielsson: > Hello, > > Given an EVP_PKEY (can contain either RSA or EC key), is there a > function to generate a hash of the public key? (I have some vague > memory of having read a few years ago that there wasn't any standardized > way to hashing EC keys (+parameters) yet. If so; has this been remedied?). > > (Storing public keys in a DHT, users need to be able to - given a > public key - generate a hash to check if the hash exists in the DHT). > From madwolf at openca.org Wed Mar 21 16:26:13 2018 From: madwolf at openca.org (Dr. Pala) Date: Wed, 21 Mar 2018 16:26:13 +0000 Subject: [openssl-users] Hashing public keys In-Reply-To: References: Message-ID: <4a8d2ae7-c0df-3945-2280-09f581395b42@openca.org> Hi Jan, not sure if this might help you, I solved the problem by using X509_PUBKEY + i2d_X509_PUBKEY. Here's an example: ??? https://github.com/openca/libpki/blob/b87b647170cb5f71e00baffe609f5a02edfa3845/src/openssl/pki_keypair.c#L307 I hope that helps, Cheers, Max On 3/21/18 1:42 PM, Jan Danielsson wrote: > Hello, > > Given an EVP_PKEY (can contain either RSA or EC key), is there a > function to generate a hash of the public key? (I have some vague > memory of having read a few years ago that there wasn't any standardized > way to hashing EC keys (+parameters) yet. If so; has this been remedied?). > > (Storing public keys in a DHT, users need to be able to - given a > public key - generate a hash to check if the hash exists in the DHT). > From pdfe at sapo.pt Thu Mar 22 00:19:14 2018 From: pdfe at sapo.pt (RTT) Date: Thu, 22 Mar 2018 00:19:14 +0000 Subject: [openssl-users] Windows shared libraries version information needs some fixes In-Reply-To: <2B52A600-141A-4021-A512-44FC68CC41B1@akamai.com> References: <8e29b843-db9a-3c9e-f71b-ad6361e0eba1@sapo.pt> <2B52A600-141A-4021-A512-44FC68CC41B1@akamai.com> Message-ID: <3fdfcf9c-055c-aa55-f609-41dd9fc669b4@sapo.pt> After your forth commit, seems all is working fine. Exe and dlls with, and correct, version information now. Thanks. On 21/03/2018 02:08, Salz, Rich via openssl-users wrote: > Please look athttps://github.com/openssl/openssl/pull/5704 and see if it fixes the issues. From norm.green at gemtalksystems.com Thu Mar 22 03:34:48 2018 From: norm.green at gemtalksystems.com (Norm Green) Date: Wed, 21 Mar 2018 20:34:48 -0700 Subject: [openssl-users] Certificate Revocation List and SSL Message-ID: How does one specify the CRL to the SSL_CTX when setting up a connection?? I would expect there to be something similar to SSL_CTX_use_certificate(), such as: int SSL_CTX_use_crl(SSL_CTX *ctx, X509_CRL *crl) but can nothing like that. Norm Green From jgh at wizmail.org Thu Mar 22 10:04:39 2018 From: jgh at wizmail.org (Jeremy Harris) Date: Thu, 22 Mar 2018 10:04:39 +0000 Subject: [openssl-users] Certificate Revocation List and SSL In-Reply-To: References: Message-ID: <484652d7-be0c-5167-d5eb-687bcb59f894@wizmail.org> On 22/03/18 03:34, Norm Green wrote: > How does one specify the CRL to the SSL_CTX when setting up a > connection?? I would expect there to be something similar to > SSL_CTX_use_certificate(), such as: > > int SSL_CTX_use_crl(SSL_CTX *ctx, X509_CRL *crl) X509_STORE_load_locations() ? It appears to know that the content is CRL. -- Cheers, Jeremy From beldmit at gmail.com Thu Mar 22 16:55:06 2018 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 22 Mar 2018 19:55:06 +0300 Subject: [openssl-users] ARM native compiler Message-ID: Hello, Has anybody tried to build OpenSSL using ARM C compiler (armcc/armclang) and got a success? Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From maddi.nivedita at gmail.com Fri Mar 23 07:10:09 2018 From: maddi.nivedita at gmail.com (Nivedita) Date: Fri, 23 Mar 2018 12:40:09 +0530 Subject: [openssl-users] DTLS over UDP In-Reply-To: <14991.1521653664@dooku.sandelman.ca> References: <10616.1518547870@obiwan.sandelman.ca> <5049.1518629142@obiwan.sandelman.ca> <12591.1519065788@obiwan.sandelman.ca> <14991.1521653664@dooku.sandelman.ca> Message-ID: Hi Michael, We are working on SIP , and i am looking for dtlsv1_accept method so that when multiple clients want to connect to single server, dtls should open a separate port for each client instance, when running over udp. Regards, Nivedita On Wed, Mar 21, 2018 at 11:04 PM, Michael Richardson wrote: > > Nivedita wrote: > > Would you please let me know whether this new release of > > openssl-1.1.1-pre3 supports DTLS over udp for SIP protocol using > > dtlsv1_accept method. > > No. I will be rebasing very soon. > (I'm a contributor like you) > > Even the basic BIO patches that I was working on were not yet accepted, as > I > guess I need to validate that it compiles on VMS. > I hope to get an accout soon that I can use to verify things. > > BTW: Are you speaking about *SIP* or *RTP? My impression is that the > existing API was designed specifically for SRTP. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nospam001-lists at jan-kohnert.de Fri Mar 23 17:03:17 2018 From: nospam001-lists at jan-kohnert.de (Jan Kohnert) Date: Fri, 23 Mar 2018 18:03:17 +0100 Subject: [openssl-users] File signing/encrypting upgrade from 1.0.2 to 1.1.0 Message-ID: Hello, I'm using the openssl-libs for signing/encrypting files in PKCS#7 format. When trying to upgrade from 1.0.2 to 1.1.0 the code stops working properly: Files are generated, but the formating is broken. When trying to decrypt the generated files, I get: Error in encoding 6252:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:crypto\asn1\asn1_lib.c:91: (that's it, really). Could you please point me to what I'm missing? I have tried to find something useful in changslogs and docs, but I couldn't find a helping hint (and I don't really know what t look for, too) I have made a minimal working example as well as a small testfile and test key/cert in the attached zip-file (should compile on all platforms supported by openssl). But beware: absolutly *no* error-checking at all in there, it is assumed, all is in the same place, testfile, key, cert, and program. Thanks a lot, and a happy weekend! :) -- MfG Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: TestCrypt.zip Type: application/zip Size: 4940 bytes Desc: not available URL: From nospam001-lists at jan-kohnert.de Fri Mar 23 18:25:32 2018 From: nospam001-lists at jan-kohnert.de (Jan Kohnert) Date: Fri, 23 Mar 2018 19:25:32 +0100 Subject: [openssl-users] File signing/encrypting upgrade from 1.0.2 to 1.1.0 In-Reply-To: References: Message-ID: <20180323192532.21d09104@jan-kohnert.de> Hi again, Am Fri, 23 Mar 2018 18:03:17 +0100 schrieb Jan Kohnert : > I'm using the openssl-libs for signing/encrypting files in PKCS#7 > format. When trying to upgrade from 1.0.2 to 1.1.0 the code stops > working properly: Files are generated, but the formating is broken. > When trying to decrypt the generated files, I get: > > Error in encoding > 6252:error:0D07209B:asn1 encoding routines:ASN1_get_object:too > long:crypto\asn1\asn1_lib.c:91: I just compiled the code on Linux (with the small changes to let it compile and link), and it works for 1.1.0g, so it seems to be a Windows-specific problem (I can reproduce that in 32 and 64bit Win). Bug? Best regards, Jan From rsalz at akamai.com Fri Mar 23 18:32:28 2018 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 23 Mar 2018 18:32:28 +0000 Subject: [openssl-users] File signing/encrypting upgrade from 1.0.2 to 1.1.0 In-Reply-To: <20180323192532.21d09104@jan-kohnert.de> References: <20180323192532.21d09104@jan-kohnert.de> Message-ID: How big is the file? Could it be bigger than 32 vs 64 bit platforms? From sfhacker at hotmail.com Fri Mar 23 18:45:22 2018 From: sfhacker at hotmail.com (Sergio NNX) Date: Fri, 23 Mar 2018 18:45:22 +0000 Subject: [openssl-users] File signing/encrypting upgrade from 1.0.2 to 1.1.0 In-Reply-To: <20180323192532.21d09104@jan-kohnert.de> References: , <20180323192532.21d09104@jan-kohnert.de> Message-ID: I've just built it (manually) on Windows and I don't see any error messages. A few points/questions: - Why cmake? - I does not build/compile at all. - Why is this line here: #include ? I get a compilation error! ? - Why are we adding these libraries: odbc32 advapi32 ? CMake Error at CMakeLists.txt:9 (find_package): By not providing "FindOpenSSLSyn.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "OpenSSLSyn", but CMake did not find one. Could not find a package configuration file provided by "OpenSSLSyn" (requested version 1.1.0) with any of the following names: OpenSSLSynConfig.cmake opensslsyn-config.cmake Add the installation prefix of "OpenSSLSyn" to CMAKE_PREFIX_PATH or set "OpenSSLSyn_DIR" to a directory containing one of the above files. If "OpenSSLSyn" provides a separate development package or SDK, be sure it has been installed. -- Configuring incomplete, errors occurred! ________________________________ From: openssl-users on behalf of Jan Kohnert Sent: Saturday, 24 March 2018 5:25 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] File signing/encrypting upgrade from 1.0.2 to 1.1.0 Hi again, Am Fri, 23 Mar 2018 18:03:17 +0100 schrieb Jan Kohnert : > I'm using the openssl-libs for signing/encrypting files in PKCS#7 > format. When trying to upgrade from 1.0.2 to 1.1.0 the code stops > working properly: Files are generated, but the formating is broken. > When trying to decrypt the generated files, I get: > > Error in encoding > 6252:error:0D07209B:asn1 encoding routines:ASN1_get_object:too > long:crypto\asn1\asn1_lib.c:91: I just compiled the code on Linux (with the small changes to let it compile and link), and it works for 1.1.0g, so it seems to be a Windows-specific problem (I can reproduce that in 32 and 64bit Win). Bug? Best regards, Jan -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users openssl-users Info Page mta.openssl.org This mailing list is for discussion among those using the OpenSSL software. To see the collection of prior postings to the list, visit the openssl-users Archives -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Mar 23 20:08:35 2018 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 23 Mar 2018 20:08:35 +0000 Subject: [openssl-users] File signing/encrypting upgrade from 1.0.2 to 1.1.0 In-Reply-To: <20180323194138.091dd5c3@jan-kohnert.de> References: <20180323192532.21d09104@jan-kohnert.de> <20180323194138.091dd5c3@jan-kohnert.de> Message-ID: Did you specify the -md flag on either/both? https://www.openssl.org/docs/faq.html#USER3 From matt at openssl.org Fri Mar 23 21:14:30 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 23 Mar 2018 21:14:30 +0000 Subject: [openssl-users] File signing/encrypting upgrade from 1.0.2 to 1.1.0 In-Reply-To: <20180323192532.21d09104@jan-kohnert.de> References: <20180323192532.21d09104@jan-kohnert.de> Message-ID: <6cc8034c-b41c-d6c4-3386-99456fa3eb94@openssl.org> Your minimal working example only does the encrypt side. Please could you show the decrypt side too that demonstrates the error. Matt On 23/03/18 18:25, Jan Kohnert wrote: > Hi again, > > Am Fri, 23 Mar 2018 18:03:17 +0100 > schrieb Jan Kohnert : > >> I'm using the openssl-libs for signing/encrypting files in PKCS#7 >> format. When trying to upgrade from 1.0.2 to 1.1.0 the code stops >> working properly: Files are generated, but the formating is broken. >> When trying to decrypt the generated files, I get: >> >> Error in encoding >> 6252:error:0D07209B:asn1 encoding routines:ASN1_get_object:too >> long:crypto\asn1\asn1_lib.c:91: > > I just compiled the code on Linux (with the small changes to let it > compile and link), and it works for 1.1.0g, so it seems to be a > Windows-specific problem (I can reproduce that in 32 and 64bit Win). > Bug? > > Best regards, Jan > From matt at openssl.org Fri Mar 23 21:22:02 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 23 Mar 2018 21:22:02 +0000 Subject: [openssl-users] File signing/encrypting upgrade from 1.0.2 to 1.1.0 In-Reply-To: References: Message-ID: On 23/03/18 17:03, Jan Kohnert wrote: > Hello, > > I'm using the openssl-libs for signing/encrypting files in PKCS#7 > format. When trying to upgrade from 1.0.2 to 1.1.0 the code stops > working properly: Files are generated, but the formating is broken. > When trying to decrypt the generated files, I get: > > Error in encoding > 6252:error:0D07209B:asn1 encoding routines:ASN1_get_object:too > long:crypto\asn1\asn1_lib.c:91: > > (that's it, really). > > Could you please point me to what I'm missing? I have tried to find > something useful in changslogs and docs, but I couldn't find a helping > hint (and I don't really know what t look for, too) > > I have made a minimal working example as well as a small testfile and > test key/cert in the attached zip-file (should compile on all platforms > supported by openssl). But beware: absolutly *no* error-checking at all > in there, it is assumed, all is in the same place, testfile, key, cert, > and program. > > Thanks a lot, and a happy weekend! :) Also what happens if you change this line: bioCryptedData = BIO_new_file("testfile.crypt", "w"); to bioCryptedData = BIO_new_file("testfile.crypt", "wb"); Matt From nospam001-lists at jan-kohnert.de Sat Mar 24 00:19:13 2018 From: nospam001-lists at jan-kohnert.de (Jan Kohnert) Date: Sat, 24 Mar 2018 01:19:13 +0100 Subject: [openssl-users] File signing/encrypting upgrade from 1.0.2 to 1.1.0 In-Reply-To: <6cc8034c-b41c-d6c4-3386-99456fa3eb94@openssl.org> References: <20180323192532.21d09104@jan-kohnert.de> <6cc8034c-b41c-d6c4-3386-99456fa3eb94@openssl.org> Message-ID: <20180324011913.37a7351e@jan-kohnert.de> Hi, Am Fri, 23 Mar 2018 21:14:30 +0000 schrieb Matt Caswell : > Your minimal working example only does the encrypt side. Please could > you show the decrypt side too that demonstrates the error. The problem is on the encryption/signing side: the signed/encrypted files are broken. A test on the files generated by the demonstration code can be done via the openssl binary: openssl smime -decrypt -inform DER -in testfile.crypt -inkey local.key -out test.s fails with the reported error for encryption/signing done using the provided code on the Windows platform for version 1.1.0. Best regards Jan From nospam001-lists at jan-kohnert.de Sat Mar 24 00:20:10 2018 From: nospam001-lists at jan-kohnert.de (Jan Kohnert) Date: Sat, 24 Mar 2018 01:20:10 +0100 Subject: [openssl-users] File signing/encrypting upgrade from 1.0.2 to 1.1.0 In-Reply-To: References: <20180323192532.21d09104@jan-kohnert.de> Message-ID: <20180324012010.2f1b1f70@jan-kohnert.de> Hi, Am Fri, 23 Mar 2018 18:32:28 +0000 schrieb "Salz, Rich via openssl-users" : > How big is the file? Could it be bigger than 32 vs 64 bit platforms? the testfile in the zip is only a few bytes. The problem exists for larger files, too (I didn't try *really* large files, though) Best regards Jan From nospam001-lists at jan-kohnert.de Sat Mar 24 00:22:21 2018 From: nospam001-lists at jan-kohnert.de (Jan Kohnert) Date: Sat, 24 Mar 2018 01:22:21 +0100 Subject: [openssl-users] File signing/encrypting upgrade from 1.0.2 to 1.1.0 In-Reply-To: References: Message-ID: <20180324012221.153aafa4@jan-kohnert.de> Am Fri, 23 Mar 2018 21:22:02 +0000 schrieb Matt Caswell : > Also what happens if you change this line: > > bioCryptedData = BIO_new_file("testfile.crypt", "w"); > > to > > bioCryptedData = BIO_new_file("testfile.crypt", "wb"); good point, thanks. I'll test that on Monday and report back. Best regards Jan From jgh at wizmail.org Sat Mar 24 18:59:20 2018 From: jgh at wizmail.org (Jeremy Harris) Date: Sat, 24 Mar 2018 18:59:20 +0000 Subject: [openssl-users] ed25519 key generation Message-ID: <4f6e9344-c7a2-2c27-f1b0-e7008bafbf64@wizmail.org> On spotting the example code in Ed25519(7) I tried it, and it segfaulted: #0 0x00007fcedd3e47e0 in PEM_write_bio_PrivateKey () from /lib64/libcrypto.so.1.1 #1 0x00007fcedd3e4afb in PEM_write_PrivateKey () from /lib64/libcrypto.so.1.1 #2 0x0000000000400744 in main () at src/ed25519_gen_privkey.c:11 This a self-built openssl from today's master. I'm unsure how to get debuginfo for it, for better detail. Given how simple PEM_write_bio_PrivateKey() is, I assume it's gone on to PEM_write_bio_PrivateKey_traditional(). Any clues? -- Thanks, Jeremy From jgh at wizmail.org Sat Mar 24 19:19:13 2018 From: jgh at wizmail.org (Jeremy Harris) Date: Sat, 24 Mar 2018 19:19:13 +0000 Subject: [openssl-users] ed25519 key generation In-Reply-To: <4f6e9344-c7a2-2c27-f1b0-e7008bafbf64@wizmail.org> References: <4f6e9344-c7a2-2c27-f1b0-e7008bafbf64@wizmail.org> Message-ID: <81a5a068-a135-9ef8-0f63-536ff07f5109@wizmail.org> On 24/03/18 18:59, Jeremy Harris wrote: > On spotting the example code in Ed25519(7) > I tried it, and it segfaulted: Cancel that. My compile wasn't picking up my fresh-built library version. -- Cheers, Jeremy From dclarke at blastwave.org Sat Mar 24 19:39:05 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Sat, 24 Mar 2018 15:39:05 -0400 Subject: [openssl-users] OpenSSL version 1.1.1 pre release 3 published In-Reply-To: References: <20180320140913.GA11276@openssl.org> <0cceaa91-aba6-92e0-9eb8-4610b249973c@blastwave.org> Message-ID: On 20/03/18 08:03 PM, Viktor Dukhovni wrote: > > >> On Mar 20, 2018, at 5:55 PM, Dennis Clarke wrote: >> >> sign verify sign/s verify/s >> rsa 4096 bits 0.082541s 0.001186s 12.1 843.0 > > That seems remarkably slow, is that expected with this CPU? I find it interesting that nearly every version of OpenSSL for the past five years will report "inf" performance on one of my sparc units : $ /usr/local/bin/openssl version OpenSSL 1.1.0g 2 Nov 2017 $ /usr/local/bin/openssl speed rsa1024 Doing 1024 bit private rsa's for 10s: 28 1024 bit private RSA's in 0.00s Doing 1024 bit public rsa's for 10s: 1964 1024 bit public RSA's in 0.00s OpenSSL 1.1.0g 2 Nov 2017 built on: reproducible build, date unspecified options:bn(64,32) rc4(char) des(int) aes(partial) idea(int) blowfish(ptr) compiler: /opt/solarisstudio12.4/bin/cc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-1.1\"" sign verify sign/s verify/s rsa 1024 bits 0.000000s 0.000000s Inf Inf $ I always find that interesting. Dennis From tanushree.banerjee at uwaterloo.ca Sat Mar 24 22:10:06 2018 From: tanushree.banerjee at uwaterloo.ca (Tanushree Banerjee) Date: Sat, 24 Mar 2018 22:10:06 +0000 Subject: [openssl-users] Request for help in research Message-ID: <102beb5ff79a4ee797c94fe24144a25f@uwaterloo.ca> Hello, I was looking for benchmarking the execution time of Elliptic Curve based Diffie Hellman of the OpenSSL implementation in C just for my own purpose of understanding. Is there any easy way to do that by coding in C ? Do you have any sample code for that ? (I have used time openssl ecparam -name secp256k1 -genkey -noout -out secp256k1-key.pem in command line. And it does give me some average timing. ) But using this I don't get timing for generation of shared secret key. Also I would like to know if affine coordinates are used or Jacobian projective coordinates are being used? Is there any way to know all these ? I also tried this code -> The code over here gives me a bunch of error https://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman Is there any other reliable source that has been used before ? If someone knows can you please forward me or let me know? That would be extremely helpful. Thank you for your patience. Thanks and regards Tanushree Banerjee Graduate Student University of Waterloo -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sat Mar 24 22:57:53 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 24 Mar 2018 18:57:53 -0400 Subject: [openssl-users] ed25519 key generation In-Reply-To: <4f6e9344-c7a2-2c27-f1b0-e7008bafbf64@wizmail.org> References: <4f6e9344-c7a2-2c27-f1b0-e7008bafbf64@wizmail.org> Message-ID: <6B832619-61BA-458A-89D8-4909E817D733@dukhovni.org> > On Mar 24, 2018, at 2:59 PM, Jeremy Harris wrote: > > On spotting the example code in Ed25519(7) FWIW, "openssl genpkey" supports "-algorithm ed25519" (not yet documented. So if you're not specifically looking to do this in C, you can use the CLI. -- Viktor. From dclarke at blastwave.org Sat Mar 24 23:15:57 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Sat, 24 Mar 2018 19:15:57 -0400 Subject: [openssl-users] Request for help in research In-Reply-To: <102beb5ff79a4ee797c94fe24144a25f@uwaterloo.ca> References: <102beb5ff79a4ee797c94fe24144a25f@uwaterloo.ca> Message-ID: <15b443f3-c5b1-2baa-6d87-da1470fff6fe@blastwave.org> On 24/03/18 06:10 PM, Tanushree Banerjee wrote: > Hello, > > I was looking for benchmarking the execution time of Elliptic Curve > based Diffie Hellman of the OpenSSL implementation in C just for my own > purpose of understanding. A few more specifics would be helpful here. > |in command line. And it does give me some average timing. )| > Your results here would be portable across systems however one would need to know the nature of the build and the architecture. I often single step through functions and thus use non-optimized debug builds which are vastly slower than a regular optimal build. Also the asm code simply does not exist on some architectures like sparc ( non T4 ) or some older powerpc types. > ||I also tried this code -> > > The code over here gives me a bunch of error That isn't too clear. How are you calling ecdh() and with what test data? > Is there any other reliable source that has been used before ? If > someone knows can you please forward me or let me know? That would be > extremely helpful. Thank you for your patience. Hey there UofW type, what rev of openssl are you using? Should I assume that you have "OpenSSL 1.1.0g 2 Nov 2017" on some reasonable architecture? Dennis Clarke number cruncher math geek From jgh at wizmail.org Sat Mar 24 23:28:53 2018 From: jgh at wizmail.org (Jeremy Harris) Date: Sat, 24 Mar 2018 23:28:53 +0000 Subject: [openssl-users] ed25519 key generation In-Reply-To: <6B832619-61BA-458A-89D8-4909E817D733@dukhovni.org> References: <4f6e9344-c7a2-2c27-f1b0-e7008bafbf64@wizmail.org> <6B832619-61BA-458A-89D8-4909E817D733@dukhovni.org> Message-ID: <417000cf-0fa6-211f-0b4b-59d9be27fdb0@wizmail.org> On 24/03/18 22:57, Viktor Dukhovni wrote: > FWIW, "openssl genpkey" supports "-algorithm ed25519" (not yet > documented. So if you're not specifically looking to do this > in C, you can use the CLI. That's certainly preferable, thanks. Is there a way yet to get the raw public-key out, documented or not? As you may guess, this is for DKIM. -- Cheers, Jeremy From rsalz at akamai.com Sat Mar 24 23:44:34 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 24 Mar 2018 23:44:34 +0000 Subject: [openssl-users] ed25519 key generation In-Reply-To: <417000cf-0fa6-211f-0b4b-59d9be27fdb0@wizmail.org> References: <4f6e9344-c7a2-2c27-f1b0-e7008bafbf64@wizmail.org> <6B832619-61BA-458A-89D8-4909E817D733@dukhovni.org> <417000cf-0fa6-211f-0b4b-59d9be27fdb0@wizmail.org> Message-ID: > Is there a way yet to get the raw public-key out, documented or not? As you may guess, this is for DKIM. Ask Murray; he's had some off-list discussions :) From ian.bilek at gmail.com Sun Mar 25 00:32:22 2018 From: ian.bilek at gmail.com (Jan Bilek) Date: Sun, 25 Mar 2018 10:32:22 +1000 Subject: [openssl-users] Generating unsigned RSA Public Key with openssl Message-ID: Hi, Following code is simplified to demonstrate plain RSA public key with the OpenSSL library: RSA_ptr rsa(RSA_new(), ::RSA_free); BN_ptr bn(BN_new(), ::BN_free); BN_set_word(bn.get(), RSA_F4); //65535 RSA_generate_key_ex(rsa.get(), 320, bn.get(), NULL); BIO * keybio = BIO_new(BIO_s_mem()); i2d_RSAPublicKey_bio(keybio, rsa.get()); char buffer2 [2048]; size_t pubKeyBufferSize = BIO_read (keybio, buffer2, 320); std::cout << Convert::BinToHexString(buffer2, pubKeyBufferSize); //using here our internal routine to print binary data Output from this will come up with binary data in DER ANS.1 format like this: 30 ;SEQUENCE 30 02 29 ;SEQUENCE + size 00 ;leading zero of INTEGER CCEE6526AE9D4380B670A23F55B840F8C5D8CC784E06E123C126753525FD FE1949... 02 03 ;SEQUENCE + size 010001 Now, the "leading zero of INTEGER" part is present to indicate that following value is positive value integer. However I need to get rid of it due to some legacy reasons. I was going through openssl source and found that through the DER construction its presence is decided based on ASN1_VALUE->type & V_ASN1_NEG, but I am unable to track down where to set generated PublicKey as V_ASN1_NEG (or influence it to be generated as negative). Other way to handle this is to write my own TLV-DER parser and re-pack these few bytes to comply with what I need, but I would rather enforce API to do that for me, if it makes sense. Would you have any advice on this? Thank you, Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sun Mar 25 01:05:43 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 24 Mar 2018 21:05:43 -0400 Subject: [openssl-users] ed25519 key generation In-Reply-To: <417000cf-0fa6-211f-0b4b-59d9be27fdb0@wizmail.org> References: <4f6e9344-c7a2-2c27-f1b0-e7008bafbf64@wizmail.org> <6B832619-61BA-458A-89D8-4909E817D733@dukhovni.org> <417000cf-0fa6-211f-0b4b-59d9be27fdb0@wizmail.org> Message-ID: <5BC5EBFF-B79C-4A12-B5DA-B8A5D9C094EF@dukhovni.org> > On Mar 24, 2018, at 7:28 PM, Jeremy Harris wrote: > > Is there a way yet to get the raw public-key out, > documented or not? As you may guess, this is for DKIM. Not sure what format DKIM wants the key in, but if it is SKPI in base64 form then: $ openssl genpkey -algorithm Ed25519 -out /tmp/key.pem $ openssl pkey -in /tmp/key.pem -pubout | openssl pkey -pubin -text -----BEGIN PUBLIC KEY----- MCowBQYDK2VwAyEA92VFLCjUOrNcediYNNr6z9ZU/cqnJoKHA75Pp9rT7u8= -----END PUBLIC KEY----- ED25519 Public-Key: pub: f7:65:45:2c:28:d4:3a:b3:5c:79:d8:98:34:da:fa: cf:d6:54:fd:ca:a7:26:82:87:03:be:4f:a7:da:d3: ee:ef So for just the base64: $ openssl pkey -in /tmp/key.pem -pubout | openssl pkey -pubin -outform DER | openssl base64 -A; echo MCowBQYDK2VwAyEA92VFLCjUOrNcediYNNr6z9ZU/cqnJoKHA75Pp9rT7u8= -- Viktor. From rsalz at akamai.com Sun Mar 25 01:09:03 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 25 Mar 2018 01:09:03 +0000 Subject: [openssl-users] Generating unsigned RSA Public Key with openssl In-Reply-To: References: Message-ID: <81DE76E0-3A9D-40F9-A359-E870F05E2238@akamai.com> The API cannot do it. The encoding requires that numbers with the high-bit on have a leading zero to avoid being interpreted as negative numbers as you noticed. You could maybe generate our own RSA numbers with the high-bit off ? i.e., make your own RSA_new kind of API. The BN code can have flags to not require the high bit on. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgh at wizmail.org Sun Mar 25 11:46:36 2018 From: jgh at wizmail.org (Jeremy Harris) Date: Sun, 25 Mar 2018 12:46:36 +0100 Subject: [openssl-users] ed25519 key generation In-Reply-To: <5BC5EBFF-B79C-4A12-B5DA-B8A5D9C094EF@dukhovni.org> References: <4f6e9344-c7a2-2c27-f1b0-e7008bafbf64@wizmail.org> <6B832619-61BA-458A-89D8-4909E817D733@dukhovni.org> <417000cf-0fa6-211f-0b4b-59d9be27fdb0@wizmail.org> <5BC5EBFF-B79C-4A12-B5DA-B8A5D9C094EF@dukhovni.org> Message-ID: On 25/03/18 02:05, Viktor Dukhovni wrote: >> Is there a way yet to get the raw public-key out, >> documented or not? As you may guess, this is for DKIM. > > Not sure what format DKIM wants the key in, but if it is SKPI > in base64 form It is not. The _raw_ pubkey, base64'd is what is wanted. No ASN.1 wrapping; that's why I said "raw". -- Jeremy From jgh at wizmail.org Sun Mar 25 14:11:30 2018 From: jgh at wizmail.org (Jeremy Harris) Date: Sun, 25 Mar 2018 15:11:30 +0100 Subject: [openssl-users] ed25519 key generation In-Reply-To: References: <4f6e9344-c7a2-2c27-f1b0-e7008bafbf64@wizmail.org> <6B832619-61BA-458A-89D8-4909E817D733@dukhovni.org> <417000cf-0fa6-211f-0b4b-59d9be27fdb0@wizmail.org> Message-ID: On 24/03/18 23:44, Salz, Rich via openssl-users wrote: >> Is there a way yet to get the raw public-key out, > documented or not? As you may guess, this is for DKIM. > > Ask Murray; he's had some off-list discussions :) I might, but people using envelope-from are not very contactable :( -- Jeremy From tanushree.banerjee at uwaterloo.ca Sun Mar 25 15:55:32 2018 From: tanushree.banerjee at uwaterloo.ca (Tanushree Banerjee) Date: Sun, 25 Mar 2018 15:55:32 +0000 Subject: [openssl-users] Request for help in research In-Reply-To: <15b443f3-c5b1-2baa-6d87-da1470fff6fe@blastwave.org> References: <102beb5ff79a4ee797c94fe24144a25f@uwaterloo.ca>, <15b443f3-c5b1-2baa-6d87-da1470fff6fe@blastwave.org> Message-ID: Hey Hi, I'm using 1.0.2n version of openSSL currently. I'm using it on ubuntu 16.04, processor is i7 - 6700 Skylake. Actually I understand that the code https://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman has omitted the details of how to obtain the other party's key (the peer key) . So is there any code available online which can be used to benchmark the execution time of the ecdh implementation of OpenSSL ? Is someone aware of that ? Then please let me know. Thanks and regards Tanushree Banerjee ________________________________ From: openssl-users on behalf of Dennis Clarke Sent: Saturday, March 24, 2018 7:15:57 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] Request for help in research On 24/03/18 06:10 PM, Tanushree Banerjee wrote: > Hello, > > I was looking for benchmarking the execution time of Elliptic Curve > based Diffie Hellman of the OpenSSL implementation in C just for my own > purpose of understanding. A few more specifics would be helpful here. > |in command line. And it does give me some average timing. )| > Your results here would be portable across systems however one would need to know the nature of the build and the architecture. I often single step through functions and thus use non-optimized debug builds which are vastly slower than a regular optimal build. Also the asm code simply does not exist on some architectures like sparc ( non T4 ) or some older powerpc types. > ||I also tried this code -> > > The code over here gives me a bunch of error That isn't too clear. How are you calling ecdh() and with what test data? > Is there any other reliable source that has been used before ? If > someone knows can you please forward me or let me know? That would be > extremely helpful. Thank you for your patience. Hey there UofW type, what rev of openssl are you using? Should I assume that you have "OpenSSL 1.1.0g 2 Nov 2017" on some reasonable architecture? Dennis Clarke number cruncher math geek -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From wangqun at alumni.nus.edu.sg Mon Mar 26 02:05:03 2018 From: wangqun at alumni.nus.edu.sg (Wang) Date: Sun, 25 Mar 2018 19:05:03 -0700 (MST) Subject: [openssl-users] Potential memory leak in RSA_private_decrypt In-Reply-To: <1510219720735-0.post@n7.nabble.com> References: <1509948826636-0.post@n7.nabble.com> <1510048874324-0.post@n7.nabble.com> <99883d51-5a38-e99a-f6ee-30faf8e17033@openssl.org> <1510134459165-0.post@n7.nabble.com> <1510219720735-0.post@n7.nabble.com> Message-ID: <1522029903910-0.post@n7.nabble.com> My further investigation showed this is a memory leak in application code, rather than an OpenSSL one. Thanks, Wang -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From wangqun at alumni.nus.edu.sg Mon Mar 26 02:10:01 2018 From: wangqun at alumni.nus.edu.sg (Wang) Date: Sun, 25 Mar 2018 19:10:01 -0700 (MST) Subject: [openssl-users] Potential memory leak in RSA_private_decrypt In-Reply-To: <1510219720735-0.post@n7.nabble.com> References: <1509948826636-0.post@n7.nabble.com> <1510048874324-0.post@n7.nabble.com> <99883d51-5a38-e99a-f6ee-30faf8e17033@openssl.org> <1510134459165-0.post@n7.nabble.com> <1510219720735-0.post@n7.nabble.com> Message-ID: <1522030201594-0.post@n7.nabble.com> My further investigation showed this is a memory leak in my application code rather than an OpenSSL leak. Thanks, Wang -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From openssl-users at dukhovni.org Mon Mar 26 05:13:56 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 26 Mar 2018 01:13:56 -0400 Subject: [openssl-users] ed25519 key generation In-Reply-To: References: <4f6e9344-c7a2-2c27-f1b0-e7008bafbf64@wizmail.org> <6B832619-61BA-458A-89D8-4909E817D733@dukhovni.org> <417000cf-0fa6-211f-0b4b-59d9be27fdb0@wizmail.org> <5BC5EBFF-B79C-4A12-B5DA-B8A5D9C094EF@dukhovni.org> Message-ID: <96E09733-D357-4EFD-8C44-E8C0CCBD6EAE@dukhovni.org> > On Mar 25, 2018, at 7:46 AM, Jeremy Harris wrote: > >> Not sure what format DKIM wants the key in, but if it is SKPI >> in base64 form > > It is not. The _raw_ pubkey, base64'd is what is wanted. > No ASN.1 wrapping; that's why I said "raw". I'm afraid you're wrong about that: $ dig +noall +ans +nocl +nottl +nosplit -t txt 20161025._domainkey.gmail.com 20161025._domainkey.gmail.com. TXT "k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAviPGBk4ZB64UfSqWyAicdR7lodhytae+EYRQVtKDhM+1mXjEqRtP/pDT3sBhazkmA48n2k5NJUyMEoO8nc2r6sUA+/Dom5jRBZp6qDKJOwjJ5R/OpHamlRG+YRJQqR" "tqEgSiJWG7h7efGYWmh4URhFM9k9+rmG/CwCgwx7Et+c8OMlngaLl04/bPmfpjdEyLWyNimk761CX6KymzYiRDNz1MOJOJ7OzFaS4PFbVLn0m5mf0HVNtBpPwWuCNvaFVflUYxEyblbB6h/oWOPGbzoSgtRA47SHV53SwZjIsVpbq4LxUW9IxAEwYzGcSgZ4n5Q8X8TndowsDUzoccPFGhdwIDAQAB" $ printf "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAviPGBk4ZB64UfSqWyAicdR7lodhytae+EYRQVtKDhM+1mXjEqRtP/pDT3sBhazkmA48n2k5NJUyMEoO8nc2r6sUA+/Dom5jRBZp6qDKJOwjJ5R/OpHamlRG+YRJQqRtqEgSiJWG7h7efGYWmh4URhFM9k9+rmG/CwCgwx7Et+c8OMlngaLl04/bPmfpjdEyLWyNimk761CX6KymzYiRDNz1MOJOJ7OzFaS4PFbVLn0m5mf0HVNtBpPwWuCNvaFVflUYxEyblbB6h/oWOPGbzoSgtRA47SHV53SwZjIsVpbq4LxUW9IxAEwYzGcSgZ4n5Q8X8TndowsDUzoccPFGhdwIDAQAB" | openssl base64 -A -d | openssl asn1parse -inform DER 0:d=0 hl=4 l= 290 cons: SEQUENCE 4:d=1 hl=2 l= 13 cons: SEQUENCE 6:d=2 hl=2 l= 9 prim: OBJECT :rsaEncryption 17:d=2 hl=2 l= 0 prim: NULL 19:d=1 hl=4 l= 271 prim: BIT STRING That's an ASN1 encoding of X.509 SPKI object. Which is not surprising, even for RSA one must still encode the modulus and exponent somehow, and other algorithms might have parameters... So ASN.1 it is. -- Viktor. From sahil.malhotra at nxp.com Mon Mar 26 06:28:44 2018 From: sahil.malhotra at nxp.com (Sahil Malhotra) Date: Mon, 26 Mar 2018 06:28:44 +0000 Subject: [openssl-users] PKCS#11 support in OpenSSL Message-ID: Hi, A general query about inbuilt PKCS#11 support in OpenSSL. If we want to use the keys stored in the Token/HSM with OpenSSL, we need to use the Third party modules(libp11 in combination with libpkcs11 engine). But in some other TLS stacks like GnuTLS, PKCS#11 support is inbuilt. So, Is OpenSSL community is thinking on having the inbuilt PKCS#11 support or will continue working with third party modules(libp11) ? Regards, Sahil Malhotra -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgh at wizmail.org Mon Mar 26 08:31:16 2018 From: jgh at wizmail.org (Jeremy Harris) Date: Mon, 26 Mar 2018 09:31:16 +0100 Subject: [openssl-users] ed25519 key generation In-Reply-To: <96E09733-D357-4EFD-8C44-E8C0CCBD6EAE@dukhovni.org> References: <4f6e9344-c7a2-2c27-f1b0-e7008bafbf64@wizmail.org> <6B832619-61BA-458A-89D8-4909E817D733@dukhovni.org> <417000cf-0fa6-211f-0b4b-59d9be27fdb0@wizmail.org> <5BC5EBFF-B79C-4A12-B5DA-B8A5D9C094EF@dukhovni.org> <96E09733-D357-4EFD-8C44-E8C0CCBD6EAE@dukhovni.org> Message-ID: <769242a4-e1c7-1a3b-22a0-20b2d31b58b8@wizmail.org> On 26/03/18 06:13, Viktor Dukhovni wrote: >> On Mar 25, 2018, at 7:46 AM, Jeremy Harris wrote: >> >>> Not sure what format DKIM wants the key in, but if it is SKPI >>> in base64 form >> >> It is not. The _raw_ pubkey, base64'd is what is wanted. >> No ASN.1 wrapping; that's why I said "raw". > > I'm afraid you're wrong about that: > > $ dig +noall +ans +nocl +nottl +nosplit -t txt 20161025._domainkey.gmail.com > 20161025._domainkey.gmail.com. TXT "k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAviPGBk4ZB64UfSqWyAicdR7lodhytae+EYRQVtKDhM+1mXjEqRtP/pDT3sBhazkmA48n2k5NJUyMEoO8nc2r6sUA+/Dom5jRBZp6qDKJOwjJ5R/OpHamlRG+YRJQqR" "tqEgSiJWG7h7efGYWmh4URhFM9k9+rmG/CwCgwx7Et+c8OMlngaLl04/bPmfpjdEyLWyNimk761CX6KymzYiRDNz1MOJOJ7OzFaS4PFbVLn0m5mf0HVNtBpPwWuCNvaFVflUYxEyblbB6h/oWOPGbzoSgtRA47SHV53SwZjIsVpbq4LxUW9IxAEwYzGcSgZ4n5Q8X8TndowsDUzoccPFGhdwIDAQAB" > > $ printf "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAviPGBk4ZB64UfSqWyAicdR7lodhytae+EYRQVtKDhM+1mXjEqRtP/pDT3sBhazkmA48n2k5NJUyMEoO8nc2r6sUA+/Dom5jRBZp6qDKJOwjJ5R/OpHamlRG+YRJQqRtqEgSiJWG7h7efGYWmh4URhFM9k9+rmG/CwCgwx7Et+c8OMlngaLl04/bPmfpjdEyLWyNimk761CX6KymzYiRDNz1MOJOJ7OzFaS4PFbVLn0m5mf0HVNtBpPwWuCNvaFVflUYxEyblbB6h/oWOPGbzoSgtRA47SHV53SwZjIsVpbq4LxUW9IxAEwYzGcSgZ4n5Q8X8TndowsDUzoccPFGhdwIDAQAB" | openssl base64 -A -d | openssl asn1parse -inform DER > 0:d=0 hl=4 l= 290 cons: SEQUENCE > 4:d=1 hl=2 l= 13 cons: SEQUENCE > 6:d=2 hl=2 l= 9 prim: OBJECT :rsaEncryption > 17:d=2 hl=2 l= 0 prim: NULL > 19:d=1 hl=4 l= 271 prim: BIT STRING > > That's an ASN1 encoding of X.509 SPKI object. Which is > not surprising, even for RSA one must still encode the > modulus and exponent somehow, and other algorithms might > have parameters... So ASN.1 it is. That is an RSA key. We're talking about Ed25519 keys. -- Jeremy From matt at openssl.org Mon Mar 26 10:46:09 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 26 Mar 2018 11:46:09 +0100 Subject: [openssl-users] ed25519 key generation In-Reply-To: References: <4f6e9344-c7a2-2c27-f1b0-e7008bafbf64@wizmail.org> <6B832619-61BA-458A-89D8-4909E817D733@dukhovni.org> <417000cf-0fa6-211f-0b4b-59d9be27fdb0@wizmail.org> <5BC5EBFF-B79C-4A12-B5DA-B8A5D9C094EF@dukhovni.org> Message-ID: <3c9c837b-8aff-406b-fe4c-1e0c3d402188@openssl.org> On 25/03/18 12:46, Jeremy Harris wrote: > On 25/03/18 02:05, Viktor Dukhovni wrote: >>> Is there a way yet to get the raw public-key out, >>> documented or not? As you may guess, this is for DKIM. >> >> Not sure what format DKIM wants the key in, but if it is SKPI >> in base64 form > > It is not. The _raw_ pubkey, base64'd is what is wanted. > No ASN.1 wrapping; that's why I said "raw". > I just had the exact same conversation off-list... To generate an Ed25519 private key: $ openssl genpkey -algorithm ed25519 -outform PEM -out test25519.pem OpenSSL does not support outputting only the raw key from the command line. You *can* get it in SubjectPublicKeyInfo format which, for an Ed25519 key will always consist of 12 bytes of ASN.1 header followed by 32 bytes of raw key. Therefore to get a base64 encoded raw public key: $ openssl pkey -outform DER -pubout -in test25519.pem | tail -c +13 | openssl base64 Matt From jgh at wizmail.org Mon Mar 26 12:10:21 2018 From: jgh at wizmail.org (Jeremy Harris) Date: Mon, 26 Mar 2018 13:10:21 +0100 Subject: [openssl-users] ed25519 key generation In-Reply-To: <3c9c837b-8aff-406b-fe4c-1e0c3d402188@openssl.org> References: <4f6e9344-c7a2-2c27-f1b0-e7008bafbf64@wizmail.org> <6B832619-61BA-458A-89D8-4909E817D733@dukhovni.org> <417000cf-0fa6-211f-0b4b-59d9be27fdb0@wizmail.org> <5BC5EBFF-B79C-4A12-B5DA-B8A5D9C094EF@dukhovni.org> <3c9c837b-8aff-406b-fe4c-1e0c3d402188@openssl.org> Message-ID: <3c39d6e8-bbdb-ca09-081c-2acd8d0eb05b@wizmail.org> On 26/03/18 11:46, Matt Caswell wrote: > $ openssl pkey -outform DER -pubout -in test25519.pem | tail -c +13 | > openssl base64 Thanks! -- Jeremy From rsalz at akamai.com Mon Mar 26 12:55:52 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 26 Mar 2018 12:55:52 +0000 Subject: [openssl-users] ed25519 key generation In-Reply-To: References: <4f6e9344-c7a2-2c27-f1b0-e7008bafbf64@wizmail.org> <6B832619-61BA-458A-89D8-4909E817D733@dukhovni.org> <417000cf-0fa6-211f-0b4b-59d9be27fdb0@wizmail.org> Message-ID: > I might, but people using envelope-from are not very contactable :( Did you try? That address works. From rsalz at akamai.com Mon Mar 26 12:58:43 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 26 Mar 2018 12:58:43 +0000 Subject: [openssl-users] ed25519 key generation In-Reply-To: <96E09733-D357-4EFD-8C44-E8C0CCBD6EAE@dukhovni.org> References: <4f6e9344-c7a2-2c27-f1b0-e7008bafbf64@wizmail.org> <6B832619-61BA-458A-89D8-4909E817D733@dukhovni.org> <417000cf-0fa6-211f-0b4b-59d9be27fdb0@wizmail.org> <5BC5EBFF-B79C-4A12-B5DA-B8A5D9C094EF@dukhovni.org> <96E09733-D357-4EFD-8C44-E8C0CCBD6EAE@dukhovni.org> Message-ID: <362B43FD-CB17-42CB-BEE7-1D171C629E02@akamai.com> For RSA it's the ASN1 sequence of the key. For Ed25519 it's just the 40 bytes of the raw key. From rsalz at akamai.com Mon Mar 26 13:04:49 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 26 Mar 2018 13:04:49 +0000 Subject: [openssl-users] PKCS#11 support in OpenSSL Message-ID: * So, Is OpenSSL community is thinking on having the inbuilt PKCS#11 support or will continue working with third party modules(libp11) ? Things have never gotten past this kind of discussion phase. Interested parties will have to discuss on email list and create one or more pull requests. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgh at wizmail.org Mon Mar 26 13:48:04 2018 From: jgh at wizmail.org (Jeremy Harris) Date: Mon, 26 Mar 2018 14:48:04 +0100 Subject: [openssl-users] ed25519 key generation In-Reply-To: References: <4f6e9344-c7a2-2c27-f1b0-e7008bafbf64@wizmail.org> <6B832619-61BA-458A-89D8-4909E817D733@dukhovni.org> <417000cf-0fa6-211f-0b4b-59d9be27fdb0@wizmail.org> Message-ID: On 26/03/18 13:55, Salz, Rich via openssl-users wrote: >> I might, but people using envelope-from > are not very contactable :( > > Did you try? That address works. I tried somebody, possibly somebody else (it could have been Brandon) using that moniker, some time ago. Got no response; assumed it to be a spam-dump. But perhaps my question was uninteresting that time. -- Cheers, Jeremy From matt at openssl.org Mon Mar 26 14:08:26 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 26 Mar 2018 15:08:26 +0100 Subject: [openssl-users] ed25519 key generation In-Reply-To: <362B43FD-CB17-42CB-BEE7-1D171C629E02@akamai.com> References: <4f6e9344-c7a2-2c27-f1b0-e7008bafbf64@wizmail.org> <6B832619-61BA-458A-89D8-4909E817D733@dukhovni.org> <417000cf-0fa6-211f-0b4b-59d9be27fdb0@wizmail.org> <5BC5EBFF-B79C-4A12-B5DA-B8A5D9C094EF@dukhovni.org> <96E09733-D357-4EFD-8C44-E8C0CCBD6EAE@dukhovni.org> <362B43FD-CB17-42CB-BEE7-1D171C629E02@akamai.com> Message-ID: <5dc28890-3319-9b59-bbb1-f83924ece739@openssl.org> On 26/03/18 13:58, Salz, Rich via openssl-users wrote: > For RSA it's the ASN1 sequence of the key. For Ed25519 it's just the 40 bytes of the raw key. > > Note that for Ed25519 the raw public key is 32 bytes not 40. Matt From openssl-users at dukhovni.org Mon Mar 26 15:04:40 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 26 Mar 2018 11:04:40 -0400 Subject: [openssl-users] ed25519 key generation In-Reply-To: <5dc28890-3319-9b59-bbb1-f83924ece739@openssl.org> References: <4f6e9344-c7a2-2c27-f1b0-e7008bafbf64@wizmail.org> <6B832619-61BA-458A-89D8-4909E817D733@dukhovni.org> <417000cf-0fa6-211f-0b4b-59d9be27fdb0@wizmail.org> <5BC5EBFF-B79C-4A12-B5DA-B8A5D9C094EF@dukhovni.org> <96E09733-D357-4EFD-8C44-E8C0CCBD6EAE@dukhovni.org> <362B43FD-CB17-42CB-BEE7-1D171C629E02@akamai.com> <5dc28890-3319-9b59-bbb1-f83924ece739@openssl.org> Message-ID: <04F65139-5FD5-4210-802F-01C95FF91550@dukhovni.org> > On Mar 26, 2018, at 10:08 AM, Matt Caswell wrote: > > Note that for Ed25519 the raw public key is 32 bytes not 40. I see so the DKIM key encoding for Ed25519 was slimmed down to bare essentials, which slightly complicates the interface for using it on the verifier side (at least for OpenSSL), since now one needs to create the SPKI key handle in an algorithm-specific manner, loading the public key into a new Ed25519 public key object, ... https://tools.ietf.org/html/draft-ietf-dcrup-dkim-crypto-08#section-4.2 The p= value in the key record is the ed25519 public key encoded in base64. Since the key is 256 bits long, the base64 text is 44 octets long. -- Viktor. From juriarte at redhat.com Mon Mar 26 15:19:01 2018 From: juriarte at redhat.com (Jon Uriarte) Date: Mon, 26 Mar 2018 17:19:01 +0200 Subject: [openssl-users] CSR verify failure Message-ID: Hi folks, I'm hitting some issues when trying to create SSL certificates and was wondering if any around could help with this. I can create a CSR and sign it with a newly created key: $ openssl req -out CSR.csr -new -newkey rsa:2048 -nodes -keyout privateKey.key Generating a 2048 bit RSA private key ........................................+++ .....+++ writing new private key to 'privateKey.key' ----- (enter CSR data) ... But just after CSR creation, its verification fails: $ openssl req -text -noout -verify -in CSR.csr verify failure 139886616864656:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:103: 139886616864656:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:773: 139886616864656:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:249: Certificate Request: Data: Version: 0 (0x0) Subject: C=ES, L=Default City, O=Default Company Ltd ... At this point, if I try to create a certificate from the CSR, it creates an empty certificate. Private key check returns ok: $ openssl rsa -in privateKey.key -check RSA key ok writing RSA key -----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY----- The public key can be read from the CSR: $ openssl req -in CSR.csr -noout -pubkey -----BEGIN PUBLIC KEY----- ... -----END PUBLIC KEY----- I am working on a RHEL machine, with this openssl version: $ rpm -qa | grep openssl openssl-libs-1.0.2k-12.el7.x86_64 openssl-1.0.2k-12.el7.x86_64 Don't know if could be related to a missing library, and have tried to find out the root cause of the issue in internet and mailing lists but didn't get to it. Any help would be very much appreciated. Thanks! Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe at felipegasper.com Mon Mar 26 15:28:05 2018 From: felipe at felipegasper.com (Felipe Gasper) Date: Mon, 26 Mar 2018 11:28:05 -0400 Subject: [openssl-users] CSR verify failure In-Reply-To: References: Message-ID: Can you paste one of the CSRs that fails verification? -Felipe > On Mar 26, 2018, at 11:19 AM, Jon Uriarte wrote: > > Hi folks, > > I'm hitting some issues when trying to create SSL certificates and was wondering if any around could help with this. > I can create a CSR and sign it with a newly created key: > > $ openssl req -out CSR.csr -new -newkey rsa:2048 -nodes -keyout privateKey.key > Generating a 2048 bit RSA private key > ........................................+++ > .....+++ > writing new private key to 'privateKey.key' > ----- > (enter CSR data) > ... > > But just after CSR creation, its verification fails: > > $ openssl req -text -noout -verify -in CSR.csr > verify failure > 139886616864656:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:103: > 139886616864656:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:773: > 139886616864656:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:249: > Certificate Request: > Data: > Version: 0 (0x0) > Subject: C=ES, L=Default City, O=Default Company Ltd > ... > > At this point, if I try to create a certificate from the CSR, it creates an empty certificate. > > Private key check returns ok: > > $ openssl rsa -in privateKey.key -check > RSA key ok > writing RSA key > -----BEGIN RSA PRIVATE KEY----- > ... > -----END RSA PRIVATE KEY----- > > The public key can be read from the CSR: > > $ openssl req -in CSR.csr -noout -pubkey > -----BEGIN PUBLIC KEY----- > ... > -----END PUBLIC KEY----- > > I am working on a RHEL machine, with this openssl version: > > $ rpm -qa | grep openssl > openssl-libs-1.0.2k-12.el7.x86_64 > openssl-1.0.2k-12.el7.x86_64 > > Don't know if could be related to a missing library, and have tried to find out the root cause of the issue in internet and mailing lists but didn't get to it. > > Any help would be very much appreciated. > > > Thanks! > Jon > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From Michael.Wojcik at microfocus.com Mon Mar 26 15:36:04 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 26 Mar 2018 15:36:04 +0000 Subject: [openssl-users] CSR verify failure In-Reply-To: References: Message-ID: I just tried the same commands on my system, using 1.0.2n, and didn't have any problems (as I'd expect). What's the output of openssl asn1parse -dump -in CSR.csr? -- Michael Wojcik Distinguished Engineer, Micro Focus From juriarte at redhat.com Mon Mar 26 15:47:00 2018 From: juriarte at redhat.com (Jon Uriarte) Date: Mon, 26 Mar 2018 17:47:00 +0200 Subject: [openssl-users] CSR verify failure In-Reply-To: References: Message-ID: Thanks for your replies. I'm creating the CSR with the default values. $ openssl req -noout -text -in CSR.csr Certificate Request: Data: Version: 0 (0x0) Subject: C=XX, L=Default City, O=Default Company Ltd Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:e2:6e:84:97:0e:d5:ea:ad:18:4f:18:73:b3:f8: 71:28:12:c2:5c:32:b8:07:bc:01:8c:ec:78:60:aa: c0:01:18:5c:75:5d:01:76:8f:b2:92:5c:47:23:f6: 9d:dc:f6:02:66:1f:ca:d3:cf:a2:01:44:58:f9:df: f3:a5:8a:c9:a3:47:a7:80:1a:9f:62:c4:a3:46:77: e3:96:6a:85:bf:06:ac:0a:51:ea:1a:9d:03:2a:80: 4c:63:6b:81:87:21:b5:56:4d:a3:52:4d:d9:b4:60: 63:f3:14:5e:a7:6e:9d:f4:b7:5b:7d:cb:10:9c:20: d1:be:ed:7f:82:81:1c:f2:f0:94:ea:a4:c9:6a:3b: e7:1b:cc:44:e7:0c:21:24:57:fa:4e:4d:6d:c9:00: b1:79:17:e4:7e:76:96:bc:98:42:b8:ab:ce:a8:07: 47:c0:bc:06:a7:b8:a7:36:07:2e:ca:80:d9:2c:3a: 17:e7:a6:7c:ec:53:1a:6a:a1:37:a3:b6:59:00:6b: c8:fe:7f:f4:2a:72:48:74:93:d6:81:b9:c0:3b:4f: a9:9d:84:84:4d:60:76:97:90:0c:f8:c7:46:26:94: 90:84:c1:95:cb:00:41:8d:0b:35:41:2a:a8:a9:ea: 73:fd:08:81:92:46:03:1a:1c:c5:18:5b:87:dd:3c: a3:0d Exponent: 65537 (0x10001) Attributes: a0:00 Signature Algorithm: sha256WithRSAEncryption 71:86:f1:88:7e:4b:c9:66:36:6a:07:f0:76:64:4b:55:70:e0: e3:fc:18:5f:99:28:d4:95:c4:3b:e0:d7:52:64:2e:42:52:c9: 5c:cb:ba:33:25:08:80:5e:24:62:6d:a1:8e:70:f9:9e:20:66: 3a:14:d6:cb:10:25:93:fc:5a:f6:79:c8:a8:ce:f6:9d:0c:cf: 8a:96:9f:76:72:a4:f7:66:8c:2e:4a:35:f4:51:5f:b5:cd:fc: b6:a6:ee:4e:06:d2:9f:6c:6b:34:a4:19:6c:0b:a6:cb:2b:25: 47:da:ce:32:a1:89:6e:04:47:86:46:e5:6f:eb:d1:e6:65:73: 86:13:a1:f4:4a:f1:e3:2c:e5:76:a6:e1:24:c2:d6:5c:33:fc: 6a:d2:eb:33:0c:77:ca:56:b6:cb:a7:e9:13:fa:6d:0e:22:03: 51:50:39:e0:91:ca:5d:a7:d3:f5:5b:cb:4c:2d:56:39:9b:c6: ab:87:c7:9b:54:6c:55:17:b6:6d:62:28:62:e8:b3:d5:69:17: 09:80:dc:a8:6b:09:ed:c6:18:62:5f:fd:eb:9b:3a:b7:a5:ab: db:72:bc:55:df:e8:fa:ad:22:f1:bf:0d:b3:79:e1:d2:09:4e: a3:4e:61:5b:28:af:ca:3d:1f:53:52:52:72:71:e9:73:28:fd: 73:01:90:95 $ openssl asn1parse -dump -in CSR.csr 0:d=0 hl=4 l= 647 cons: SEQUENCE 4:d=1 hl=4 l= 367 cons: SEQUENCE 8:d=2 hl=2 l= 1 prim: INTEGER :00 11:d=2 hl=2 l= 66 cons: SEQUENCE 13:d=3 hl=2 l= 11 cons: SET 15:d=4 hl=2 l= 9 cons: SEQUENCE 17:d=5 hl=2 l= 3 prim: OBJECT :countryName 22:d=5 hl=2 l= 2 prim: PRINTABLESTRING :XX 26:d=3 hl=2 l= 21 cons: SET 28:d=4 hl=2 l= 19 cons: SEQUENCE 30:d=5 hl=2 l= 3 prim: OBJECT :localityName 35:d=5 hl=2 l= 12 prim: UTF8STRING :Default City 49:d=3 hl=2 l= 28 cons: SET 51:d=4 hl=2 l= 26 cons: SEQUENCE 53:d=5 hl=2 l= 3 prim: OBJECT :organizationName 58:d=5 hl=2 l= 19 prim: UTF8STRING :Default Company Ltd 79:d=2 hl=4 l= 290 cons: SEQUENCE 83:d=3 hl=2 l= 13 cons: SEQUENCE 85:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption 96:d=4 hl=2 l= 0 prim: NULL 98:d=3 hl=4 l= 271 prim: BIT STRING 0000 - 00 30 82 01 0a 02 82 01-01 00 e2 6e 84 97 0e d5 .0.........n.... 0010 - ea ad 18 4f 18 73 b3 f8-71 28 12 c2 5c 32 b8 07 ...O.s..q(..\2.. 0020 - bc 01 8c ec 78 60 aa c0-01 18 5c 75 5d 01 76 8f ....x`....\u].v. 0030 - b2 92 5c 47 23 f6 9d dc-f6 02 66 1f ca d3 cf a2 ..\G#.....f..... 0040 - 01 44 58 f9 df f3 a5 8a-c9 a3 47 a7 80 1a 9f 62 .DX.......G....b 0050 - c4 a3 46 77 e3 96 6a 85-bf 06 ac 0a 51 ea 1a 9d ..Fw..j.....Q... 0060 - 03 2a 80 4c 63 6b 81 87-21 b5 56 4d a3 52 4d d9 .*.Lck..!.VM.RM. 0070 - b4 60 63 f3 14 5e a7 6e-9d f4 b7 5b 7d cb 10 9c .`c..^.n...[}... 0080 - 20 d1 be ed 7f 82 81 1c-f2 f0 94 ea a4 c9 6a 3b .............j; 0090 - e7 1b cc 44 e7 0c 21 24-57 fa 4e 4d 6d c9 00 b1 ...D..!$W.NMm... 00a0 - 79 17 e4 7e 76 96 bc 98-42 b8 ab ce a8 07 47 c0 y..~v...B.....G. 00b0 - bc 06 a7 b8 a7 36 07 2e-ca 80 d9 2c 3a 17 e7 a6 .....6.....,:... 00c0 - 7c ec 53 1a 6a a1 37 a3-b6 59 00 6b c8 fe 7f f4 |.S.j.7..Y.k.... 00d0 - 2a 72 48 74 93 d6 81 b9-c0 3b 4f a9 9d 84 84 4d *rHt.....;O....M 00e0 - 60 76 97 90 0c f8 c7 46-26 94 90 84 c1 95 cb 00 `v.....F&....... 00f0 - 41 8d 0b 35 41 2a a8 a9-ea 73 fd 08 81 92 46 03 A..5A*...s....F. 0100 - 1a 1c c5 18 5b 87 dd 3c-a3 0d 02 03 01 00 01 ....[..<....... 373:d=2 hl=2 l= 0 cons: cont [ 0 ] 375:d=1 hl=2 l= 13 cons: SEQUENCE 377:d=2 hl=2 l= 9 prim: OBJECT :sha256WithRSAEncryption 388:d=2 hl=2 l= 0 prim: NULL 390:d=1 hl=4 l= 257 prim: BIT STRING 0000 - 00 71 86 f1 88 7e 4b c9-66 36 6a 07 f0 76 64 4b .q...~K.f6j..vdK 0010 - 55 70 e0 e3 fc 18 5f 99-28 d4 95 c4 3b e0 d7 52 Up...._.(...;..R 0020 - 64 2e 42 52 c9 5c cb ba-33 25 08 80 5e 24 62 6d d.BR.\..3%..^$bm 0030 - a1 8e 70 f9 9e 20 66 3a-14 d6 cb 10 25 93 fc 5a ..p.. f:....%..Z 0040 - f6 79 c8 a8 ce f6 9d 0c-cf 8a 96 9f 76 72 a4 f7 .y..........vr.. 0050 - 66 8c 2e 4a 35 f4 51 5f-b5 cd fc b6 a6 ee 4e 06 f..J5.Q_......N. 0060 - d2 9f 6c 6b 34 a4 19 6c-0b a6 cb 2b 25 47 da ce ..lk4..l...+%G.. 0070 - 32 a1 89 6e 04 47 86 46-e5 6f eb d1 e6 65 73 86 2..n.G.F.o...es. 0080 - 13 a1 f4 4a f1 e3 2c e5-76 a6 e1 24 c2 d6 5c 33 ...J..,.v..$..\3 0090 - fc 6a d2 eb 33 0c 77 ca-56 b6 cb a7 e9 13 fa 6d .j..3.w.V......m 00a0 - 0e 22 03 51 50 39 e0 91-ca 5d a7 d3 f5 5b cb 4c .".QP9...]...[.L 00b0 - 2d 56 39 9b c6 ab 87 c7-9b 54 6c 55 17 b6 6d 62 -V9......TlU..mb 00c0 - 28 62 e8 b3 d5 69 17 09-80 dc a8 6b 09 ed c6 18 (b...i.....k.... 00d0 - 62 5f fd eb 9b 3a b7 a5-ab db 72 bc 55 df e8 fa b_...:....r.U... 00e0 - ad 22 f1 bf 0d b3 79 e1-d2 09 4e a3 4e 61 5b 28 ."....y...N.Na[( 00f0 - af ca 3d 1f 53 52 52 72-71 e9 73 28 fd 73 01 90 ..=.SRRrq.s(.s.. 0100 - 95 . Jon On Mon, Mar 26, 2018 at 5:36 PM, Michael Wojcik < Michael.Wojcik at microfocus.com> wrote: > I just tried the same commands on my system, using 1.0.2n, and didn't have > any problems (as I'd expect). > > What's the output of openssl asn1parse -dump -in CSR.csr? > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe at felipegasper.com Mon Mar 26 15:49:24 2018 From: felipe at felipegasper.com (Felipe Gasper) Date: Mon, 26 Mar 2018 11:49:24 -0400 Subject: [openssl-users] CSR verify failure In-Reply-To: References: Message-ID: <071BD49D-F44C-4B15-8A78-9635CF576673@felipegasper.com> But what is the actual PEM of the CSR? It should look like: -----BEGIN CERTIFICATE REQUEST----- ... -----END CERTIFICATE REQUEST----- -FG > On Mar 26, 2018, at 11:47 AM, Jon Uriarte wrote: > > Thanks for your replies. > > I'm creating the CSR with the default values. > > $ openssl req -noout -text -in CSR.csr > Certificate Request: > Data: > Version: 0 (0x0) > Subject: C=XX, L=Default City, O=Default Company Ltd > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > Public-Key: (2048 bit) > Modulus: > 00:e2:6e:84:97:0e:d5:ea:ad:18:4f:18:73:b3:f8: > 71:28:12:c2:5c:32:b8:07:bc:01:8c:ec:78:60:aa: > c0:01:18:5c:75:5d:01:76:8f:b2:92:5c:47:23:f6: > 9d:dc:f6:02:66:1f:ca:d3:cf:a2:01:44:58:f9:df: > f3:a5:8a:c9:a3:47:a7:80:1a:9f:62:c4:a3:46:77: > e3:96:6a:85:bf:06:ac:0a:51:ea:1a:9d:03:2a:80: > 4c:63:6b:81:87:21:b5:56:4d:a3:52:4d:d9:b4:60: > 63:f3:14:5e:a7:6e:9d:f4:b7:5b:7d:cb:10:9c:20: > d1:be:ed:7f:82:81:1c:f2:f0:94:ea:a4:c9:6a:3b: > e7:1b:cc:44:e7:0c:21:24:57:fa:4e:4d:6d:c9:00: > b1:79:17:e4:7e:76:96:bc:98:42:b8:ab:ce:a8:07: > 47:c0:bc:06:a7:b8:a7:36:07:2e:ca:80:d9:2c:3a: > 17:e7:a6:7c:ec:53:1a:6a:a1:37:a3:b6:59:00:6b: > c8:fe:7f:f4:2a:72:48:74:93:d6:81:b9:c0:3b:4f: > a9:9d:84:84:4d:60:76:97:90:0c:f8:c7:46:26:94: > 90:84:c1:95:cb:00:41:8d:0b:35:41:2a:a8:a9:ea: > 73:fd:08:81:92:46:03:1a:1c:c5:18:5b:87:dd:3c: > a3:0d > Exponent: 65537 (0x10001) > Attributes: > a0:00 > Signature Algorithm: sha256WithRSAEncryption > 71:86:f1:88:7e:4b:c9:66:36:6a:07:f0:76:64:4b:55:70:e0: > e3:fc:18:5f:99:28:d4:95:c4:3b:e0:d7:52:64:2e:42:52:c9: > 5c:cb:ba:33:25:08:80:5e:24:62:6d:a1:8e:70:f9:9e:20:66: > 3a:14:d6:cb:10:25:93:fc:5a:f6:79:c8:a8:ce:f6:9d:0c:cf: > 8a:96:9f:76:72:a4:f7:66:8c:2e:4a:35:f4:51:5f:b5:cd:fc: > b6:a6:ee:4e:06:d2:9f:6c:6b:34:a4:19:6c:0b:a6:cb:2b:25: > 47:da:ce:32:a1:89:6e:04:47:86:46:e5:6f:eb:d1:e6:65:73: > 86:13:a1:f4:4a:f1:e3:2c:e5:76:a6:e1:24:c2:d6:5c:33:fc: > 6a:d2:eb:33:0c:77:ca:56:b6:cb:a7:e9:13:fa:6d:0e:22:03: > 51:50:39:e0:91:ca:5d:a7:d3:f5:5b:cb:4c:2d:56:39:9b:c6: > ab:87:c7:9b:54:6c:55:17:b6:6d:62:28:62:e8:b3:d5:69:17: > 09:80:dc:a8:6b:09:ed:c6:18:62:5f:fd:eb:9b:3a:b7:a5:ab: > db:72:bc:55:df:e8:fa:ad:22:f1:bf:0d:b3:79:e1:d2:09:4e: > a3:4e:61:5b:28:af:ca:3d:1f:53:52:52:72:71:e9:73:28:fd: > 73:01:90:95 > > > $ openssl asn1parse -dump -in CSR.csr > 0:d=0 hl=4 l= 647 cons: SEQUENCE > 4:d=1 hl=4 l= 367 cons: SEQUENCE > 8:d=2 hl=2 l= 1 prim: INTEGER :00 > 11:d=2 hl=2 l= 66 cons: SEQUENCE > 13:d=3 hl=2 l= 11 cons: SET > 15:d=4 hl=2 l= 9 cons: SEQUENCE > 17:d=5 hl=2 l= 3 prim: OBJECT :countryName > 22:d=5 hl=2 l= 2 prim: PRINTABLESTRING :XX > 26:d=3 hl=2 l= 21 cons: SET > 28:d=4 hl=2 l= 19 cons: SEQUENCE > 30:d=5 hl=2 l= 3 prim: OBJECT :localityName > 35:d=5 hl=2 l= 12 prim: UTF8STRING :Default City > 49:d=3 hl=2 l= 28 cons: SET > 51:d=4 hl=2 l= 26 cons: SEQUENCE > 53:d=5 hl=2 l= 3 prim: OBJECT :organizationName > 58:d=5 hl=2 l= 19 prim: UTF8STRING :Default Company Ltd > 79:d=2 hl=4 l= 290 cons: SEQUENCE > 83:d=3 hl=2 l= 13 cons: SEQUENCE > 85:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption > 96:d=4 hl=2 l= 0 prim: NULL > 98:d=3 hl=4 l= 271 prim: BIT STRING > 0000 - 00 30 82 01 0a 02 82 01-01 00 e2 6e 84 97 0e d5 .0.........n.... > 0010 - ea ad 18 4f 18 73 b3 f8-71 28 12 c2 5c 32 b8 07 ...O.s..q(..\2.. > 0020 - bc 01 8c ec 78 60 aa c0-01 18 5c 75 5d 01 76 8f ....x`....\u].v. > 0030 - b2 92 5c 47 23 f6 9d dc-f6 02 66 1f ca d3 cf a2 ..\G#.....f..... > 0040 - 01 44 58 f9 df f3 a5 8a-c9 a3 47 a7 80 1a 9f 62 .DX.......G....b > 0050 - c4 a3 46 77 e3 96 6a 85-bf 06 ac 0a 51 ea 1a 9d ..Fw..j.....Q... > 0060 - 03 2a 80 4c 63 6b 81 87-21 b5 56 4d a3 52 4d d9 .*.Lck..!.VM.RM. > 0070 - b4 60 63 f3 14 5e a7 6e-9d f4 b7 5b 7d cb 10 9c .`c..^.n...[}... > 0080 - 20 d1 be ed 7f 82 81 1c-f2 f0 94 ea a4 c9 6a 3b .............j; > 0090 - e7 1b cc 44 e7 0c 21 24-57 fa 4e 4d 6d c9 00 b1 ...D..!$W.NMm... > 00a0 - 79 17 e4 7e 76 96 bc 98-42 b8 ab ce a8 07 47 c0 y..~v...B.....G. > 00b0 - bc 06 a7 b8 a7 36 07 2e-ca 80 d9 2c 3a 17 e7 a6 .....6.....,:... > 00c0 - 7c ec 53 1a 6a a1 37 a3-b6 59 00 6b c8 fe 7f f4 |.S.j.7..Y.k.... > 00d0 - 2a 72 48 74 93 d6 81 b9-c0 3b 4f a9 9d 84 84 4d *rHt.....;O....M > 00e0 - 60 76 97 90 0c f8 c7 46-26 94 90 84 c1 95 cb 00 `v.....F&....... > 00f0 - 41 8d 0b 35 41 2a a8 a9-ea 73 fd 08 81 92 46 03 A..5A*...s....F. > 0100 - 1a 1c c5 18 5b 87 dd 3c-a3 0d 02 03 01 00 01 ....[..<....... > 373:d=2 hl=2 l= 0 cons: cont [ 0 ] > 375:d=1 hl=2 l= 13 cons: SEQUENCE > 377:d=2 hl=2 l= 9 prim: OBJECT :sha256WithRSAEncryption > 388:d=2 hl=2 l= 0 prim: NULL > 390:d=1 hl=4 l= 257 prim: BIT STRING > 0000 - 00 71 86 f1 88 7e 4b c9-66 36 6a 07 f0 76 64 4b .q...~K.f6j..vdK > 0010 - 55 70 e0 e3 fc 18 5f 99-28 d4 95 c4 3b e0 d7 52 Up...._.(...;..R > 0020 - 64 2e 42 52 c9 5c cb ba-33 25 08 80 5e 24 62 6d d.BR.\..3%..^$bm > 0030 - a1 8e 70 f9 9e 20 66 3a-14 d6 cb 10 25 93 fc 5a ..p.. f:....%..Z > 0040 - f6 79 c8 a8 ce f6 9d 0c-cf 8a 96 9f 76 72 a4 f7 .y..........vr.. > 0050 - 66 8c 2e 4a 35 f4 51 5f-b5 cd fc b6 a6 ee 4e 06 f..J5.Q_......N. > 0060 - d2 9f 6c 6b 34 a4 19 6c-0b a6 cb 2b 25 47 da ce ..lk4..l...+%G.. > 0070 - 32 a1 89 6e 04 47 86 46-e5 6f eb d1 e6 65 73 86 2..n.G.F.o...es. > 0080 - 13 a1 f4 4a f1 e3 2c e5-76 a6 e1 24 c2 d6 5c 33 ...J..,.v..$..\3 > 0090 - fc 6a d2 eb 33 0c 77 ca-56 b6 cb a7 e9 13 fa 6d .j..3.w.V......m > 00a0 - 0e 22 03 51 50 39 e0 91-ca 5d a7 d3 f5 5b cb 4c .".QP9...]...[.L > 00b0 - 2d 56 39 9b c6 ab 87 c7-9b 54 6c 55 17 b6 6d 62 -V9......TlU..mb > 00c0 - 28 62 e8 b3 d5 69 17 09-80 dc a8 6b 09 ed c6 18 (b...i.....k.... > 00d0 - 62 5f fd eb 9b 3a b7 a5-ab db 72 bc 55 df e8 fa b_...:....r.U... > 00e0 - ad 22 f1 bf 0d b3 79 e1-d2 09 4e a3 4e 61 5b 28 ."....y...N.Na[( > 00f0 - af ca 3d 1f 53 52 52 72-71 e9 73 28 fd 73 01 90 ..=.SRRrq.s(.s.. > 0100 - 95 . > > > Jon > > On Mon, Mar 26, 2018 at 5:36 PM, Michael Wojcik wrote: > I just tried the same commands on my system, using 1.0.2n, and didn't have any problems (as I'd expect). > > What's the output of openssl asn1parse -dump -in CSR.csr? > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From juriarte at redhat.com Mon Mar 26 15:55:04 2018 From: juriarte at redhat.com (Jon Uriarte) Date: Mon, 26 Mar 2018 17:55:04 +0200 Subject: [openssl-users] CSR verify failure In-Reply-To: <071BD49D-F44C-4B15-8A78-9635CF576673@felipegasper.com> References: <071BD49D-F44C-4B15-8A78-9635CF576673@felipegasper.com> Message-ID: Sure, here it is: $ cat CSR.csr -----BEGIN CERTIFICATE REQUEST----- MIIChzCCAW8CAQAwQjELMAkGA1UEBhMCWFgxFTATBgNVBAcMDERlZmF1bHQgQ2l0 eTEcMBoGA1UECgwTRGVmYXVsdCBDb21wYW55IEx0ZDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAOJuhJcO1eqtGE8Yc7P4cSgSwlwyuAe8AYzseGCqwAEY XHVdAXaPspJcRyP2ndz2AmYfytPPogFEWPnf86WKyaNHp4Aan2LEo0Z345Zqhb8G rApR6hqdAyqATGNrgYchtVZNo1JN2bRgY/MUXqdunfS3W33LEJwg0b7tf4KBHPLw lOqkyWo75xvMROcMISRX+k5NbckAsXkX5H52lryYQrirzqgHR8C8Bqe4pzYHLsqA 2Sw6F+emfOxTGmqhN6O2WQBryP5/9CpySHST1oG5wDtPqZ2EhE1gdpeQDPjHRiaU kITBlcsAQY0LNUEqqKnqc/0IgZJGAxocxRhbh908ow0CAwEAAaAAMA0GCSqGSIb3 DQEBCwUAA4IBAQBxhvGIfkvJZjZqB/B2ZEtVcODj/BhfmSjUlcQ74NdSZC5CUslc y7ozJQiAXiRibaGOcPmeIGY6FNbLECWT/Fr2eciozvadDM+Klp92cqT3ZowuSjX0 UV+1zfy2pu5OBtKfbGs0pBlsC6bLKyVH2s4yoYluBEeGRuVv69HmZXOGE6H0SvHj LOV2puEkwtZcM/xq0uszDHfKVrbLp+kT+m0OIgNRUDngkcpdp9P1W8tMLVY5m8ar h8ebVGxVF7ZtYihi6LPVaRcJgNyoawntxhhiX/3rmzq3pavbcrxV3+j6rSLxvw2z eeHSCU6jTmFbKK/KPR9TUlJycelzKP1zAZCV -----END CERTIFICATE REQUEST----- Jon On Mon, Mar 26, 2018 at 5:49 PM, Felipe Gasper wrote: > But what is the actual PEM of the CSR? > > It should look like: > > -----BEGIN CERTIFICATE REQUEST----- > ... > -----END CERTIFICATE REQUEST----- > > -FG > > > On Mar 26, 2018, at 11:47 AM, Jon Uriarte wrote: > > > > Thanks for your replies. > > > > I'm creating the CSR with the default values. > > > > $ openssl req -noout -text -in CSR.csr > > Certificate Request: > > Data: > > Version: 0 (0x0) > > Subject: C=XX, L=Default City, O=Default Company Ltd > > Subject Public Key Info: > > Public Key Algorithm: rsaEncryption > > Public-Key: (2048 bit) > > Modulus: > > 00:e2:6e:84:97:0e:d5:ea:ad:18:4f:18:73:b3:f8: > > 71:28:12:c2:5c:32:b8:07:bc:01:8c:ec:78:60:aa: > > c0:01:18:5c:75:5d:01:76:8f:b2:92:5c:47:23:f6: > > 9d:dc:f6:02:66:1f:ca:d3:cf:a2:01:44:58:f9:df: > > f3:a5:8a:c9:a3:47:a7:80:1a:9f:62:c4:a3:46:77: > > e3:96:6a:85:bf:06:ac:0a:51:ea:1a:9d:03:2a:80: > > 4c:63:6b:81:87:21:b5:56:4d:a3:52:4d:d9:b4:60: > > 63:f3:14:5e:a7:6e:9d:f4:b7:5b:7d:cb:10:9c:20: > > d1:be:ed:7f:82:81:1c:f2:f0:94:ea:a4:c9:6a:3b: > > e7:1b:cc:44:e7:0c:21:24:57:fa:4e:4d:6d:c9:00: > > b1:79:17:e4:7e:76:96:bc:98:42:b8:ab:ce:a8:07: > > 47:c0:bc:06:a7:b8:a7:36:07:2e:ca:80:d9:2c:3a: > > 17:e7:a6:7c:ec:53:1a:6a:a1:37:a3:b6:59:00:6b: > > c8:fe:7f:f4:2a:72:48:74:93:d6:81:b9:c0:3b:4f: > > a9:9d:84:84:4d:60:76:97:90:0c:f8:c7:46:26:94: > > 90:84:c1:95:cb:00:41:8d:0b:35:41:2a:a8:a9:ea: > > 73:fd:08:81:92:46:03:1a:1c:c5:18:5b:87:dd:3c: > > a3:0d > > Exponent: 65537 (0x10001) > > Attributes: > > a0:00 > > Signature Algorithm: sha256WithRSAEncryption > > 71:86:f1:88:7e:4b:c9:66:36:6a:07:f0:76:64:4b:55:70:e0: > > e3:fc:18:5f:99:28:d4:95:c4:3b:e0:d7:52:64:2e:42:52:c9: > > 5c:cb:ba:33:25:08:80:5e:24:62:6d:a1:8e:70:f9:9e:20:66: > > 3a:14:d6:cb:10:25:93:fc:5a:f6:79:c8:a8:ce:f6:9d:0c:cf: > > 8a:96:9f:76:72:a4:f7:66:8c:2e:4a:35:f4:51:5f:b5:cd:fc: > > b6:a6:ee:4e:06:d2:9f:6c:6b:34:a4:19:6c:0b:a6:cb:2b:25: > > 47:da:ce:32:a1:89:6e:04:47:86:46:e5:6f:eb:d1:e6:65:73: > > 86:13:a1:f4:4a:f1:e3:2c:e5:76:a6:e1:24:c2:d6:5c:33:fc: > > 6a:d2:eb:33:0c:77:ca:56:b6:cb:a7:e9:13:fa:6d:0e:22:03: > > 51:50:39:e0:91:ca:5d:a7:d3:f5:5b:cb:4c:2d:56:39:9b:c6: > > ab:87:c7:9b:54:6c:55:17:b6:6d:62:28:62:e8:b3:d5:69:17: > > 09:80:dc:a8:6b:09:ed:c6:18:62:5f:fd:eb:9b:3a:b7:a5:ab: > > db:72:bc:55:df:e8:fa:ad:22:f1:bf:0d:b3:79:e1:d2:09:4e: > > a3:4e:61:5b:28:af:ca:3d:1f:53:52:52:72:71:e9:73:28:fd: > > 73:01:90:95 > > > > > > $ openssl asn1parse -dump -in CSR.csr > > 0:d=0 hl=4 l= 647 cons: SEQUENCE > > 4:d=1 hl=4 l= 367 cons: SEQUENCE > > 8:d=2 hl=2 l= 1 prim: INTEGER :00 > > 11:d=2 hl=2 l= 66 cons: SEQUENCE > > 13:d=3 hl=2 l= 11 cons: SET > > 15:d=4 hl=2 l= 9 cons: SEQUENCE > > 17:d=5 hl=2 l= 3 prim: OBJECT :countryName > > 22:d=5 hl=2 l= 2 prim: PRINTABLESTRING :XX > > 26:d=3 hl=2 l= 21 cons: SET > > 28:d=4 hl=2 l= 19 cons: SEQUENCE > > 30:d=5 hl=2 l= 3 prim: OBJECT :localityName > > 35:d=5 hl=2 l= 12 prim: UTF8STRING :Default City > > 49:d=3 hl=2 l= 28 cons: SET > > 51:d=4 hl=2 l= 26 cons: SEQUENCE > > 53:d=5 hl=2 l= 3 prim: OBJECT :organizationName > > 58:d=5 hl=2 l= 19 prim: UTF8STRING :Default Company Ltd > > 79:d=2 hl=4 l= 290 cons: SEQUENCE > > 83:d=3 hl=2 l= 13 cons: SEQUENCE > > 85:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption > > 96:d=4 hl=2 l= 0 prim: NULL > > 98:d=3 hl=4 l= 271 prim: BIT STRING > > 0000 - 00 30 82 01 0a 02 82 01-01 00 e2 6e 84 97 0e d5 > .0.........n.... > > 0010 - ea ad 18 4f 18 73 b3 f8-71 28 12 c2 5c 32 b8 07 > ...O.s..q(..\2.. > > 0020 - bc 01 8c ec 78 60 aa c0-01 18 5c 75 5d 01 76 8f > ....x`....\u].v. > > 0030 - b2 92 5c 47 23 f6 9d dc-f6 02 66 1f ca d3 cf a2 > ..\G#.....f..... > > 0040 - 01 44 58 f9 df f3 a5 8a-c9 a3 47 a7 80 1a 9f 62 > .DX.......G....b > > 0050 - c4 a3 46 77 e3 96 6a 85-bf 06 ac 0a 51 ea 1a 9d > ..Fw..j.....Q... > > 0060 - 03 2a 80 4c 63 6b 81 87-21 b5 56 4d a3 52 4d d9 > .*.Lck..!.VM.RM. > > 0070 - b4 60 63 f3 14 5e a7 6e-9d f4 b7 5b 7d cb 10 9c > .`c..^.n...[}... > > 0080 - 20 d1 be ed 7f 82 81 1c-f2 f0 94 ea a4 c9 6a 3b > .............j; > > 0090 - e7 1b cc 44 e7 0c 21 24-57 fa 4e 4d 6d c9 00 b1 > ...D..!$W.NMm... > > 00a0 - 79 17 e4 7e 76 96 bc 98-42 b8 ab ce a8 07 47 c0 > y..~v...B.....G. > > 00b0 - bc 06 a7 b8 a7 36 07 2e-ca 80 d9 2c 3a 17 e7 a6 > .....6.....,:... > > 00c0 - 7c ec 53 1a 6a a1 37 a3-b6 59 00 6b c8 fe 7f f4 > |.S.j.7..Y.k.... > > 00d0 - 2a 72 48 74 93 d6 81 b9-c0 3b 4f a9 9d 84 84 4d > *rHt.....;O....M > > 00e0 - 60 76 97 90 0c f8 c7 46-26 94 90 84 c1 95 cb 00 > `v.....F&....... > > 00f0 - 41 8d 0b 35 41 2a a8 a9-ea 73 fd 08 81 92 46 03 > A..5A*...s....F. > > 0100 - 1a 1c c5 18 5b 87 dd 3c-a3 0d 02 03 01 00 01 > ....[..<....... > > 373:d=2 hl=2 l= 0 cons: cont [ 0 ] > > 375:d=1 hl=2 l= 13 cons: SEQUENCE > > 377:d=2 hl=2 l= 9 prim: OBJECT :sha256WithRSAEncryption > > 388:d=2 hl=2 l= 0 prim: NULL > > 390:d=1 hl=4 l= 257 prim: BIT STRING > > 0000 - 00 71 86 f1 88 7e 4b c9-66 36 6a 07 f0 76 64 4b > .q...~K.f6j..vdK > > 0010 - 55 70 e0 e3 fc 18 5f 99-28 d4 95 c4 3b e0 d7 52 > Up...._.(...;..R > > 0020 - 64 2e 42 52 c9 5c cb ba-33 25 08 80 5e 24 62 6d > d.BR.\..3%..^$bm > > 0030 - a1 8e 70 f9 9e 20 66 3a-14 d6 cb 10 25 93 fc 5a ..p.. > f:....%..Z > > 0040 - f6 79 c8 a8 ce f6 9d 0c-cf 8a 96 9f 76 72 a4 f7 > .y..........vr.. > > 0050 - 66 8c 2e 4a 35 f4 51 5f-b5 cd fc b6 a6 ee 4e 06 > f..J5.Q_......N. > > 0060 - d2 9f 6c 6b 34 a4 19 6c-0b a6 cb 2b 25 47 da ce > ..lk4..l...+%G.. > > 0070 - 32 a1 89 6e 04 47 86 46-e5 6f eb d1 e6 65 73 86 > 2..n.G.F.o...es. > > 0080 - 13 a1 f4 4a f1 e3 2c e5-76 a6 e1 24 c2 d6 5c 33 > ...J..,.v..$..\3 > > 0090 - fc 6a d2 eb 33 0c 77 ca-56 b6 cb a7 e9 13 fa 6d > .j..3.w.V......m > > 00a0 - 0e 22 03 51 50 39 e0 91-ca 5d a7 d3 f5 5b cb 4c > .".QP9...]...[.L > > 00b0 - 2d 56 39 9b c6 ab 87 c7-9b 54 6c 55 17 b6 6d 62 > -V9......TlU..mb > > 00c0 - 28 62 e8 b3 d5 69 17 09-80 dc a8 6b 09 ed c6 18 > (b...i.....k.... > > 00d0 - 62 5f fd eb 9b 3a b7 a5-ab db 72 bc 55 df e8 fa > b_...:....r.U... > > 00e0 - ad 22 f1 bf 0d b3 79 e1-d2 09 4e a3 4e 61 5b 28 > ."....y...N.Na[( > > 00f0 - af ca 3d 1f 53 52 52 72-71 e9 73 28 fd 73 01 90 > ..=.SRRrq.s(.s.. > > 0100 - 95 . > > > > > > Jon > > > > On Mon, Mar 26, 2018 at 5:36 PM, Michael Wojcik < > Michael.Wojcik at microfocus.com> wrote: > > I just tried the same commands on my system, using 1.0.2n, and didn't > have any problems (as I'd expect). > > > > What's the output of openssl asn1parse -dump -in CSR.csr? > > > > -- > > Michael Wojcik > > Distinguished Engineer, Micro Focus > > > > > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe at felipegasper.com Mon Mar 26 16:15:58 2018 From: felipe at felipegasper.com (Felipe Gasper) Date: Mon, 26 Mar 2018 12:15:58 -0400 Subject: [openssl-users] CSR verify failure In-Reply-To: References: <071BD49D-F44C-4B15-8A78-9635CF576673@felipegasper.com> Message-ID: <85E7748F-44FF-4246-937E-36C9B091DDCE@felipegasper.com> I see the same errors with 1.0.2n. Going by posts I see out-and-about about this error, there seem to be two possibilities: 1) There?s an RSA padding scheme mismatch. Maybe your openssl.cnf has something nonstandard, e.g., raw padding rather than PKCS1? 2) The signature is simply incorrect. It?s been a while since I did this, but I *believe* you could check this by extracting the bytes for the first-nested SEQUENCE from the ASN.1 structure, get the signature for that blob against your private key, then compare that to the CSR?s stored signature. They should be the same. Also, did you verify that the modulus and exponent as stored in the CSR match up against your private key file? -F > On Mar 26, 2018, at 11:55 AM, Jon Uriarte wrote: > > Sure, here it is: > > $ cat CSR.csr > -----BEGIN CERTIFICATE REQUEST----- > MIIChzCCAW8CAQAwQjELMAkGA1UEBhMCWFgxFTATBgNVBAcMDERlZmF1bHQgQ2l0 > eTEcMBoGA1UECgwTRGVmYXVsdCBDb21wYW55IEx0ZDCCASIwDQYJKoZIhvcNAQEB > BQADggEPADCCAQoCggEBAOJuhJcO1eqtGE8Yc7P4cSgSwlwyuAe8AYzseGCqwAEY > XHVdAXaPspJcRyP2ndz2AmYfytPPogFEWPnf86WKyaNHp4Aan2LEo0Z345Zqhb8G > rApR6hqdAyqATGNrgYchtVZNo1JN2bRgY/MUXqdunfS3W33LEJwg0b7tf4KBHPLw > lOqkyWo75xvMROcMISRX+k5NbckAsXkX5H52lryYQrirzqgHR8C8Bqe4pzYHLsqA > 2Sw6F+emfOxTGmqhN6O2WQBryP5/9CpySHST1oG5wDtPqZ2EhE1gdpeQDPjHRiaU > kITBlcsAQY0LNUEqqKnqc/0IgZJGAxocxRhbh908ow0CAwEAAaAAMA0GCSqGSIb3 > DQEBCwUAA4IBAQBxhvGIfkvJZjZqB/B2ZEtVcODj/BhfmSjUlcQ74NdSZC5CUslc > y7ozJQiAXiRibaGOcPmeIGY6FNbLECWT/Fr2eciozvadDM+Klp92cqT3ZowuSjX0 > UV+1zfy2pu5OBtKfbGs0pBlsC6bLKyVH2s4yoYluBEeGRuVv69HmZXOGE6H0SvHj > LOV2puEkwtZcM/xq0uszDHfKVrbLp+kT+m0OIgNRUDngkcpdp9P1W8tMLVY5m8ar > h8ebVGxVF7ZtYihi6LPVaRcJgNyoawntxhhiX/3rmzq3pavbcrxV3+j6rSLxvw2z > eeHSCU6jTmFbKK/KPR9TUlJycelzKP1zAZCV > -----END CERTIFICATE REQUEST----- > > > Jon > > On Mon, Mar 26, 2018 at 5:49 PM, Felipe Gasper wrote: > But what is the actual PEM of the CSR? > > It should look like: > > -----BEGIN CERTIFICATE REQUEST----- > ... > -----END CERTIFICATE REQUEST----- > > -FG > > > On Mar 26, 2018, at 11:47 AM, Jon Uriarte wrote: > > > > Thanks for your replies. > > > > I'm creating the CSR with the default values. > > > > $ openssl req -noout -text -in CSR.csr > > Certificate Request: > > Data: > > Version: 0 (0x0) > > Subject: C=XX, L=Default City, O=Default Company Ltd > > Subject Public Key Info: > > Public Key Algorithm: rsaEncryption > > Public-Key: (2048 bit) > > Modulus: > > 00:e2:6e:84:97:0e:d5:ea:ad:18:4f:18:73:b3:f8: > > 71:28:12:c2:5c:32:b8:07:bc:01:8c:ec:78:60:aa: > > c0:01:18:5c:75:5d:01:76:8f:b2:92:5c:47:23:f6: > > 9d:dc:f6:02:66:1f:ca:d3:cf:a2:01:44:58:f9:df: > > f3:a5:8a:c9:a3:47:a7:80:1a:9f:62:c4:a3:46:77: > > e3:96:6a:85:bf:06:ac:0a:51:ea:1a:9d:03:2a:80: > > 4c:63:6b:81:87:21:b5:56:4d:a3:52:4d:d9:b4:60: > > 63:f3:14:5e:a7:6e:9d:f4:b7:5b:7d:cb:10:9c:20: > > d1:be:ed:7f:82:81:1c:f2:f0:94:ea:a4:c9:6a:3b: > > e7:1b:cc:44:e7:0c:21:24:57:fa:4e:4d:6d:c9:00: > > b1:79:17:e4:7e:76:96:bc:98:42:b8:ab:ce:a8:07: > > 47:c0:bc:06:a7:b8:a7:36:07:2e:ca:80:d9:2c:3a: > > 17:e7:a6:7c:ec:53:1a:6a:a1:37:a3:b6:59:00:6b: > > c8:fe:7f:f4:2a:72:48:74:93:d6:81:b9:c0:3b:4f: > > a9:9d:84:84:4d:60:76:97:90:0c:f8:c7:46:26:94: > > 90:84:c1:95:cb:00:41:8d:0b:35:41:2a:a8:a9:ea: > > 73:fd:08:81:92:46:03:1a:1c:c5:18:5b:87:dd:3c: > > a3:0d > > Exponent: 65537 (0x10001) > > Attributes: > > a0:00 > > Signature Algorithm: sha256WithRSAEncryption > > 71:86:f1:88:7e:4b:c9:66:36:6a:07:f0:76:64:4b:55:70:e0: > > e3:fc:18:5f:99:28:d4:95:c4:3b:e0:d7:52:64:2e:42:52:c9: > > 5c:cb:ba:33:25:08:80:5e:24:62:6d:a1:8e:70:f9:9e:20:66: > > 3a:14:d6:cb:10:25:93:fc:5a:f6:79:c8:a8:ce:f6:9d:0c:cf: > > 8a:96:9f:76:72:a4:f7:66:8c:2e:4a:35:f4:51:5f:b5:cd:fc: > > b6:a6:ee:4e:06:d2:9f:6c:6b:34:a4:19:6c:0b:a6:cb:2b:25: > > 47:da:ce:32:a1:89:6e:04:47:86:46:e5:6f:eb:d1:e6:65:73: > > 86:13:a1:f4:4a:f1:e3:2c:e5:76:a6:e1:24:c2:d6:5c:33:fc: > > 6a:d2:eb:33:0c:77:ca:56:b6:cb:a7:e9:13:fa:6d:0e:22:03: > > 51:50:39:e0:91:ca:5d:a7:d3:f5:5b:cb:4c:2d:56:39:9b:c6: > > ab:87:c7:9b:54:6c:55:17:b6:6d:62:28:62:e8:b3:d5:69:17: > > 09:80:dc:a8:6b:09:ed:c6:18:62:5f:fd:eb:9b:3a:b7:a5:ab: > > db:72:bc:55:df:e8:fa:ad:22:f1:bf:0d:b3:79:e1:d2:09:4e: > > a3:4e:61:5b:28:af:ca:3d:1f:53:52:52:72:71:e9:73:28:fd: > > 73:01:90:95 > > > > > > $ openssl asn1parse -dump -in CSR.csr > > 0:d=0 hl=4 l= 647 cons: SEQUENCE > > 4:d=1 hl=4 l= 367 cons: SEQUENCE > > 8:d=2 hl=2 l= 1 prim: INTEGER :00 > > 11:d=2 hl=2 l= 66 cons: SEQUENCE > > 13:d=3 hl=2 l= 11 cons: SET > > 15:d=4 hl=2 l= 9 cons: SEQUENCE > > 17:d=5 hl=2 l= 3 prim: OBJECT :countryName > > 22:d=5 hl=2 l= 2 prim: PRINTABLESTRING :XX > > 26:d=3 hl=2 l= 21 cons: SET > > 28:d=4 hl=2 l= 19 cons: SEQUENCE > > 30:d=5 hl=2 l= 3 prim: OBJECT :localityName > > 35:d=5 hl=2 l= 12 prim: UTF8STRING :Default City > > 49:d=3 hl=2 l= 28 cons: SET > > 51:d=4 hl=2 l= 26 cons: SEQUENCE > > 53:d=5 hl=2 l= 3 prim: OBJECT :organizationName > > 58:d=5 hl=2 l= 19 prim: UTF8STRING :Default Company Ltd > > 79:d=2 hl=4 l= 290 cons: SEQUENCE > > 83:d=3 hl=2 l= 13 cons: SEQUENCE > > 85:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption > > 96:d=4 hl=2 l= 0 prim: NULL > > 98:d=3 hl=4 l= 271 prim: BIT STRING > > 0000 - 00 30 82 01 0a 02 82 01-01 00 e2 6e 84 97 0e d5 .0.........n.... > > 0010 - ea ad 18 4f 18 73 b3 f8-71 28 12 c2 5c 32 b8 07 ...O.s..q(..\2.. > > 0020 - bc 01 8c ec 78 60 aa c0-01 18 5c 75 5d 01 76 8f ....x`....\u].v. > > 0030 - b2 92 5c 47 23 f6 9d dc-f6 02 66 1f ca d3 cf a2 ..\G#.....f..... > > 0040 - 01 44 58 f9 df f3 a5 8a-c9 a3 47 a7 80 1a 9f 62 .DX.......G....b > > 0050 - c4 a3 46 77 e3 96 6a 85-bf 06 ac 0a 51 ea 1a 9d ..Fw..j.....Q... > > 0060 - 03 2a 80 4c 63 6b 81 87-21 b5 56 4d a3 52 4d d9 .*.Lck..!.VM.RM. > > 0070 - b4 60 63 f3 14 5e a7 6e-9d f4 b7 5b 7d cb 10 9c .`c..^.n...[}... > > 0080 - 20 d1 be ed 7f 82 81 1c-f2 f0 94 ea a4 c9 6a 3b .............j; > > 0090 - e7 1b cc 44 e7 0c 21 24-57 fa 4e 4d 6d c9 00 b1 ...D..!$W.NMm... > > 00a0 - 79 17 e4 7e 76 96 bc 98-42 b8 ab ce a8 07 47 c0 y..~v...B.....G. > > 00b0 - bc 06 a7 b8 a7 36 07 2e-ca 80 d9 2c 3a 17 e7 a6 .....6.....,:... > > 00c0 - 7c ec 53 1a 6a a1 37 a3-b6 59 00 6b c8 fe 7f f4 |.S.j.7..Y.k.... > > 00d0 - 2a 72 48 74 93 d6 81 b9-c0 3b 4f a9 9d 84 84 4d *rHt.....;O....M > > 00e0 - 60 76 97 90 0c f8 c7 46-26 94 90 84 c1 95 cb 00 `v.....F&....... > > 00f0 - 41 8d 0b 35 41 2a a8 a9-ea 73 fd 08 81 92 46 03 A..5A*...s....F. > > 0100 - 1a 1c c5 18 5b 87 dd 3c-a3 0d 02 03 01 00 01 ....[..<....... > > 373:d=2 hl=2 l= 0 cons: cont [ 0 ] > > 375:d=1 hl=2 l= 13 cons: SEQUENCE > > 377:d=2 hl=2 l= 9 prim: OBJECT :sha256WithRSAEncryption > > 388:d=2 hl=2 l= 0 prim: NULL > > 390:d=1 hl=4 l= 257 prim: BIT STRING > > 0000 - 00 71 86 f1 88 7e 4b c9-66 36 6a 07 f0 76 64 4b .q...~K.f6j..vdK > > 0010 - 55 70 e0 e3 fc 18 5f 99-28 d4 95 c4 3b e0 d7 52 Up...._.(...;..R > > 0020 - 64 2e 42 52 c9 5c cb ba-33 25 08 80 5e 24 62 6d d.BR.\..3%..^$bm > > 0030 - a1 8e 70 f9 9e 20 66 3a-14 d6 cb 10 25 93 fc 5a ..p.. f:....%..Z > > 0040 - f6 79 c8 a8 ce f6 9d 0c-cf 8a 96 9f 76 72 a4 f7 .y..........vr.. > > 0050 - 66 8c 2e 4a 35 f4 51 5f-b5 cd fc b6 a6 ee 4e 06 f..J5.Q_......N. > > 0060 - d2 9f 6c 6b 34 a4 19 6c-0b a6 cb 2b 25 47 da ce ..lk4..l...+%G.. > > 0070 - 32 a1 89 6e 04 47 86 46-e5 6f eb d1 e6 65 73 86 2..n.G.F.o...es. > > 0080 - 13 a1 f4 4a f1 e3 2c e5-76 a6 e1 24 c2 d6 5c 33 ...J..,.v..$..\3 > > 0090 - fc 6a d2 eb 33 0c 77 ca-56 b6 cb a7 e9 13 fa 6d .j..3.w.V......m > > 00a0 - 0e 22 03 51 50 39 e0 91-ca 5d a7 d3 f5 5b cb 4c .".QP9...]...[.L > > 00b0 - 2d 56 39 9b c6 ab 87 c7-9b 54 6c 55 17 b6 6d 62 -V9......TlU..mb > > 00c0 - 28 62 e8 b3 d5 69 17 09-80 dc a8 6b 09 ed c6 18 (b...i.....k.... > > 00d0 - 62 5f fd eb 9b 3a b7 a5-ab db 72 bc 55 df e8 fa b_...:....r.U... > > 00e0 - ad 22 f1 bf 0d b3 79 e1-d2 09 4e a3 4e 61 5b 28 ."....y...N.Na[( > > 00f0 - af ca 3d 1f 53 52 52 72-71 e9 73 28 fd 73 01 90 ..=.SRRrq.s(.s.. > > 0100 - 95 . > > > > > > Jon > > > > On Mon, Mar 26, 2018 at 5:36 PM, Michael Wojcik wrote: > > I just tried the same commands on my system, using 1.0.2n, and didn't have any problems (as I'd expect). > > > > What's the output of openssl asn1parse -dump -in CSR.csr? > > > > -- > > Michael Wojcik > > Distinguished Engineer, Micro Focus > > > > > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From Michael.Wojcik at microfocus.com Mon Mar 26 16:59:07 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 26 Mar 2018 16:59:07 +0000 Subject: [openssl-users] CSR verify failure In-Reply-To: References: <071BD49D-F44C-4B15-8A78-9635CF576673@felipegasper.com> Message-ID: OK, I see the verify error with the CSR you sent, so it's an issue with creating the CSR, not with verifying it. Beyond that I don't see the issue, but I'd have to debug it (or decrypt the signature manually) to see what exactly the problem is. OpenSSL is complaining that it expects the signature to use PKCS#1 type 1 padding, but the block-type byte doesn't have value 1, i.e. PKCS#1 v1.5 padding. I don't know why openssl req -new on your system might have generated a signature with some other type of padding. openssl req doesn't appear to honor -sigopt rsa_padding_mode, for example; I just tried it, and it didn't produce an error, but didn't seem to have any effect either. -- Michael Wojcik Distinguished Engineer, Micro Focus From juriarte at redhat.com Mon Mar 26 17:41:05 2018 From: juriarte at redhat.com (Jon Uriarte) Date: Mon, 26 Mar 2018 19:41:05 +0200 Subject: [openssl-users] CSR verify failure In-Reply-To: <85E7748F-44FF-4246-937E-36C9B091DDCE@felipegasper.com> References: <071BD49D-F44C-4B15-8A78-9635CF576673@felipegasper.com> <85E7748F-44FF-4246-937E-36C9B091DDCE@felipegasper.com> Message-ID: On Mon, Mar 26, 2018 at 6:15 PM, Felipe Gasper wrote: > I see the same errors with 1.0.2n. > > Going by posts I see out-and-about about this error, there seem to be two > possibilities: > > 1) There?s an RSA padding scheme mismatch. Maybe your openssl.cnf has > something nonstandard, e.g., raw padding rather than PKCS1? > I paste the openssl.cnf file [1] 2) The signature is simply incorrect. It?s been a while since I did this, > but I *believe* you could check this by extracting the bytes for the > first-nested SEQUENCE from the ASN.1 structure, get the signature for that > blob against your private key, then compare that to the CSR?s stored > signature. They should be the same. > I'm not completely sure about how to check this, but I see that some data in the ASN.1 structure matches the modulus in the CSR's key modulus. 0000 - 00 30 82 01 0a 02 82 01-01 *00 e2 6e 84 97 0e d5* .0.........n.... 0010 - *ea ad 18 4f 18 73 b3 f8*-*71 28 12 c2 5c 32 b8 07* ...O.s..q(..\2.. 0020 - *bc 01 8c ec 78 60 aa c0*-*01 18 5c 75 5d 01 76 8f* ....x`....\u].v. 0030 - *b2 92 5c 47 23 f6 9d dc*-*f6 02 66 1f ca d3 cf a2* ..\G#.....f..... 0040 - *01 44 58 f9 df f3 a5 8a*-*c9 a3 47 a7 80 1a 9f 62* .DX.......G....b 0050 - *c4 a3 46 77 e3 96 6a 85*-*bf 06 ac 0a 51 ea 1a 9d* ..Fw..j.....Q... 0060 - *03 2a 80 4c 63 6b 81 87*-*21 b5 56 4d a3 52 4d d9* .*.Lck..!.VM.RM. 0070 - *b4 60 63 f3 14 5e a7 6e*-*9d f4 b7 5b 7d cb 10 9c* .`c..^.n...[}... 0080 - *20 d1 be ed 7f 82 81 1c*-*f2 f0 94 ea a4 c9 6a 3b* .............j; 0090 - *e7 1b cc 44 e7 0c 21 24*-*57 fa 4e 4d 6d c9 00 b1* ...D..!$W.NMm... 00a0 - *79 17 e4 7e 76 96 bc 98*-*42 b8 ab ce a8 07 47 c0* y..~v...B.....G. 00b0 - *bc 06 a7 b8 a7 36 07 2e*-*ca 80 d9 2c 3a 17 e7 a6* .....6.....,:... 00c0 - *7c ec 53 1a 6a a1 37 a3*-*b6 59 00 6b c8 fe 7f f4* |.S.j.7..Y.k.... 00d0 - *2a 72 48 74 93 d6 81 b9*-*c0 3b 4f a9 9d 84 84 4d* *rHt.....;O....M 00e0 - *60 76 97 90 0c f8 c7 46*-*26 94 90 84 c1 95 cb 00* `v.....F&....... 00f0 - *41 8d 0b 35 41 2a a8 a9*-*ea 73 fd 08 81 92 46 03* A..5A*...s....F. 0100 - *1a 1c c5 18 5b 87 dd 3c*-*a3 0d* 02 03 01 00 01 ....[..<....... Modulus: 00:e2:6e:84:97:0e:d5:ea:ad:18:4f:18:73:b3:f8: 71:28:12:c2:5c:32:b8:07:bc:01:8c:ec:78:60:aa: c0:01:18:5c:75:5d:01:76:8f:b2:92:5c:47:23:f6: 9d:dc:f6:02:66:1f:ca:d3:cf:a2:01:44:58:f9:df: f3:a5:8a:c9:a3:47:a7:80:1a:9f:62:c4:a3:46:77: e3:96:6a:85:bf:06:ac:0a:51:ea:1a:9d:03:2a:80: 4c:63:6b:81:87:21:b5:56:4d:a3:52:4d:d9:b4:60: 63:f3:14:5e:a7:6e:9d:f4:b7:5b:7d:cb:10:9c:20: d1:be:ed:7f:82:81:1c:f2:f0:94:ea:a4:c9:6a:3b: e7:1b:cc:44:e7:0c:21:24:57:fa:4e:4d:6d:c9:00: b1:79:17:e4:7e:76:96:bc:98:42:b8:ab:ce:a8:07: 47:c0:bc:06:a7:b8:a7:36:07:2e:ca:80:d9:2c:3a: 17:e7:a6:7c:ec:53:1a:6a:a1:37:a3:b6:59:00:6b: c8:fe:7f:f4:2a:72:48:74:93:d6:81:b9:c0:3b:4f: a9:9d:84:84:4d:60:76:97:90:0c:f8:c7:46:26:94: 90:84:c1:95:cb:00:41:8d:0b:35:41:2a:a8:a9:ea: 73:fd:08:81:92:46:03:1a:1c:c5:18:5b:87:dd:3c: a3:0d > Also, did you verify that the modulus and exponent as stored in the CSR > match up against your private key file? > They match: $ openssl req -noout -text -in CSR.csr ... *Exponent: 65537 (0x10001)* $ openssl rsa -noout -text -in privateKey.key Private-Key: (2048 bit) modulus: ... *publicExponent: 65537 (0x10001)* $ openssl req -noout -modulus -in CSR.csr Modulus=E26E84970ED5EAAD184F1873B3F8712812C25C32B807BC018CEC7860AAC001185C755D01768FB2925C4723F69DDCF602661FCAD3C FA2014458F9DFF3A58AC9A347A7801A9F62C4A34677E3966A85BF06AC0A51EA1A9D032A804C636B818721B5564DA3524DD9B46063F3145EA7 6E9DF4B75B7DCB109C20D1BEED7F82811CF2F094EAA4C96A3BE71BCC44E70C212457FA4E4D6DC900B17917E47E7696BC9842B8ABCEA80747C 0BC06A7B8A736072ECA80D92C3A17E7A67CEC531A6AA137A3B659006BC8FE7FF42A72487493D681B9C03B4FA99D84844D607697900CF8C746 26949084C195CB00418D0B35412AA8A9EA73FD08819246031A1CC5185B87DD3CA30D $ openssl rsa -noout -modulus -in privateKey.key Modulus=E26E84970ED5EAAD184F1873B3F8712812C25C32B807BC018CEC7860AAC001185C755D01768FB2925C4723F69DDCF602661FCAD3C FA2014458F9DFF3A58AC9A347A7801A9F62C4A34677E3966A85BF06AC0A51EA1A9D032A804C636B818721B5564DA3524DD9B46063F3145EA7 6E9DF4B75B7DCB109C20D1BEED7F82811CF2F094EAA4C96A3BE71BCC44E70C212457FA4E4D6DC900B17917E47E7696BC9842B8ABCEA80747C 0BC06A7B8A736072ECA80D92C3A17E7A67CEC531A6AA137A3B659006BC8FE7FF42A72487493D681B9C03B4FA99D84844D607697900CF8C746 26949084C195CB00418D0B35412AA8A9EA73FD08819246031A1CC5185B87DD3CA30D $ openssl rsa -noout -modulus -in privateKey.key | openssl md5 (stdin)= *7eeda89fc0dcc018e8039af089d28609* $ openssl req -noout -modulus -in CSR.csr | openssl md5 (stdin)= *7eeda89fc0dcc018e8039af089d28609* > -F > [1] https://paste.fedoraproject.org/paste/Eats8N1qHT3npyLWCxS~aw Thank you Jon > > On Mar 26, 2018, at 11:55 AM, Jon Uriarte wrote: > > > > Sure, here it is: > > > > $ cat CSR.csr > > -----BEGIN CERTIFICATE REQUEST----- > > MIIChzCCAW8CAQAwQjELMAkGA1UEBhMCWFgxFTATBgNVBAcMDERlZmF1bHQgQ2l0 > > eTEcMBoGA1UECgwTRGVmYXVsdCBDb21wYW55IEx0ZDCCASIwDQYJKoZIhvcNAQEB > > BQADggEPADCCAQoCggEBAOJuhJcO1eqtGE8Yc7P4cSgSwlwyuAe8AYzseGCqwAEY > > XHVdAXaPspJcRyP2ndz2AmYfytPPogFEWPnf86WKyaNHp4Aan2LEo0Z345Zqhb8G > > rApR6hqdAyqATGNrgYchtVZNo1JN2bRgY/MUXqdunfS3W33LEJwg0b7tf4KBHPLw > > lOqkyWo75xvMROcMISRX+k5NbckAsXkX5H52lryYQrirzqgHR8C8Bqe4pzYHLsqA > > 2Sw6F+emfOxTGmqhN6O2WQBryP5/9CpySHST1oG5wDtPqZ2EhE1gdpeQDPjHRiaU > > kITBlcsAQY0LNUEqqKnqc/0IgZJGAxocxRhbh908ow0CAwEAAaAAMA0GCSqGSIb3 > > DQEBCwUAA4IBAQBxhvGIfkvJZjZqB/B2ZEtVcODj/BhfmSjUlcQ74NdSZC5CUslc > > y7ozJQiAXiRibaGOcPmeIGY6FNbLECWT/Fr2eciozvadDM+Klp92cqT3ZowuSjX0 > > UV+1zfy2pu5OBtKfbGs0pBlsC6bLKyVH2s4yoYluBEeGRuVv69HmZXOGE6H0SvHj > > LOV2puEkwtZcM/xq0uszDHfKVrbLp+kT+m0OIgNRUDngkcpdp9P1W8tMLVY5m8ar > > h8ebVGxVF7ZtYihi6LPVaRcJgNyoawntxhhiX/3rmzq3pavbcrxV3+j6rSLxvw2z > > eeHSCU6jTmFbKK/KPR9TUlJycelzKP1zAZCV > > -----END CERTIFICATE REQUEST----- > > > > > > Jon > > > > On Mon, Mar 26, 2018 at 5:49 PM, Felipe Gasper > wrote: > > But what is the actual PEM of the CSR? > > > > It should look like: > > > > -----BEGIN CERTIFICATE REQUEST----- > > ... > > -----END CERTIFICATE REQUEST----- > > > > -FG > > > > > On Mar 26, 2018, at 11:47 AM, Jon Uriarte wrote: > > > > > > Thanks for your replies. > > > > > > I'm creating the CSR with the default values. > > > > > > $ openssl req -noout -text -in CSR.csr > > > Certificate Request: > > > Data: > > > Version: 0 (0x0) > > > Subject: C=XX, L=Default City, O=Default Company Ltd > > > Subject Public Key Info: > > > Public Key Algorithm: rsaEncryption > > > Public-Key: (2048 bit) > > > Modulus: > > > 00:e2:6e:84:97:0e:d5:ea:ad:18:4f:18:73:b3:f8: > > > 71:28:12:c2:5c:32:b8:07:bc:01:8c:ec:78:60:aa: > > > c0:01:18:5c:75:5d:01:76:8f:b2:92:5c:47:23:f6: > > > 9d:dc:f6:02:66:1f:ca:d3:cf:a2:01:44:58:f9:df: > > > f3:a5:8a:c9:a3:47:a7:80:1a:9f:62:c4:a3:46:77: > > > e3:96:6a:85:bf:06:ac:0a:51:ea:1a:9d:03:2a:80: > > > 4c:63:6b:81:87:21:b5:56:4d:a3:52:4d:d9:b4:60: > > > 63:f3:14:5e:a7:6e:9d:f4:b7:5b:7d:cb:10:9c:20: > > > d1:be:ed:7f:82:81:1c:f2:f0:94:ea:a4:c9:6a:3b: > > > e7:1b:cc:44:e7:0c:21:24:57:fa:4e:4d:6d:c9:00: > > > b1:79:17:e4:7e:76:96:bc:98:42:b8:ab:ce:a8:07: > > > 47:c0:bc:06:a7:b8:a7:36:07:2e:ca:80:d9:2c:3a: > > > 17:e7:a6:7c:ec:53:1a:6a:a1:37:a3:b6:59:00:6b: > > > c8:fe:7f:f4:2a:72:48:74:93:d6:81:b9:c0:3b:4f: > > > a9:9d:84:84:4d:60:76:97:90:0c:f8:c7:46:26:94: > > > 90:84:c1:95:cb:00:41:8d:0b:35:41:2a:a8:a9:ea: > > > 73:fd:08:81:92:46:03:1a:1c:c5:18:5b:87:dd:3c: > > > a3:0d > > > Exponent: 65537 (0x10001) > > > Attributes: > > > a0:00 > > > Signature Algorithm: sha256WithRSAEncryption > > > 71:86:f1:88:7e:4b:c9:66:36:6a:07:f0:76:64:4b:55:70:e0: > > > e3:fc:18:5f:99:28:d4:95:c4:3b:e0:d7:52:64:2e:42:52:c9: > > > 5c:cb:ba:33:25:08:80:5e:24:62:6d:a1:8e:70:f9:9e:20:66: > > > 3a:14:d6:cb:10:25:93:fc:5a:f6:79:c8:a8:ce:f6:9d:0c:cf: > > > 8a:96:9f:76:72:a4:f7:66:8c:2e:4a:35:f4:51:5f:b5:cd:fc: > > > b6:a6:ee:4e:06:d2:9f:6c:6b:34:a4:19:6c:0b:a6:cb:2b:25: > > > 47:da:ce:32:a1:89:6e:04:47:86:46:e5:6f:eb:d1:e6:65:73: > > > 86:13:a1:f4:4a:f1:e3:2c:e5:76:a6:e1:24:c2:d6:5c:33:fc: > > > 6a:d2:eb:33:0c:77:ca:56:b6:cb:a7:e9:13:fa:6d:0e:22:03: > > > 51:50:39:e0:91:ca:5d:a7:d3:f5:5b:cb:4c:2d:56:39:9b:c6: > > > ab:87:c7:9b:54:6c:55:17:b6:6d:62:28:62:e8:b3:d5:69:17: > > > 09:80:dc:a8:6b:09:ed:c6:18:62:5f:fd:eb:9b:3a:b7:a5:ab: > > > db:72:bc:55:df:e8:fa:ad:22:f1:bf:0d:b3:79:e1:d2:09:4e: > > > a3:4e:61:5b:28:af:ca:3d:1f:53:52:52:72:71:e9:73:28:fd: > > > 73:01:90:95 > > > > > > > > > $ openssl asn1parse -dump -in CSR.csr > > > 0:d=0 hl=4 l= 647 cons: SEQUENCE > > > 4:d=1 hl=4 l= 367 cons: SEQUENCE > > > 8:d=2 hl=2 l= 1 prim: INTEGER :00 > > > 11:d=2 hl=2 l= 66 cons: SEQUENCE > > > 13:d=3 hl=2 l= 11 cons: SET > > > 15:d=4 hl=2 l= 9 cons: SEQUENCE > > > 17:d=5 hl=2 l= 3 prim: OBJECT :countryName > > > 22:d=5 hl=2 l= 2 prim: PRINTABLESTRING :XX > > > 26:d=3 hl=2 l= 21 cons: SET > > > 28:d=4 hl=2 l= 19 cons: SEQUENCE > > > 30:d=5 hl=2 l= 3 prim: OBJECT :localityName > > > 35:d=5 hl=2 l= 12 prim: UTF8STRING :Default City > > > 49:d=3 hl=2 l= 28 cons: SET > > > 51:d=4 hl=2 l= 26 cons: SEQUENCE > > > 53:d=5 hl=2 l= 3 prim: OBJECT :organizationName > > > 58:d=5 hl=2 l= 19 prim: UTF8STRING :Default Company Ltd > > > 79:d=2 hl=4 l= 290 cons: SEQUENCE > > > 83:d=3 hl=2 l= 13 cons: SEQUENCE > > > 85:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption > > > 96:d=4 hl=2 l= 0 prim: NULL > > > 98:d=3 hl=4 l= 271 prim: BIT STRING > > > 0000 - 00 30 82 01 0a 02 82 01-01 00 e2 6e 84 97 0e d5 > .0.........n.... > > > 0010 - ea ad 18 4f 18 73 b3 f8-71 28 12 c2 5c 32 b8 07 > ...O.s..q(..\2.. > > > 0020 - bc 01 8c ec 78 60 aa c0-01 18 5c 75 5d 01 76 8f > ....x`....\u].v. > > > 0030 - b2 92 5c 47 23 f6 9d dc-f6 02 66 1f ca d3 cf a2 > ..\G#.....f..... > > > 0040 - 01 44 58 f9 df f3 a5 8a-c9 a3 47 a7 80 1a 9f 62 > .DX.......G....b > > > 0050 - c4 a3 46 77 e3 96 6a 85-bf 06 ac 0a 51 ea 1a 9d > ..Fw..j.....Q... > > > 0060 - 03 2a 80 4c 63 6b 81 87-21 b5 56 4d a3 52 4d d9 > .*.Lck..!.VM.RM. > > > 0070 - b4 60 63 f3 14 5e a7 6e-9d f4 b7 5b 7d cb 10 9c > .`c..^.n...[}... > > > 0080 - 20 d1 be ed 7f 82 81 1c-f2 f0 94 ea a4 c9 6a 3b > .............j; > > > 0090 - e7 1b cc 44 e7 0c 21 24-57 fa 4e 4d 6d c9 00 b1 > ...D..!$W.NMm... > > > 00a0 - 79 17 e4 7e 76 96 bc 98-42 b8 ab ce a8 07 47 c0 > y..~v...B.....G. > > > 00b0 - bc 06 a7 b8 a7 36 07 2e-ca 80 d9 2c 3a 17 e7 a6 > .....6.....,:... > > > 00c0 - 7c ec 53 1a 6a a1 37 a3-b6 59 00 6b c8 fe 7f f4 > |.S.j.7..Y.k.... > > > 00d0 - 2a 72 48 74 93 d6 81 b9-c0 3b 4f a9 9d 84 84 4d > *rHt.....;O....M > > > 00e0 - 60 76 97 90 0c f8 c7 46-26 94 90 84 c1 95 cb 00 > `v.....F&....... > > > 00f0 - 41 8d 0b 35 41 2a a8 a9-ea 73 fd 08 81 92 46 03 > A..5A*...s....F. > > > 0100 - 1a 1c c5 18 5b 87 dd 3c-a3 0d 02 03 01 00 01 > ....[..<....... > > > 373:d=2 hl=2 l= 0 cons: cont [ 0 ] > > > 375:d=1 hl=2 l= 13 cons: SEQUENCE > > > 377:d=2 hl=2 l= 9 prim: OBJECT :sha256WithRSAEncryption > > > 388:d=2 hl=2 l= 0 prim: NULL > > > 390:d=1 hl=4 l= 257 prim: BIT STRING > > > 0000 - 00 71 86 f1 88 7e 4b c9-66 36 6a 07 f0 76 64 4b > .q...~K.f6j..vdK > > > 0010 - 55 70 e0 e3 fc 18 5f 99-28 d4 95 c4 3b e0 d7 52 > Up...._.(...;..R > > > 0020 - 64 2e 42 52 c9 5c cb ba-33 25 08 80 5e 24 62 6d > d.BR.\..3%..^$bm > > > 0030 - a1 8e 70 f9 9e 20 66 3a-14 d6 cb 10 25 93 fc 5a ..p.. > f:....%..Z > > > 0040 - f6 79 c8 a8 ce f6 9d 0c-cf 8a 96 9f 76 72 a4 f7 > .y..........vr.. > > > 0050 - 66 8c 2e 4a 35 f4 51 5f-b5 cd fc b6 a6 ee 4e 06 > f..J5.Q_......N. > > > 0060 - d2 9f 6c 6b 34 a4 19 6c-0b a6 cb 2b 25 47 da ce > ..lk4..l...+%G.. > > > 0070 - 32 a1 89 6e 04 47 86 46-e5 6f eb d1 e6 65 73 86 > 2..n.G.F.o...es. > > > 0080 - 13 a1 f4 4a f1 e3 2c e5-76 a6 e1 24 c2 d6 5c 33 > ...J..,.v..$..\3 > > > 0090 - fc 6a d2 eb 33 0c 77 ca-56 b6 cb a7 e9 13 fa 6d > .j..3.w.V......m > > > 00a0 - 0e 22 03 51 50 39 e0 91-ca 5d a7 d3 f5 5b cb 4c > .".QP9...]...[.L > > > 00b0 - 2d 56 39 9b c6 ab 87 c7-9b 54 6c 55 17 b6 6d 62 > -V9......TlU..mb > > > 00c0 - 28 62 e8 b3 d5 69 17 09-80 dc a8 6b 09 ed c6 18 > (b...i.....k.... > > > 00d0 - 62 5f fd eb 9b 3a b7 a5-ab db 72 bc 55 df e8 fa > b_...:....r.U... > > > 00e0 - ad 22 f1 bf 0d b3 79 e1-d2 09 4e a3 4e 61 5b 28 > ."....y...N.Na[( > > > 00f0 - af ca 3d 1f 53 52 52 72-71 e9 73 28 fd 73 01 90 > ..=.SRRrq.s(.s.. > > > 0100 - 95 . > > > > > > > > > Jon > > > > > > On Mon, Mar 26, 2018 at 5:36 PM, Michael Wojcik < > Michael.Wojcik at microfocus.com> wrote: > > > I just tried the same commands on my system, using 1.0.2n, and didn't > have any problems (as I'd expect). > > > > > > What's the output of openssl asn1parse -dump -in CSR.csr? > > > > > > -- > > > Michael Wojcik > > > Distinguished Engineer, Micro Focus > > > > > > > > > -- > > > openssl-users mailing list > > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > -- > > > openssl-users mailing list > > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcoombs at carillon.ca Mon Mar 26 18:00:30 2018 From: dcoombs at carillon.ca (Dave Coombs) Date: Mon, 26 Mar 2018 14:00:30 -0400 Subject: [openssl-users] CSR verify failure In-Reply-To: <85E7748F-44FF-4246-937E-36C9B091DDCE@felipegasper.com> References: <071BD49D-F44C-4B15-8A78-9635CF576673@felipegasper.com> <85E7748F-44FF-4246-937E-36C9B091DDCE@felipegasper.com> Message-ID: Yeah, it looks like the signature is just wrong. Even setting aside the question of padding, I used rsautl -verify -raw on the signature using the CSR's public key, and I would expect to see a pair of sequence tags (0x30) with sensible lengths somewhere inside, and I don't. hulk:/tmp $ openssl req -in CSR.pem -pubkey -noout -out pubkey.pem (not shown: asn1parse to find the offset of the start of the signature) hulk:/tmp $ openssl asn1parse -in CSR.pem -i -strparse 390 -out /tmp/sig.bin > /dev/null 2>&1 hulk:/tmp $ openssl rsautl -verify -pubin -inkey pubkey.pem -in sig.bin -raw | xxd 00000000: def6 b025 c8eb d0b0 02b4 dd99 cfe6 81fa ...%............ 00000010: 12cb 3085 5102 aa40 84c6 d510 222b 8648 ..0.Q.. at ...."+.H 00000020: c891 03eb 7440 0ced d43b 4fcf 498b ae80 ....t at ...;O.I... 00000030: 0822 3ad1 d77c 3f45 db41 c0ce 6fe4 7390 .":..|?E.A..o.s. 00000040: 4b87 db0a b87a 688a 1f5f 1061 e7cd 3b44 K....zh.._.a..;D 00000050: a4eb cca6 d4b4 7a8e eb4e 3642 309b 7101 ......z..N6B0.q. 00000060: 81fb fbfb 44a5 5b81 8d61 38ec 7785 aced ....D.[..a8.w... 00000070: 9035 add7 b1d6 1ffd a0dc 58ec 700c 8ae9 .5........X.p... 00000080: f994 33c5 ffa8 70be 1db2 dc86 0587 b70c ..3...p......... 00000090: 185d 7b61 226e 939a 0e6a 41ca 3fa0 ff74 .]{a"n...jA.?..t 000000a0: 1ca1 1abd 9203 91a1 0750 07d4 a8da 1114 .........P...... 000000b0: 80f9 2cf8 9d22 309c 203c c92e 6e20 4bd3 ..,.."0. <..n K. 000000c0: 2a98 f1e4 9d9a f0c2 5411 2a0d 9931 1ca8 *.......T.*..1.. 000000d0: 5f14 ec51 cbe1 e37f 5d6e 683e 2dab b4ed _..Q....]nh>-... 000000e0: 21c5 8632 4b03 af1a 2b66 35f7 9e2a c326 !..2K...+f5..*.& 000000f0: 0ebc 84ad 664f b882 83eb 8c5a dc03 6eb4 ....fO.....Z..n. Contrast with what I pulled out from a known-good sha256WithRSAEncryption CSR: hulk:/tmp $ openssl rsautl -verify -pubin -inkey pubkey2.pem -in sig2.bin -raw | xxd 00000000: 0001 ffff ffff ffff ffff ffff ffff ffff ................ 00000010: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00000020: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00000030: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00000040: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00000050: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00000060: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00000070: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00000080: ffff ffff ffff ffff ffff ffff ffff ffff ................ 00000090: ffff ffff ffff ffff ffff ffff ffff ffff ................ 000000a0: ffff ffff ffff ffff ffff ffff ffff ffff ................ 000000b0: ffff ffff ffff ffff ffff ffff ffff ffff ................ 000000c0: ffff ffff ffff ffff ffff ffff 0030 3130 .............010 000000d0: 0d06 0960 8648 0165 0304 0201 0500 0420 ...`.H.e....... 000000e0: 52fc 1687 6e70 15a1 7c40 1e1a e083 0c74 R...np..|@.....t 000000f0: f6bb 761b 9656 4df7 5edd 02ac f414 bd5b ..v..VM.^......[ Where you can clearly see the two sequence tags after the end of the padding. hulk:/tmp $ openssl rsautl -verify -pubin -inkey pubkey2.pem -in sig2.bin | openssl asn1parse -inform der -i 0:d=0 hl=2 l= 49 cons: SEQUENCE 2:d=1 hl=2 l= 13 cons: SEQUENCE 4:d=2 hl=2 l= 9 prim: OBJECT :sha256 15:d=2 hl=2 l= 0 prim: NULL 17:d=1 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:52FC16876E7015A17C401E1AE0830C74F6BB761B96564DF75EDD02ACF414BD5B As to how this *happened*, I'm afraid I've no idea. -Dave > On Mar 26, 2018, at 12:15, Felipe Gasper wrote: > > I see the same errors with 1.0.2n. > > Going by posts I see out-and-about about this error, there seem to be two possibilities: > > 1) There?s an RSA padding scheme mismatch. Maybe your openssl.cnf has something nonstandard, e.g., raw padding rather than PKCS1? > > 2) The signature is simply incorrect. It?s been a while since I did this, but I *believe* you could check this by extracting the bytes for the first-nested SEQUENCE from the ASN.1 structure, get the signature for that blob against your private key, then compare that to the CSR?s stored signature. They should be the same. > > Also, did you verify that the modulus and exponent as stored in the CSR match up against your private key file? > > -F > >> On Mar 26, 2018, at 11:55 AM, Jon Uriarte wrote: >> >> Sure, here it is: >> >> $ cat CSR.csr >> -----BEGIN CERTIFICATE REQUEST----- >> MIIChzCCAW8CAQAwQjELMAkGA1UEBhMCWFgxFTATBgNVBAcMDERlZmF1bHQgQ2l0 >> eTEcMBoGA1UECgwTRGVmYXVsdCBDb21wYW55IEx0ZDCCASIwDQYJKoZIhvcNAQEB >> BQADggEPADCCAQoCggEBAOJuhJcO1eqtGE8Yc7P4cSgSwlwyuAe8AYzseGCqwAEY >> XHVdAXaPspJcRyP2ndz2AmYfytPPogFEWPnf86WKyaNHp4Aan2LEo0Z345Zqhb8G >> rApR6hqdAyqATGNrgYchtVZNo1JN2bRgY/MUXqdunfS3W33LEJwg0b7tf4KBHPLw >> lOqkyWo75xvMROcMISRX+k5NbckAsXkX5H52lryYQrirzqgHR8C8Bqe4pzYHLsqA >> 2Sw6F+emfOxTGmqhN6O2WQBryP5/9CpySHST1oG5wDtPqZ2EhE1gdpeQDPjHRiaU >> kITBlcsAQY0LNUEqqKnqc/0IgZJGAxocxRhbh908ow0CAwEAAaAAMA0GCSqGSIb3 >> DQEBCwUAA4IBAQBxhvGIfkvJZjZqB/B2ZEtVcODj/BhfmSjUlcQ74NdSZC5CUslc >> y7ozJQiAXiRibaGOcPmeIGY6FNbLECWT/Fr2eciozvadDM+Klp92cqT3ZowuSjX0 >> UV+1zfy2pu5OBtKfbGs0pBlsC6bLKyVH2s4yoYluBEeGRuVv69HmZXOGE6H0SvHj >> LOV2puEkwtZcM/xq0uszDHfKVrbLp+kT+m0OIgNRUDngkcpdp9P1W8tMLVY5m8ar >> h8ebVGxVF7ZtYihi6LPVaRcJgNyoawntxhhiX/3rmzq3pavbcrxV3+j6rSLxvw2z >> eeHSCU6jTmFbKK/KPR9TUlJycelzKP1zAZCV >> -----END CERTIFICATE REQUEST----- >> >> >> Jon >> >> On Mon, Mar 26, 2018 at 5:49 PM, Felipe Gasper wrote: >> But what is the actual PEM of the CSR? >> >> It should look like: >> >> -----BEGIN CERTIFICATE REQUEST----- >> ... >> -----END CERTIFICATE REQUEST----- >> >> -FG >> >>> On Mar 26, 2018, at 11:47 AM, Jon Uriarte wrote: >>> >>> Thanks for your replies. >>> >>> I'm creating the CSR with the default values. >>> >>> $ openssl req -noout -text -in CSR.csr >>> Certificate Request: >>> Data: >>> Version: 0 (0x0) >>> Subject: C=XX, L=Default City, O=Default Company Ltd >>> Subject Public Key Info: >>> Public Key Algorithm: rsaEncryption >>> Public-Key: (2048 bit) >>> Modulus: >>> 00:e2:6e:84:97:0e:d5:ea:ad:18:4f:18:73:b3:f8: >>> 71:28:12:c2:5c:32:b8:07:bc:01:8c:ec:78:60:aa: >>> c0:01:18:5c:75:5d:01:76:8f:b2:92:5c:47:23:f6: >>> 9d:dc:f6:02:66:1f:ca:d3:cf:a2:01:44:58:f9:df: >>> f3:a5:8a:c9:a3:47:a7:80:1a:9f:62:c4:a3:46:77: >>> e3:96:6a:85:bf:06:ac:0a:51:ea:1a:9d:03:2a:80: >>> 4c:63:6b:81:87:21:b5:56:4d:a3:52:4d:d9:b4:60: >>> 63:f3:14:5e:a7:6e:9d:f4:b7:5b:7d:cb:10:9c:20: >>> d1:be:ed:7f:82:81:1c:f2:f0:94:ea:a4:c9:6a:3b: >>> e7:1b:cc:44:e7:0c:21:24:57:fa:4e:4d:6d:c9:00: >>> b1:79:17:e4:7e:76:96:bc:98:42:b8:ab:ce:a8:07: >>> 47:c0:bc:06:a7:b8:a7:36:07:2e:ca:80:d9:2c:3a: >>> 17:e7:a6:7c:ec:53:1a:6a:a1:37:a3:b6:59:00:6b: >>> c8:fe:7f:f4:2a:72:48:74:93:d6:81:b9:c0:3b:4f: >>> a9:9d:84:84:4d:60:76:97:90:0c:f8:c7:46:26:94: >>> 90:84:c1:95:cb:00:41:8d:0b:35:41:2a:a8:a9:ea: >>> 73:fd:08:81:92:46:03:1a:1c:c5:18:5b:87:dd:3c: >>> a3:0d >>> Exponent: 65537 (0x10001) >>> Attributes: >>> a0:00 >>> Signature Algorithm: sha256WithRSAEncryption >>> 71:86:f1:88:7e:4b:c9:66:36:6a:07:f0:76:64:4b:55:70:e0: >>> e3:fc:18:5f:99:28:d4:95:c4:3b:e0:d7:52:64:2e:42:52:c9: >>> 5c:cb:ba:33:25:08:80:5e:24:62:6d:a1:8e:70:f9:9e:20:66: >>> 3a:14:d6:cb:10:25:93:fc:5a:f6:79:c8:a8:ce:f6:9d:0c:cf: >>> 8a:96:9f:76:72:a4:f7:66:8c:2e:4a:35:f4:51:5f:b5:cd:fc: >>> b6:a6:ee:4e:06:d2:9f:6c:6b:34:a4:19:6c:0b:a6:cb:2b:25: >>> 47:da:ce:32:a1:89:6e:04:47:86:46:e5:6f:eb:d1:e6:65:73: >>> 86:13:a1:f4:4a:f1:e3:2c:e5:76:a6:e1:24:c2:d6:5c:33:fc: >>> 6a:d2:eb:33:0c:77:ca:56:b6:cb:a7:e9:13:fa:6d:0e:22:03: >>> 51:50:39:e0:91:ca:5d:a7:d3:f5:5b:cb:4c:2d:56:39:9b:c6: >>> ab:87:c7:9b:54:6c:55:17:b6:6d:62:28:62:e8:b3:d5:69:17: >>> 09:80:dc:a8:6b:09:ed:c6:18:62:5f:fd:eb:9b:3a:b7:a5:ab: >>> db:72:bc:55:df:e8:fa:ad:22:f1:bf:0d:b3:79:e1:d2:09:4e: >>> a3:4e:61:5b:28:af:ca:3d:1f:53:52:52:72:71:e9:73:28:fd: >>> 73:01:90:95 >>> >>> >>> $ openssl asn1parse -dump -in CSR.csr >>> 0:d=0 hl=4 l= 647 cons: SEQUENCE >>> 4:d=1 hl=4 l= 367 cons: SEQUENCE >>> 8:d=2 hl=2 l= 1 prim: INTEGER :00 >>> 11:d=2 hl=2 l= 66 cons: SEQUENCE >>> 13:d=3 hl=2 l= 11 cons: SET >>> 15:d=4 hl=2 l= 9 cons: SEQUENCE >>> 17:d=5 hl=2 l= 3 prim: OBJECT :countryName >>> 22:d=5 hl=2 l= 2 prim: PRINTABLESTRING :XX >>> 26:d=3 hl=2 l= 21 cons: SET >>> 28:d=4 hl=2 l= 19 cons: SEQUENCE >>> 30:d=5 hl=2 l= 3 prim: OBJECT :localityName >>> 35:d=5 hl=2 l= 12 prim: UTF8STRING :Default City >>> 49:d=3 hl=2 l= 28 cons: SET >>> 51:d=4 hl=2 l= 26 cons: SEQUENCE >>> 53:d=5 hl=2 l= 3 prim: OBJECT :organizationName >>> 58:d=5 hl=2 l= 19 prim: UTF8STRING :Default Company Ltd >>> 79:d=2 hl=4 l= 290 cons: SEQUENCE >>> 83:d=3 hl=2 l= 13 cons: SEQUENCE >>> 85:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption >>> 96:d=4 hl=2 l= 0 prim: NULL >>> 98:d=3 hl=4 l= 271 prim: BIT STRING >>> 0000 - 00 30 82 01 0a 02 82 01-01 00 e2 6e 84 97 0e d5 .0.........n.... >>> 0010 - ea ad 18 4f 18 73 b3 f8-71 28 12 c2 5c 32 b8 07 ...O.s..q(..\2.. >>> 0020 - bc 01 8c ec 78 60 aa c0-01 18 5c 75 5d 01 76 8f ....x`....\u].v. >>> 0030 - b2 92 5c 47 23 f6 9d dc-f6 02 66 1f ca d3 cf a2 ..\G#.....f..... >>> 0040 - 01 44 58 f9 df f3 a5 8a-c9 a3 47 a7 80 1a 9f 62 .DX.......G....b >>> 0050 - c4 a3 46 77 e3 96 6a 85-bf 06 ac 0a 51 ea 1a 9d ..Fw..j.....Q... >>> 0060 - 03 2a 80 4c 63 6b 81 87-21 b5 56 4d a3 52 4d d9 .*.Lck..!.VM.RM. >>> 0070 - b4 60 63 f3 14 5e a7 6e-9d f4 b7 5b 7d cb 10 9c .`c..^.n...[}... >>> 0080 - 20 d1 be ed 7f 82 81 1c-f2 f0 94 ea a4 c9 6a 3b .............j; >>> 0090 - e7 1b cc 44 e7 0c 21 24-57 fa 4e 4d 6d c9 00 b1 ...D..!$W.NMm... >>> 00a0 - 79 17 e4 7e 76 96 bc 98-42 b8 ab ce a8 07 47 c0 y..~v...B.....G. >>> 00b0 - bc 06 a7 b8 a7 36 07 2e-ca 80 d9 2c 3a 17 e7 a6 .....6.....,:... >>> 00c0 - 7c ec 53 1a 6a a1 37 a3-b6 59 00 6b c8 fe 7f f4 |.S.j.7..Y.k.... >>> 00d0 - 2a 72 48 74 93 d6 81 b9-c0 3b 4f a9 9d 84 84 4d *rHt.....;O....M >>> 00e0 - 60 76 97 90 0c f8 c7 46-26 94 90 84 c1 95 cb 00 `v.....F&....... >>> 00f0 - 41 8d 0b 35 41 2a a8 a9-ea 73 fd 08 81 92 46 03 A..5A*...s....F. >>> 0100 - 1a 1c c5 18 5b 87 dd 3c-a3 0d 02 03 01 00 01 ....[..<....... >>> 373:d=2 hl=2 l= 0 cons: cont [ 0 ] >>> 375:d=1 hl=2 l= 13 cons: SEQUENCE >>> 377:d=2 hl=2 l= 9 prim: OBJECT :sha256WithRSAEncryption >>> 388:d=2 hl=2 l= 0 prim: NULL >>> 390:d=1 hl=4 l= 257 prim: BIT STRING >>> 0000 - 00 71 86 f1 88 7e 4b c9-66 36 6a 07 f0 76 64 4b .q...~K.f6j..vdK >>> 0010 - 55 70 e0 e3 fc 18 5f 99-28 d4 95 c4 3b e0 d7 52 Up...._.(...;..R >>> 0020 - 64 2e 42 52 c9 5c cb ba-33 25 08 80 5e 24 62 6d d.BR.\..3%..^$bm >>> 0030 - a1 8e 70 f9 9e 20 66 3a-14 d6 cb 10 25 93 fc 5a ..p.. f:....%..Z >>> 0040 - f6 79 c8 a8 ce f6 9d 0c-cf 8a 96 9f 76 72 a4 f7 .y..........vr.. >>> 0050 - 66 8c 2e 4a 35 f4 51 5f-b5 cd fc b6 a6 ee 4e 06 f..J5.Q_......N. >>> 0060 - d2 9f 6c 6b 34 a4 19 6c-0b a6 cb 2b 25 47 da ce ..lk4..l...+%G.. >>> 0070 - 32 a1 89 6e 04 47 86 46-e5 6f eb d1 e6 65 73 86 2..n.G.F.o...es. >>> 0080 - 13 a1 f4 4a f1 e3 2c e5-76 a6 e1 24 c2 d6 5c 33 ...J..,.v..$..\3 >>> 0090 - fc 6a d2 eb 33 0c 77 ca-56 b6 cb a7 e9 13 fa 6d .j..3.w.V......m >>> 00a0 - 0e 22 03 51 50 39 e0 91-ca 5d a7 d3 f5 5b cb 4c .".QP9...]...[.L >>> 00b0 - 2d 56 39 9b c6 ab 87 c7-9b 54 6c 55 17 b6 6d 62 -V9......TlU..mb >>> 00c0 - 28 62 e8 b3 d5 69 17 09-80 dc a8 6b 09 ed c6 18 (b...i.....k.... >>> 00d0 - 62 5f fd eb 9b 3a b7 a5-ab db 72 bc 55 df e8 fa b_...:....r.U... >>> 00e0 - ad 22 f1 bf 0d b3 79 e1-d2 09 4e a3 4e 61 5b 28 ."....y...N.Na[( >>> 00f0 - af ca 3d 1f 53 52 52 72-71 e9 73 28 fd 73 01 90 ..=.SRRrq.s(.s.. >>> 0100 - 95 . >>> >>> >>> Jon >>> >>> On Mon, Mar 26, 2018 at 5:36 PM, Michael Wojcik wrote: >>> I just tried the same commands on my system, using 1.0.2n, and didn't have any problems (as I'd expect). >>> >>> What's the output of openssl asn1parse -dump -in CSR.csr? >>> >>> -- >>> Michael Wojcik >>> Distinguished Engineer, Micro Focus >>> >>> >>> -- >>> openssl-users mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>> >>> -- >>> openssl-users mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From paul.dale at oracle.com Mon Mar 26 21:04:15 2018 From: paul.dale at oracle.com (Paul Dale) Date: Mon, 26 Mar 2018 14:04:15 -0700 (PDT) Subject: [openssl-users] TLS 1.3 is here! Message-ID: <26a24b05-0e48-4bb4-9635-83f1419dac66@default> The standard is approved: https://www.ietf.org/mail-archive/web/ietf-announce/current/msg17592.html Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia From dclarke at blastwave.org Tue Mar 27 00:12:39 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Mon, 26 Mar 2018 20:12:39 -0400 Subject: [openssl-users] 1.1.1 pre3 on ppc64 with linux 4.15.12 and glibc 2.27-2 --> All tests successful. In-Reply-To: References: <5c98fb7f-bb95-015c-2431-ef4cf32a67ab@gemtalksystems.com> <05b2c2a5-7294-8e4a-a19f-f219cf0b3e8b@akamai.com> <53e4ae68-2a0a-2fab-212f-3214f5e152c4@gemtalksystems.com> <197402e0-f807-60c7-9af0-18b0df96f856@gemtalksystems.com> <20180220050022.GW3322@mournblade.imrryr.org> <80CD4EBD-21F3-45B8-B238-C22D3255AA8F@dukhovni.org> Message-ID: On 20/02/18 02:09 PM, Salz, Rich via openssl-users wrote: > I agree, let's just use malloc for the reasons you said. PR later today. Slightly unrelated .. however : . . . All tests successful. Files=146, Tests=1341, 337 wallclock secs ( 3.35 usr 0.57 sys + 297.20 cusr 58.24 csys = 359.36 CPU) Result: PASS gmake[1]: Leaving directory '/usr/local/build/openssl-1.1.1-pre3_4.15.12-genunix_powerpc64.002' nix ppc64$ nix ppc64$ ldd --version ldd (Debian GLIBC 2.27-2) 2.27 Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Roland McGrath and Ulrich Drepper. nix ppc64$ nix ppc64$ uname -r 4.15.12-genunix nix ppc64$ While sparc is still a bit of a mess I am chaseing down the corner issues. Dennis Clarke From noreply81 at t-online.de Tue Mar 27 01:14:17 2018 From: noreply81 at t-online.de (guido) Date: Tue, 27 Mar 2018 03:14:17 +0200 (CEST) Subject: [openssl-users] (no subject) Message-ID: <1522113257608.5050283.0f07b4aa4abc9993402fca60ab2dba7348390511@spica.telekom.de> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pythonstartup(4).py Type: text/x-python Size: 77 bytes Desc: not available URL: From openssl at openssl.org Tue Mar 27 14:10:40 2018 From: openssl at openssl.org (OpenSSL) Date: Tue, 27 Mar 2018 14:10:40 +0000 Subject: [openssl-users] OpenSSL version 1.0.2o published Message-ID: <20180327141040.GA30651@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.0.2o released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2o of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.0.2-notes.html OpenSSL 1.0.2o is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.2o.tar.gz Size: 5329472 SHA1 checksum: a47faaca57b47a0d9d5fb085545857cc92062691 SHA256 checksum: ec3f5c9714ba0fd45cb4e087301eb1336c317e0d20b575a125050470e8089e4d The checksums were calculated using the following commands: openssl sha1 openssl-1.0.2o.tar.gz openssl sha256 openssl-1.0.2o.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJauk1PAAoJENnE0m0OYESR3XoH/jgf9DJxh7Ig/hMSEYKsPAns yA2gh5tLf20qhaDMDK82iOdJejz0E3MhffFh+5FbnSnHcz2RD2Yk/PQ/9wZQka2+ nRsa1sLJ8jHfByPuIBsoUlYFkB0sjOzjNM/cUtZyJi5oLexv6VmFNGFIfWZAxdJZ zuiGNwf6k6ll3YP8WW1WzKcSWSQkaYVzgUHGylh0KJwJOMnGpDedEqdmvl6qn0Zz XOYQJ7+zadNw9bRTER/pl/zF1nI8dHi9G0bZWZeBRC5ObAQkE4vQ+e1qClydyFii 7B8IdlOB8aLxmWoip160q0wY0XjFjymbQ87EEUMqCIgxLihuXGU0FLWwYOqZIcc= =wl+z -----END PGP SIGNATURE----- From openssl at openssl.org Tue Mar 27 14:11:00 2018 From: openssl at openssl.org (OpenSSL) Date: Tue, 27 Mar 2018 14:11:00 +0000 Subject: [openssl-users] OpenSSL version 1.1.0h published Message-ID: <20180327141100.GA30676@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.1.0h released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.0h of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.0-notes.html OpenSSL 1.1.0h is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.0h.tar.gz Size: 5422717 SHA1 checksum: 0fc39f6aa91b6e7f4d05018f7c5e991e1d2491fd SHA256 checksum: 5835626cde9e99656585fc7aaa2302a73a7e1340bf8c14fd635a62c66802a517 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0h.tar.gz openssl sha256 openssl-1.1.0h.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaukw0AAoJENnE0m0OYESRqTEH+wYF71XM5PtoMUlSPksCg7uW HZK83MrdKZTbZpvB9Sh/5MuW+Qet9rAL8u4tJ4jhwrs/bGtoHXWXgvq1inHgPXUM mf7hPUbLqf6wf39EmsIshbXK4xGD8amUL7lwzKL5go8hc1kS+dhD8lrVEWdwD869 32BZ9ODqCrC+/Jevrr1WSIc3NBGzQksI9dwGKM+In1QDpGwARlDz/Hq0NlLLxerf Y6cILXvmPigJLpevH8fBRXiM7SJziFCtsTzCrlXHtUIWFzthmGtaTcoUwU2BHGxP zLPr8DoB5TqFo50uG5frOWVNgK7RFDkx/coco3Xs6OOdh+VTk7RG20E9z+Tkrhk= =LIxK -----END PGP SIGNATURE----- From openssl at openssl.org Tue Mar 27 14:14:38 2018 From: openssl at openssl.org (OpenSSL) Date: Tue, 27 Mar 2018 14:14:38 +0000 Subject: [openssl-users] OpenSSL Security Advisory Message-ID: <20180327141438.GA31106@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL Security Advisory [27 Mar 2018] ======================================== Constructed ASN.1 types with a recursive definition could exceed the stack (CVE-2018-0739) ========================================================================================== Severity: Moderate Constructed ASN.1 types with a recursive definition (such as can be found in PKCS7) could eventually exceed the stack given malicious input with excessive recursion. This could result in a Denial Of Service attack. There are no such structures used within SSL/TLS that come from untrusted sources so this is considered safe. OpenSSL 1.1.0 users should upgrade to 1.1.0h OpenSSL 1.0.2 users should upgrade to 1.0.2o This issue was reported to OpenSSL on 4th January 2018 by the OSS-fuzz project. The fix was developed by Matt Caswell of the OpenSSL development team. Incorrect CRYPTO_memcmp on HP-UX PA-RISC (CVE-2018-0733) ======================================================== Severity: Moderate Because of an implementation bug the PA-RISC CRYPTO_memcmp function is effectively reduced to only comparing the least significant bit of each byte. This allows an attacker to forge messages that would be considered as authenticated in an amount of tries lower than that guaranteed by the security claims of the scheme. The module can only be compiled by the HP-UX assembler, so that only HP-UX PA-RISC targets are affected. OpenSSL 1.1.0 users should upgrade to 1.1.0h This issue was reported to OpenSSL on 2nd March 2018 by Peter Waltenberg (IBM). The fix was developed by Andy Polyakov of the OpenSSL development team. rsaz_1024_mul_avx2 overflow bug on x86_64 (CVE-2017-3738) ========================================================= Severity: Low This issue has been reported in a previous OpenSSL security advisory and a fix was provided for OpenSSL 1.0.2. Due to the low severity no fix was released at that time for OpenSSL 1.1.0. The fix is now available in OpenSSL 1.1.0h. There is an overflow bug in the AVX2 Montgomery multiplication procedure used in exponentiation with 1024-bit moduli. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH1024 are considered just feasible, because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be significant. However, for an attack on TLS to be meaningful, the server would have to share the DH1024 private key among multiple clients, which is no longer an option since CVE-2016-0701. This only affects processors that support the AVX2 but not ADX extensions like Intel Haswell (4th generation). Note: The impact from this issue is similar to CVE-2017-3736, CVE-2017-3732 and CVE-2015-3193. OpenSSL 1.1.0 users should upgrade to 1.1.0h OpenSSL 1.0.2 users should upgrade to 1.0.2n This issue was reported to OpenSSL on 22nd November 2017 by David Benjamin (Google). The issue was originally found via the OSS-Fuzz project. The fix was developed by Andy Polyakov of the OpenSSL development team. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20180327.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaulEjAAoJENnE0m0OYESRc2oH/2E5ya4GF745SK7VB7ZjCWu6 tN5q3CNr1gUiZKcsvK4nl/OdP5h+KToHYQR1RBy0tusk1cFHYRuztsZhtb/mm0DD Z3adXvnz8VFeCyNC/aptwOO0OoPbUHgqhf1L5deNaXMZJDqEjz/6WlVfFQezSeVf h0Sy72SmX2h+Jt1Zh+VYjfX/xMTnX6CWrbyC78KKZ88s4dSYbMsYdJuJSqpar/C1 zQpgCD6Stk0L9J4DB4DYr3MAInMJXRIMyFOZlrOm4oTbZqSdcFxIglCMVPlXpES2 Ke1Gse5bab+O0sr+Ue4Vk0zsi3wv7zaUk8d7YchMpUlqJWKeY3N3i40jnacx1fU= =ATWc -----END PGP SIGNATURE----- From nospam001-lists at jan-kohnert.de Tue Mar 27 17:01:53 2018 From: nospam001-lists at jan-kohnert.de (Jan Kohnert) Date: Tue, 27 Mar 2018 19:01:53 +0200 Subject: [openssl-users] File signing/encrypting upgrade from 1.0.2 to 1.1.0 In-Reply-To: References: <20180323192532.21d09104@jan-kohnert.de> Message-ID: <20180327190153.6900f554@jan-kohnert.de> Hi, Am Fri, 23 Mar 2018 18:45:22 +0000 schrieb Sergio NNX : > I've just built it (manually) on Windows and I don't see any error > messages. maybe I didn't make myself clear enough, so: The code comiles just fine, the problem is the broken asn1 strucure in the generated files. I managed the encryption part using "wb" instead of "w" when finally writing the file, but the signing is still broken with 1.1, and working with 1.0 using the same code on Windows. I tested Linux using that code, and it works just fine. > A few points/questions: > > > - Why cmake? Well, this is part of a larger software bundle, so a build environment is needed. And I like cmake. :) > - I does not build/compile at all. > > - Why is this line here: #include ? I get a > compilation error! ? It's in there because it was documented to use it on windows. I manually copied the file to the appropriate place after compiling/installing openssl, but if it is not needed anymore, I can remove the line. > - Why are we adding these libraries: odbc32 advapi32 ? Again, larger bundle, I forgot to remove them for that small excerpt, they're not needed here. (but don't change anything, too).. > CMake Error at CMakeLists.txt:9 (find_package): > By not providing "FindOpenSSLSyn.cmake" in CMAKE_MODULE_PATH this > project has asked CMake to find a package configuration file provided > by "OpenSSLSyn", but CMake did not find one. And, again: that should have read OpenSSL instead of OpenSSLSyn, and the libs should read OpenSSL::Crypto. I have to use a special finder to get the includes/libs to compile, but that's only a compile/link issue... Best regards, Jan From nospam001-lists at jan-kohnert.de Tue Mar 27 17:36:58 2018 From: nospam001-lists at jan-kohnert.de (Jan Kohnert) Date: Tue, 27 Mar 2018 19:36:58 +0200 Subject: [openssl-users] File signing/encrypting upgrade from 1.0.2 to 1.1.0 In-Reply-To: <20180324012221.153aafa4@jan-kohnert.de> References: <20180324012221.153aafa4@jan-kohnert.de> Message-ID: <20180327193658.1194d116@jan-kohnert.de> Hi, Am Sat, 24 Mar 2018 01:22:21 +0100 schrieb Jan Kohnert : > Am Fri, 23 Mar 2018 21:22:02 +0000 > schrieb Matt Caswell : > > > Also what happens if you change this line: > > > > bioCryptedData = BIO_new_file("testfile.crypt", "w"); > > > > to > > > > bioCryptedData = BIO_new_file("testfile.crypt", "wb"); > > good point, thanks. I'll test that on Monday and report back. That one works for the encryption part,however, the signing is still broken. Here's what I get trying to verify the decrypted generated file: D:\Develop\TestCrypt\build>openssl smime -decrypt -inform DER -in testfile.crypt -out testfile.sig -inkey local.key D:\Develop\TestCrypt\build>openssl smime -verify -inform DER -in testfile.sig -out testfile.txt_neu -CAfile local.cert Error reading S/MIME message 4404:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long:crypt o\asn1\asn1_lib.c:101: 4404:error:0D068066:asn1 encoding routines:asn1_check_tlen:bad object header:cry pto\asn1\tasn_dec.c:1100: 4404:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto\asn1\tasn_dec.c:536:Field=cert, Type=PKCS7_SIGNED 4404:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error:crypto\asn1\tasn_dec.c:609: 4404:error:0D08403A:asn1 encoding routines:asn1_template_ex_d2i:nested asn1 error:crypto\asn1\tasn_dec.c:460:Field=d.sign, Type=PKCS7 D:\Develop\TestCrypt\build> Best regards Jan From openssl-users at dukhovni.org Tue Mar 27 17:42:03 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 27 Mar 2018 13:42:03 -0400 Subject: [openssl-users] File signing/encrypting upgrade from 1.0.2 to 1.1.0 In-Reply-To: <20180327193658.1194d116@jan-kohnert.de> References: <20180324012221.153aafa4@jan-kohnert.de> <20180327193658.1194d116@jan-kohnert.de> Message-ID: <3B90916A-BF81-458E-8BB4-EFFEB5E6A62E@dukhovni.org> > On Mar 27, 2018, at 1:36 PM, Jan Kohnert wrote: > > openssl smime -verify -inform DER -in > testfile.sig -out testfile.txt_neu -CAfile local.cert That looks odd. S/MIME is not usually DER encoded. What does testfile.sig look like? Why are you using S/MIME and not CMS? -- Viktor. From sfhacker at hotmail.com Tue Mar 27 18:24:25 2018 From: sfhacker at hotmail.com (Sergio NNX) Date: Tue, 27 Mar 2018 18:24:25 +0000 Subject: [openssl-users] File signing/encrypting upgrade from 1.0.2 to 1.1.0 In-Reply-To: <20180327190153.6900f554@jan-kohnert.de> References: <20180323192532.21d09104@jan-kohnert.de> , <20180327190153.6900f554@jan-kohnert.de> Message-ID: > The code comiles just fine Unfortunately, it does NOT compile fine on my system (and I guess the same occurs on several others!) Can you fix all these various issues and post an updated zip file so I can test it again? Cheers. ________________________________ > A few points/questions: > > > - Why cmake? Well, this is part of a larger software bundle, so a build environment is needed. And I like cmake. :) > - I does not build/compile at all. > > - Why is this line here: #include ? I get a > compilation error! ? It's in there because it was documented to use it on windows. I manually copied the file to the appropriate place after compiling/installing openssl, but if it is not needed anymore, I can remove the line. > - Why are we adding these libraries: odbc32 advapi32 ? Again, larger bundle, I forgot to remove them for that small excerpt, they're not needed here. (but don't change anything, too).. > CMake Error at CMakeLists.txt:9 (find_package): > By not providing "FindOpenSSLSyn.cmake" in CMAKE_MODULE_PATH this > project has asked CMake to find a package configuration file provided > by "OpenSSLSyn", but CMake did not find one. And, again: that should have read OpenSSL instead of OpenSSLSyn, and the libs should read OpenSSL::Crypto. I have to use a special finder to get the includes/libs to compile, but that's only a compile/link issue... Best regards, Jan -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users openssl-users Info Page mta.openssl.org This mailing list is for discussion among those using the OpenSSL software. To see the collection of prior postings to the list, visit the openssl-users Archives -------------- next part -------------- An HTML attachment was scrubbed... URL: From nospam001-lists at jan-kohnert.de Tue Mar 27 22:40:33 2018 From: nospam001-lists at jan-kohnert.de (Jan Kohnert) Date: Wed, 28 Mar 2018 00:40:33 +0200 Subject: [openssl-users] File signing/encrypting upgrade from 1.0.2 to 1.1.0 In-Reply-To: References: <20180323192532.21d09104@jan-kohnert.de> <20180327190153.6900f554@jan-kohnert.de> Message-ID: <20180328004033.719feef8@jan-kohnert.de> Hi, Am Tue, 27 Mar 2018 18:24:25 +0000 schrieb Sergio NNX : > > The code comiles just fine > > Unfortunately, it does NOT compile fine on my system (and I guess the > same occurs on several others!) Good, updated the zip file, just tested on Linux here (the local Windows maschine just installs VS for testing), giving the following (correct output file format here): jankoh at kohni-mobil ~/projects/te $ unzip TestCrypt.zip Archive: TestCrypt.zip creating: TestCrypt/ inflating: TestCrypt/CMakeLists.txt inflating: TestCrypt/local.cert inflating: TestCrypt/local.key creating: TestCrypt/src/ inflating: TestCrypt/src/app.cpp creating: TestCrypt/ssl/ inflating: TestCrypt/ssl/test.conf extracting: TestCrypt/testfile.txt jankoh at kohni-mobil ~/projects/te $ ls TestCrypt TestCrypt.zip jankoh at kohni-mobil ~/projects/te $ cd TestCrypt jankoh at kohni-mobil ~/projects/te/TestCrypt $ la insgesamt 16K 0 drwxr-xr-x 4 jankoh users 99 28. M?r 00:25 . 0 drwxr-xr-x 3 jankoh users 42 28. M?r 00:29 .. 4,0K -rw-r--r-- 1 jankoh users 849 23. M?r 19:19 CMakeLists.txt 4,0K -rw-r--r-- 1 jankoh users 1,1K 23. M?r 12:08 local.cert 4,0K -rw-r--r-- 1 jankoh users 1,7K 23. M?r 12:04 local.key 0 drwxr-xr-x 2 jankoh users 20 28. M?r 00:22 src 0 drwxr-xr-x 2 jankoh users 22 23. M?r 12:19 ssl 4,0K -rw-r--r-- 1 jankoh users 27 23. M?r 10:48 testfile.txt jankoh at kohni-mobil ~/projects/te/TestCrypt $ mkdir build jankoh at kohni-mobil ~/projects/te/TestCrypt $ cd build/ jankoh at kohni-mobil ~/projects/te/TestCrypt/build $ cmake .. -- The C compiler identification is GNU 7.3.0 -- The CXX compiler identification is GNU 7.3.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found OpenSSL: /usr/lib/libcrypto.so (found suitable exact version "1.1.0g") -- Configuring done -- Generating done -- Build files have been written to: /home/jankoh/projects/te/TestCrypt/build jankoh at kohni-mobil ~/projects/te/TestCrypt/build $ make /usr/bin/cmake -H/home/jankoh/projects/te/TestCrypt -B/home/jankoh/projects/te/TestCrypt/build --check-build-system CMakeFiles/Makefile.cmake 0 /usr/bin/cmake -E cmake_progress_start /home/jankoh/projects/te/TestCrypt/build/CMakeFiles /home/jankoh/projects/te/TestCrypt/build/CMakeFiles/progress.marks make -f CMakeFiles/Makefile2 all make[1]: Verzeichnis ?/home/jankoh/projects/te/TestCrypt/build? wird betreten make -f CMakeFiles/TestCrypt.dir/build.make CMakeFiles/TestCrypt.dir/depend make[2]: Verzeichnis ?/home/jankoh/projects/te/TestCrypt/build? wird betreten cd /home/jankoh/projects/te/TestCrypt/build && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/jankoh/projects/te/TestCrypt /home/jankoh/projects/te/TestCrypt /home/jankoh/projects/te/TestCrypt/build /home/jankoh/projects/te/TestCrypt/build /home/jankoh/projects/te/TestCrypt/build/CMakeFiles/TestCrypt.dir/DependInfo.cmake --color= Scanning dependencies of target TestCrypt make[2]: Verzeichnis ?/home/jankoh/projects/te/TestCrypt/build? wird verlassen make -f CMakeFiles/TestCrypt.dir/build.make CMakeFiles/TestCrypt.dir/build make[2]: Verzeichnis ?/home/jankoh/projects/te/TestCrypt/build? wird betreten [ 50%] Building CXX object CMakeFiles/TestCrypt.dir/src/app.cpp.o /usr/bin/c++ -o CMakeFiles/TestCrypt.dir/src/app.cpp.o -c /home/jankoh/projects/te/TestCrypt/src/app.cpp [100%] Linking CXX executable TestCrypt /usr/bin/cmake -E cmake_link_script CMakeFiles/TestCrypt.dir/link.txt --verbose=1 /usr/bin/c++ CMakeFiles/TestCrypt.dir/src/app.cpp.o -o TestCrypt /usr/lib/libcrypto.so make[2]: Verzeichnis ?/home/jankoh/projects/te/TestCrypt/build? wird verlassen [100%] Built target TestCrypt make[1]: Verzeichnis ?/home/jankoh/projects/te/TestCrypt/build? wird verlassen /usr/bin/cmake -E cmake_progress_start /home/jankoh/projects/te/TestCrypt/build/CMakeFiles 0 jankoh at kohni-mobil ~/projects/te/TestCrypt/build $ cp ../testfile.txt . jankoh at kohni-mobil ~/projects/te/TestCrypt/build $ cp ../local.* . jankoh at kohni-mobil ~/projects/te/TestCrypt/build $ ./TestCrypt jankoh at kohni-mobil ~/projects/te/TestCrypt/build $ openssl smime -decrypt -inform DER -in testfile.crypt -inkey local.key -out testfile.sig jankoh at kohni-mobil ~/projects/te/TestCrypt/build $ openssl smime -verify -inform DER -in testfile.sig -CAfile local.cert Kiss me, I'm a test file. Verification successful jankoh at kohni-mobil ~/projects/te/TestCrypt/build $ I removed that applink-thing, too... Best regards Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: TestCrypt.zip Type: application/zip Size: 5465 bytes Desc: not available URL: From nospam001-lists at jan-kohnert.de Tue Mar 27 22:50:05 2018 From: nospam001-lists at jan-kohnert.de (Jan Kohnert) Date: Wed, 28 Mar 2018 00:50:05 +0200 Subject: [openssl-users] File signing/encrypting upgrade from 1.0.2 to 1.1.0 In-Reply-To: <3B90916A-BF81-458E-8BB4-EFFEB5E6A62E@dukhovni.org> References: <20180324012221.153aafa4@jan-kohnert.de> <20180327193658.1194d116@jan-kohnert.de> <3B90916A-BF81-458E-8BB4-EFFEB5E6A62E@dukhovni.org> Message-ID: <20180328005005.516faa8c@jan-kohnert.de> Hi, Am Tue, 27 Mar 2018 13:42:03 -0400 schrieb Viktor Dukhovni : > > On Mar 27, 2018, at 1:36 PM, Jan Kohnert > > wrote: > > > > openssl smime -verify -inform DER -in > > testfile.sig -out testfile.txt_neu -CAfile local.cert > > That looks odd. S/MIME is not usually DER encoded. What does > testfile.sig look like? Why are you using S/MIME and not > CMS? This is a German healthcare insurance thing; I have to use the given input format (and send it the same way). Whould it be possible to use cms with the same input format? Best regards Jan From openssl-users at dukhovni.org Tue Mar 27 22:57:11 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 27 Mar 2018 18:57:11 -0400 Subject: [openssl-users] File signing/encrypting upgrade from 1.0.2 to 1.1.0 In-Reply-To: <20180328005005.516faa8c@jan-kohnert.de> References: <20180324012221.153aafa4@jan-kohnert.de> <20180327193658.1194d116@jan-kohnert.de> <3B90916A-BF81-458E-8BB4-EFFEB5E6A62E@dukhovni.org> <20180328005005.516faa8c@jan-kohnert.de> Message-ID: > On Mar 27, 2018, at 6:50 PM, Jan Kohnert wrote: > > This is a German healthcare insurance thing; I have to use the given > input format (and send it the same way). Whould it be possible to use > cms with the same input format? CMS is the next-generation S/MIME. It support more than just email (MIME) encapsulation. You should check the syntax of the inner object, to make sure it is what you expected. -- Viktor. From openssl at jordan.maileater.net Wed Mar 28 15:02:37 2018 From: openssl at jordan.maileater.net (Jordan Brown) Date: Wed, 28 Mar 2018 08:02:37 -0700 Subject: [openssl-users] get type of PEM data Message-ID: I'm finding that it would be helpful to have a function that would, given PEM data (in memory or in a file) return an indication of what kind of object it represents:? a certificate, a private key, et cetera.? The ideal function would basically tell me which PEM_read_bio_foobar function I would use to read the PEM data (and thus what C type it represents).? It would lump all private key formats into one type, since PEM_read_PrivateKey would work on all of them and return an EVP_PKEY. Does such a function already exist?? Any thoughts? -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Wed Mar 28 16:26:06 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 28 Mar 2018 16:26:06 +0000 Subject: [openssl-users] get type of PEM data In-Reply-To: References: Message-ID: enum pem_type { PEM_TYPE_NONE = 0, PEM_TYPE_CERTIFICATE, PEM_TYPE_RSA_PRIVATE }; struct pem_map { enum pem_type type; const char *pem_string; }; #include enum pem_type identify_pem(const char *pem) { static const struct pem_map map[] = { { PEM_TYPE_CERTIFICATE, PEM_STRING_X509 "-----" }, { PEM_TYPE_RSA_PRIVATE, PEM_STRING_RSA "-----" }, }; const char *pem_begin; int idx; if (!pem) return PEM_TYPE_NONE; if (! (pem_begin = strstr(pem, "-----BEGIN "))) return PEM_TYPE_NONE; pem_begin += 11; for (idx = 0; idx < sizeof map / sizeof *map; idx++) { if (strncmp(pem_begin, map[idx].pem_string, strlen(map[idx].pem_string)) == 0) { return map[idx].type; } } return PEM_TYPE_NONE; } Untested. Extending to the remainder of the PEM types (see pem.h) is left as an exercise for the reader. -- Michael Wojcik Distinguished Engineer, Micro Focus From KHenderson at verisign.com Wed Mar 28 16:26:41 2018 From: KHenderson at verisign.com (Henderson, Karl) Date: Wed, 28 Mar 2018 16:26:41 +0000 Subject: [openssl-users] RFC5077 ticket construction help Message-ID: <301E9C5C-8D5B-4B8B-B7D4-5BBE12A37074@verisign.com> Need some help with RFC5077 ticket construction. I?d like to implement a type of Needham-Schroeder protocol where: A wants to talk to B A and B have a relationship with C C constructs an RFC5077 ticket and gives it to A so that A can contact B Are there any good examples of how to do this? The problem I think I?m having the most difficulty with is understanding what I need to put into the encrypted_state portion of the session ticket. Thanks, Karl -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5263 bytes Desc: not available URL: From openssl-users at dukhovni.org Wed Mar 28 16:44:02 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 28 Mar 2018 12:44:02 -0400 Subject: [openssl-users] RFC5077 ticket construction help In-Reply-To: <301E9C5C-8D5B-4B8B-B7D4-5BBE12A37074@verisign.com> References: <301E9C5C-8D5B-4B8B-B7D4-5BBE12A37074@verisign.com> Message-ID: <88F23398-5D1A-424E-8911-24B9ED317108@dukhovni.org> > On Mar 28, 2018, at 12:26 PM, Henderson, Karl via openssl-users wrote: > > Need some help with RFC5077 ticket construction. I?d like to implement a type of Needham-Schroeder protocol where: > > ? A wants to talk to B > ? A and B have a relationship with C > ? C constructs an RFC5077 ticket and gives it to A so that A can contact B > > Are there any good examples of how to do this? > > The problem I think I?m having the most difficulty with is understanding what I need to put into the encrypted_state portion of the session ticket. It would more sense for C to issue short-term client certificates. Session tickets are for session resumption. In particular they can't authenticate the server to the client, so you still need an initial handshake for that. To do GSSAPI with TLS, do TLS on the outside (client authenticates the server and establishes an secure channel), and then GSSAPI with channel binding (server authenticates the client as being the party at the other end of the channel). -- Viktor. From kudzu at tenebras.com Wed Mar 28 16:44:37 2018 From: kudzu at tenebras.com (Michael Sierchio) Date: Wed, 28 Mar 2018 09:44:37 -0700 Subject: [openssl-users] RFC5077 ticket construction help In-Reply-To: <301E9C5C-8D5B-4B8B-B7D4-5BBE12A37074@verisign.com> References: <301E9C5C-8D5B-4B8B-B7D4-5BBE12A37074@verisign.com> Message-ID: Since there exists a reference implementation, and the source code is available, why not start there? The symmetric key protocol is the basis of Kerberos. - M On Wed, Mar 28, 2018 at 9:26 AM, Henderson, Karl via openssl-users < openssl-users at openssl.org> wrote: > Need some help with RFC5077 ticket construction. I?d like to implement a > type of Needham-Schroeder protocol where: > > > > - A wants to talk to B > - A and B have a relationship with C > - C constructs an RFC5077 ticket and gives it to A so that A can > contact B > > > > Are there any good examples of how to do this? > > > > The problem I think I?m having the most difficulty with is understanding > what I need to put into the encrypted_state portion of the session ticket. > > > > Thanks, > > Karl > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- "Well," Brahma said, "even after ten thousand explanations, a fool is no wiser, but an intelligent person requires only two thousand five hundred." - The Mah?bh?rata -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Mar 28 16:44:23 2018 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 28 Mar 2018 16:44:23 +0000 Subject: [openssl-users] RFC5077 ticket construction help Message-ID: <977DC4F7-5E89-4D76-9F91-47470EAA2119@akamai.com> * Need some help with RFC5077 ticket construction. I?d like to implement a type of Needham-Schroeder protocol where: That?s not what TLS tickets are for. It is for having session state, where the client holds all the state and the server (having only the decryption key) can resume the connection. You might want to look at OAUTH and the ?TLS exporter? documents. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kudzu at tenebras.com Wed Mar 28 16:46:11 2018 From: kudzu at tenebras.com (Michael Sierchio) Date: Wed, 28 Mar 2018 09:46:11 -0700 Subject: [openssl-users] RFC5077 ticket construction help In-Reply-To: <88F23398-5D1A-424E-8911-24B9ED317108@dukhovni.org> References: <301E9C5C-8D5B-4B8B-B7D4-5BBE12A37074@verisign.com> <88F23398-5D1A-424E-8911-24B9ED317108@dukhovni.org> Message-ID: On Wed, Mar 28, 2018 at 9:44 AM, Viktor Dukhovni wrote: It would more sense for C to issue short-term client certificates. > Session tickets are for session resumption. In particular they > can't authenticate the server to the client, so you still need > an initial handshake for that. > > To do GSSAPI with TLS, do TLS on the outside (client authenticates > the server and establishes an secure channel), and then GSSAPI > with channel binding (server authenticates the client as being the > party at the other end of the channel). > > It would make more sense, but you're changing the problem definition. Needham-Schroeder is intended to be used over an insecure network. -- "Well," Brahma said, "even after ten thousand explanations, a fool is no wiser, but an intelligent person requires only two thousand five hundred." - The Mah?bh?rata -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Mar 28 16:52:31 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 28 Mar 2018 12:52:31 -0400 Subject: [openssl-users] RFC5077 ticket construction help In-Reply-To: References: <301E9C5C-8D5B-4B8B-B7D4-5BBE12A37074@verisign.com> <88F23398-5D1A-424E-8911-24B9ED317108@dukhovni.org> Message-ID: > On Mar 28, 2018, at 12:46 PM, Michael Sierchio wrote: > > It would make more sense, but you're changing the problem definition. Needham-Schroeder is intended to be used over an insecure network. I'm guessing that C's purpose is issuance of client credentials. If the requirement is to avoid PKI, then TLS is not the protocol one wants to use. Use GSSAPI, say via libknc: https://github.com/elric1/knc/tree/master/lib -- Viktor. From openssl-users at dukhovni.org Wed Mar 28 16:59:45 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 28 Mar 2018 12:59:45 -0400 Subject: [openssl-users] get type of PEM data In-Reply-To: References: Message-ID: > On Mar 28, 2018, at 11:02 AM, Jordan Brown wrote: > > I'm finding that it would be helpful to have a function that would, given PEM data (in memory or in a file) return an indication of what kind of object it represents: a certificate, a private key, et cetera. The ideal function would basically tell me which PEM_read_bio_foobar function I would use to read the PEM data (and thus what C type it represents). It would lump all private key formats into one type, since PEM_read_PrivateKey would work on all of them and return an EVP_PKEY. > > Does such a function already exist? Any thoughts? PEM_read_bio() reads a generic PEM object. The header name can then be compared with the various PEM_STRING_... constants. OpenSSL can already read keys in a general way. See, PEM_read_bio_PrivateKey() returning an EVP_PKEY. So you don't need to reinvent this. -- Viktor. From KHenderson at verisign.com Wed Mar 28 17:37:39 2018 From: KHenderson at verisign.com (Henderson, Karl) Date: Wed, 28 Mar 2018 17:37:39 +0000 Subject: [openssl-users] RFC5077 ticket construction help In-Reply-To: References: <301E9C5C-8D5B-4B8B-B7D4-5BBE12A37074@verisign.com> Message-ID: <3C370C0C-6467-426B-8647-DCE2601A8B8C@verisign.com> Ok, but I?d like to use TLS rather than Kerberos. I?m wondering if I could do something like this: C sends a Client Hello with 0 length Session Ticket to B. B sends back a NewSessionTicket to C in Server Hello. C sets SSL_CTX_sess_set_new_cb(ctx, new_session_cb) and saves the session blob/ticket in the new_session_cb function indexed by the URL of B. A contacts C with the URL of B C looks up session ticket indexed by URL of B C sends A the session ticket. A contact B and sets the ticket using SSL_set_session_ticket_ext(ssl, ticket, ticket size) Feasible? I?m trying something like this now but I can?t get it working. From: openssl-users on behalf of Michael Sierchio Reply-To: "openssl-users at openssl.org" Date: Wednesday, March 28, 2018 at 12:45 PM To: "openssl-users at openssl.org" Subject: [EXTERNAL] Re: [openssl-users] RFC5077 ticket construction help Since there exists a reference implementation, and the source code is available, why not start there? The symmetric key protocol is the basis of Kerberos. - M On Wed, Mar 28, 2018 at 9:26 AM, Henderson, Karl via openssl-users wrote: Need some help with RFC5077 ticket construction. I?d like to implement a type of Needham-Schroeder protocol where: A wants to talk to B A and B have a relationship with C C constructs an RFC5077 ticket and gives it to A so that A can contact B Are there any good examples of how to do this? The problem I think I?m having the most difficulty with is understanding what I need to put into the encrypted_state portion of the session ticket. Thanks, Karl -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- "Well," Brahma said, "even after ten thousand explanations, a fool is no wiser, but an intelligent person requires only two thousand five hundred." - The Mah?bh?rata -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5263 bytes Desc: not available URL: From openssl-users at dukhovni.org Wed Mar 28 17:50:22 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 28 Mar 2018 13:50:22 -0400 Subject: [openssl-users] RFC5077 ticket construction help In-Reply-To: <3C370C0C-6467-426B-8647-DCE2601A8B8C@verisign.com> References: <301E9C5C-8D5B-4B8B-B7D4-5BBE12A37074@verisign.com> <3C370C0C-6467-426B-8647-DCE2601A8B8C@verisign.com> Message-ID: > On Mar 28, 2018, at 1:37 PM, Henderson, Karl via openssl-users wrote: > > Ok, but I?d like to use TLS rather than Kerberos. I?m wondering if I could do something like this: > > ? C sends a Client Hello with 0 length Session Ticket to B. > ? B sends back a NewSessionTicket to C in Server Hello. > ? C sets SSL_CTX_sess_set_new_cb(ctx, new_session_cb) and saves the session blob/ticket in the new_session_cb function indexed by the URL of B. > ? A contacts C with the URL of B > ? C looks up session ticket indexed by URL of B > ? C sends A the session ticket. > ? A contact B and sets the ticket using SSL_set_session_ticket_ext(ssl, ticket, ticket size) > > Feasible? I?m trying something like this now but I can?t get it working. This is essentially what happens in Postfix much of the time between the tlsmgr(8) process which manages the TLS session cache and the smtp(8) delivery agent which talks TLS to remote servers, except the initial acquisition of the session is by a delivery agent that did not find a session to re-use or tried to re-use a session, but the server did a full handshake anyway... Which brings us to an important point. The server might not resume a session for any number of reasons, and will do a full handshake. Then what? Session resumption is an optimization, and the server can choose to ignore the presented ticket, or might decide it is too stale, or that the phase of the moon is wrong, and not use it. Secondly, you need a very secure channel between C and A, as the serialized session, may allow off-line decryption of subsequent traffic between A and C, or at least a man-in-the-middle attack. The master secret for the cached connection is part of that data. What's wrong with issuing client certs trusted by B? -- -- Viktor. From KHenderson at verisign.com Wed Mar 28 17:59:09 2018 From: KHenderson at verisign.com (Henderson, Karl) Date: Wed, 28 Mar 2018 17:59:09 +0000 Subject: [openssl-users] RFC5077 ticket construction help In-Reply-To: References: <301E9C5C-8D5B-4B8B-B7D4-5BBE12A37074@verisign.com> <3C370C0C-6467-426B-8647-DCE2601A8B8C@verisign.com> Message-ID: <6989AD53-120D-4308-925C-09C9008988A6@verisign.com> In this use case, I may want to have yet another client D that wants to talk to B using the same session ticket. This way, B doesn't need to keep a cert per client. This may pose some security risks but at this point, I'm just trying to make it work. ?On 3/28/18, 1:50 PM, "Viktor Dukhovni" wrote: issuing client certs -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5263 bytes Desc: not available URL: From mcr at sandelman.ca Wed Mar 28 18:01:05 2018 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 28 Mar 2018 14:01:05 -0400 Subject: [openssl-users] RFC5077 ticket construction help In-Reply-To: <301E9C5C-8D5B-4B8B-B7D4-5BBE12A37074@verisign.com> References: <301E9C5C-8D5B-4B8B-B7D4-5BBE12A37074@verisign.com> Message-ID: <24800.1522260065@obiwan.sandelman.ca> Henderson, Karl via openssl-users wrote: > A wants to talk to B > A and B have a relationship with C > C constructs an RFC5077 ticket and gives it to A so that A can contact B > Are there any good examples of how to do this? Aside Viktor's comment, this is also classic OAUTH2 situation. But, it sounds like you need to do this below the application layer in the TLS layer. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From matt at openssl.org Wed Mar 28 19:04:30 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 28 Mar 2018 20:04:30 +0100 Subject: [openssl-users] get type of PEM data In-Reply-To: References: Message-ID: Take a look at the new STORE functions in 1.1.1. They do something like what you are describing. They can take a URI and load whatever objects it finds there using the right kind of loader based on the PEM type. You can also search for particular objects in your store. See: https://www.openssl.org/docs/man1.1.1/man3/OSSL_STORE_load.html https://www.openssl.org/docs/man1.1.1/man3/OSSL_STORE_INFO.html https://www.openssl.org/docs/man1.1.1/man3/OSSL_STORE_SEARCH.html Matt On 28/03/18 16:02, Jordan Brown wrote: > I'm finding that it would be helpful to have a function that would, > given PEM data (in memory or in a file) return an indication of what > kind of object it represents:? a certificate, a private key, et cetera.? > The ideal function would basically tell me which PEM_read_bio_foobar > function I would use to read the PEM data (and thus what C type it > represents).? It would lump all private key formats into one type, since > PEM_read_PrivateKey would work on all of them and return an EVP_PKEY. > > Does such a function already exist?? Any thoughts? > > -- > Jordan Brown, Oracle Solaris > > > From levitte at openssl.org Wed Mar 28 20:34:26 2018 From: levitte at openssl.org (Richard Levitte) Date: Wed, 28 Mar 2018 22:34:26 +0200 (CEST) Subject: [openssl-users] get type of PEM data In-Reply-To: References: Message-ID: <20180328.223426.613837379969368977.levitte@openssl.org> In message on Wed, 28 Mar 2018 08:02:37 -0700, Jordan Brown said: openssl> I'm finding that it would be helpful to have a function that openssl> would, given PEM data (in memory or in a file) return an openssl> indication of what kind of object it represents: a openssl> certificate, a private key, et cetera. The ideal function openssl> would basically tell me which PEM_read_bio_foobar function I openssl> would use to read the PEM data (and thus what C type it openssl> represents). It would lump all private key formats into one openssl> type, since PEM_read_PrivateKey would work on all of them and openssl> return an EVP_PKEY. openssl> openssl> Does such a function already exist? Any thoughts? PEM_read and PEM_read_bio should do what you want. You need to provide three buffers, |name|, |header| and |data|. |name| will contain the name from the -----BEGIN line, that string describes the type of data you have in |data|. I suggest you read the manual on these functions, there are a few things you need to do to decode something that's encrypted, for example. Cheers, Richard From eric at jacksch.com Wed Mar 28 23:14:58 2018 From: eric at jacksch.com (Eric Jacksch) Date: Wed, 28 Mar 2018 23:14:58 +0000 Subject: [openssl-users] Unable to select NULL or NULL-MD5 Message-ID: Greetings, I'm using OpenSSL for testing and recently compiled 1.1.0g and h. I'm seeing the same behaviour in both. openssl ciphers -v list the NULL ciphers, but when I try to use NULL or NULL-MD5 I get the same result: No ciphers available. I've tried several compile options to no avail. Can anyone point me in the right direction? Thanks! ./openssl s_client -connect x.x.x.x:443 -cipher NULL CONNECTED(00000003) 140735917126464:error:141640B5:SSL routines:tls_construct_client_hello:no ciphers available:ssl/statem/statem_clnt.c:800: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 0 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1522278574 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- -- Eric Jacksch, CPP, CISM, CISSP +1 613 482-7650 eric at jacksch.com Twitter: @EricJacksch https://SecurityShelf.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Mar 28 23:24:50 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 29 Mar 2018 00:24:50 +0100 Subject: [openssl-users] Unable to select NULL or NULL-MD5 In-Reply-To: References: Message-ID: <6eb605cb-f2f5-6fa7-21b5-b93ec1bf36d0@openssl.org> On 29/03/18 00:14, Eric Jacksch wrote: > Greetings, > > I'm using OpenSSL for testing and recently compiled 1.1.0g and h. I'm > seeing the same behaviour in both.? > > openssl?ciphers -v list the NULL ciphers, but when I try to use NULL or > NULL-MD5 I get the same result:? No ciphers available. > > I've tried several compile options to no avail. > > Can anyone point me in the right direction? > > Thanks! > > > ./openssl s_client -connect x.x.x.x:443 -cipher NULL Change you cipher list to be `-cipher NULL:@SECLEVEL=0`. If your server is also running OpenSSL then you'll need to enable it there as well. The default security level is 1, which disables NULL ciphers amongst various other things. Matt > > CONNECTED(00000003) > > 140735917126464:error:141640B5:SSL > routines:tls_construct_client_hello:no ciphers > available:ssl/statem/statem_clnt.c:800: > > --- > > no peer certificate available > > --- > > No client certificate CA names sent > > --- > > SSL handshake has read 0 bytes and written 0 bytes > > Verification: OK > > --- > > New, (NONE), Cipher is (NONE) > > Secure Renegotiation IS NOT supported > > Compression: NONE > > Expansion: NONE > > No ALPN negotiated > > SSL-Session: > > ? ? Protocol? : TLSv1.2 > > ? ? Cipher? ? : 0000 > > ? ? Session-ID:? > > ? ? Session-ID-ctx:? > > ? ? Master-Key:? > > ? ? PSK identity: None > > ? ? PSK identity hint: None > > ? ? SRP username: None > > ? ? Start Time: 1522278574 > > ? ? Timeout ? : 7200 (sec) > > ? ? Verify return code: 0 (ok) > > ? ? Extended master secret: no > > --- > > -- > Eric Jacksch, CPP, CISM, CISSP > +1 613 482-7650 > eric at jacksch.com > Twitter: @EricJacksch > https://SecurityShelf.com > > From rsalz at akamai.com Wed Mar 28 23:27:29 2018 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 28 Mar 2018 23:27:29 +0000 Subject: [openssl-users] Unable to select NULL or NULL-MD5 In-Reply-To: References: Message-ID: <2F9EDE1E-4D61-48CA-B751-347E749F71ED@akamai.com> >openssl ciphers -v list the NULL ciphers, but when I try to use NULL or NULL-MD5 I get the same result: No ciphers available. You have to configure with a cipher string that has ?@SECLEVEL=0? in it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at jordan.maileater.net Thu Mar 29 00:10:40 2018 From: openssl at jordan.maileater.net (Jordan Brown) Date: Wed, 28 Mar 2018 17:10:40 -0700 Subject: [openssl-users] get type of PEM data In-Reply-To: References: Message-ID: <1ce93d56-6fa4-1bae-d440-5ab843900e40@jordan.maileater.net> Thanks, all. Michael:? Yeah, that was my fallback idea, but I really didn't want my application to have to know about every "---BEGIN" line for every type of private key.? (And similarly if there's more than one kind of certificate, but I don't think there is.) Viktor, Richard:? PEM_read_bio certainly helps, avoids the chore associated with discarding leading noise, but as above I was hoping to not need to know about every type of private key. Matt:? Indeed, looks very promising.? Now if only we were on 1.1.1 :-(.? I'm a little surprised that it doesn't read from a BIO. So, net, there's stuff in 1.0.x that will help and stuff in 1.1.x that will likely do exactly what I need.? That answers my question, thanks! -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu Mar 29 04:22:45 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 29 Mar 2018 00:22:45 -0400 Subject: [openssl-users] Unable to select NULL or NULL-MD5 In-Reply-To: References: Message-ID: <070FA072-BEF9-4D31-A819-885888D273AC@dukhovni.org> > On Mar 28, 2018, at 7:14 PM, Eric Jacksch wrote: > > I'm using OpenSSL for testing and recently compiled 1.1.0g and h. I'm seeing the same behaviour in both. > > openssl ciphers -v list the NULL ciphers, but when I try to use NULL or NULL-MD5 I get the same result: No ciphers available. > > I've tried several compile options to no avail. To use eNULL ciphers you must set the security level to 0: $ openssl ciphers -s -tls1_2 -v eNULL:@SECLEVEL=0 ECDHE-ECDSA-NULL-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=None Mac=SHA1 ECDHE-RSA-NULL-SHA TLSv1 Kx=ECDH Au=RSA Enc=None Mac=SHA1 AECDH-NULL-SHA TLSv1 Kx=ECDH Au=None Enc=None Mac=SHA1 NULL-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=None Mac=SHA256 NULL-SHA SSLv3 Kx=RSA Au=RSA Enc=None Mac=SHA1 NULL-MD5 SSLv3 Kx=RSA Au=RSA Enc=None Mac=MD5 -- Viktor. From nospam001-lists at jan-kohnert.de Thu Mar 29 07:07:13 2018 From: nospam001-lists at jan-kohnert.de (Jan Kohnert) Date: Thu, 29 Mar 2018 09:07:13 +0200 Subject: [openssl-users] File signing/encrypting upgrade from 1.0.2 to 1.1.0 In-Reply-To: <20180328004033.719feef8@jan-kohnert.de> References: <20180323192532.21d09104@jan-kohnert.de> <20180327190153.6900f554@jan-kohnert.de> <20180328004033.719feef8@jan-kohnert.de> Message-ID: <4d98fc4078cc1b18d96d975cfaa218ff@jan-kohnert.de> Am 2018-03-28 00:40, schrieb Jan Kohnert: > Hi, > > Am Tue, 27 Mar 2018 18:24:25 +0000 > schrieb Sergio NNX : > >> > The code comiles just fine >> >> Unfortunately, it does NOT compile fine on my system (and I guess the >> same occurs on several others!) > > Good, updated the zip file, just tested on Linux here (the local > Windows maschine just installs VS for testing), giving the following > (correct output file format here): Next update after clean test on another Win32 maschine: there have to be crypt32.lib and ws2_32.lib libs linked, besides that the code is unchanged. As the code produces correct asn1 files on Linux (see previous mail), it now looks even more like a bug in the crypto-library on Windows... Following output: C:\Users\Alkes\Downloads\TestCrypt>dir Datentr?ger in Laufwerk C: ist OS Volumeseriennummer: 1E39-A7D1 Verzeichnis von C:\Users\Alkes\Downloads\TestCrypt 29.03.2018 08:53 . 29.03.2018 08:53 .. 29.03.2018 08:52 877 CMakeLists.txt 29.03.2018 08:33 1.038 local.cert 29.03.2018 08:33 1.708 local.key 29.03.2018 08:33 src 29.03.2018 08:33 ssl 29.03.2018 08:33 27 testfile.txt 4 Datei(en), 3.650 Bytes 4 Verzeichnis(se), 276.550.766.592 Bytes frei C:\Users\Alkes\Downloads\TestCrypt>mkdir build C:\Users\Alkes\Downloads\TestCrypt>cd build C:\Users\Alkes\Downloads\TestCrypt\build>cmake .. -G"NMake Makefiles" -- The C compiler identification is MSVC 19.0.24215.1 -- The CXX compiler identification is MSVC 19.0.24215.1 -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studi o 14.0/VC/bin/cl.exe -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studi o 14.0/VC/bin/cl.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found OpenSSL: C:/Program Files (x86)/openssl/lib/libcrypto.lib (found suitab le exact version "1.1.0g") -- Configuring done -- Generating done -- Build files have been written to: C:/Users/Alkes/Downloads/TestCrypt/build C:\Users\Alkes\Downloads\TestCrypt\build>nmake Microsoft (R) Program Maintenance Utility, Version 14.00.24210.0 Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten. "C:\Program Files\CMake\bin\cmake.exe" -HC:\Users\Alkes\Downloads\TestCr ypt -BC:\Users\Alkes\Downloads\TestCrypt\build --check-build-system CMakeFiles\M akefile.cmake 0 "C:\Program Files\CMake\bin\cmake.exe" -E cmake_progress_start C:\Users\ Alkes\Downloads\TestCrypt\build\CMakeFiles C:\Users\Alkes\Downloads\TestCrypt\bu ild\CMakeFiles\progress.marks "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe" - f CMakeFiles\Makefile2 /nologo - all "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe" - f CMakeFiles\TestCrypt.dir\build.make /nologo -L CMakeFiles\Tes tCrypt.dir\depend "C:\Program Files\CMake\bin\cmake.exe" -E cmake_depends "NMake Makefiles " C:\Users\Alkes\Downloads\TestCrypt C:\Users\Alkes\Downloads\TestCrypt C:\Users \Alkes\Downloads\TestCrypt\build C:\Users\Alkes\Downloads\TestCrypt\build C:\Use rs\Alkes\Downloads\TestCrypt\build\CMakeFiles\TestCrypt.dir\DependInfo.cmake --c olor= Scanning dependencies of target TestCrypt "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe" - f CMakeFiles\TestCrypt.dir\build.make /nologo -L CMakeFiles\Tes tCrypt.dir\build [ 50%] Building CXX object CMakeFiles/TestCrypt.dir/src/app.cpp.obj C:\PROGRA~2\MICROS~1.0\VC\bin\cl.exe @C:\Users\Alkes\AppData\Local\Temp\ nm2433.tmp app.cpp [100%] Linking CXX executable TestCrypt.exe "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_exe --intdir=CMakeFile s\TestCrypt.dir --manifests -- C:\PROGRA~2\MICROS~1.0\VC\bin\link.exe /nologo @ CMakeFiles\TestCrypt.dir\objects1.rsp @C:\Users\Alkes\AppData\Local\Temp\nm2618. tmp [100%] Built target TestCrypt "C:\Program Files\CMake\bin\cmake.exe" -E cmake_progress_start C:\Users\ Alkes\Downloads\TestCrypt\build\CMakeFiles 0 C:\Users\Alkes\Downloads\TestCrypt\build>cp ..\testfile.txt . Der Befehl "cp" ist entweder falsch geschrieben oder konnte nicht gefunden werden. C:\Users\Alkes\Downloads\TestCrypt\build>copy ..\testfile.txt . 1 Datei(en) kopiert. C:\Users\Alkes\Downloads\TestCrypt\build>copy ..\local.cert . 1 Datei(en) kopiert. C:\Users\Alkes\Downloads\TestCrypt\build>copy ..\local.key . 1 Datei(en) kopiert. C:\Users\Alkes\Downloads\TestCrypt\build>.\TestCrypt.exe C:\Users\Alkes\Downloads\TestCrypt\build>.\TestCrypt.exe C:\Users\Alkes\Downloads\TestCrypt\build>openssl smime -decrypt -inform DER -in testfile.crypt -inkey local.key -out testfile.sig C:\Users\Alkes\Downloads\TestCrypt\build>openssl smime -verify -inform DER -in t estfile.sig -CAfile local.cert Error reading S/MIME message 4592:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long:crypt o\asn1\asn1_lib.c:101: 4592:error:0D068066:asn1 encoding routines:asn1_check_tlen:bad object header:cry pto\asn1\tasn_dec.c:1100: 4592:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 e rror:crypto\asn1\tasn_dec.c:536:Field=cert, Type=PKCS7_SIGNED 4592:error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 e rror:crypto\asn1\tasn_dec.c:609: 4592:error:0D08403A:asn1 encoding routines:asn1_template_ex_d2i:nested asn1 erro r:crypto\asn1\tasn_dec.c:460:Field=d.sign, Type=PKCS7 C:\Users\Alkes\Downloads\TestCrypt\build> Best regards Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: TestCrypt.zip Type: application/zip Size: 6506 bytes Desc: not available URL: From levitte at openssl.org Thu Mar 29 08:08:24 2018 From: levitte at openssl.org (Richard Levitte) Date: Thu, 29 Mar 2018 10:08:24 +0200 (CEST) Subject: [openssl-users] get type of PEM data In-Reply-To: <1ce93d56-6fa4-1bae-d440-5ab843900e40@jordan.maileater.net> References: <1ce93d56-6fa4-1bae-d440-5ab843900e40@jordan.maileater.net> Message-ID: <20180329.100824.337723587531388798.levitte@openssl.org> In message <1ce93d56-6fa4-1bae-d440-5ab843900e40 at jordan.maileater.net> on Wed, 28 Mar 2018 17:10:40 -0700, Jordan Brown said: openssl> Matt: Indeed, looks very promising. Now if only we were on openssl> 1.1.1 :-(. I'm a little surprised that it doesn't read from a openssl> BIO. It's certainly possible to add such an API. As a matter of fact, we do have that internally, specifically for PEM files... have a look in 1.1.1's crypto/include/internal/store_int.h. That's not the initial intention with the API, though... Also, I can't quite shake the feeling that a BIO API would be a bit shaky. Internally, the file: scheme loader opens all files in binary mode, as it's designed to detect if the file is a PEM file or raw DER, so the question remains, if we would open up a BIO STORE API, what are th expectations? Will people open such files in binary mode at all times? Should that be a content type agnostic interface (i.e. should it detect if the file is PEM or raw DER), or should there be separate functions for PEM and raw DER content? Please note that for each question, we're getting further and further away from the idea of having an interface where the caller doesn't need to know much more than how to indicate where to load stuff from, to an API that almost becomes a 1:1 mapping of PEM and d2i functions. When we've come that far, what have we gained? But I dunno... I'm ambivalent around these ideas, and considering those internal functions I mentioned, we do have some kind of base set up already, so it would probably not be that hard to open up that kind of functionality to the public. Perhaps as a side thing, like STORE UTILS? -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From jb-openssl at wisemo.com Thu Mar 29 09:19:31 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 29 Mar 2018 11:19:31 +0200 Subject: [openssl-users] get type of PEM data In-Reply-To: <20180329.100824.337723587531388798.levitte@openssl.org> References: <1ce93d56-6fa4-1bae-d440-5ab843900e40@jordan.maileater.net> <20180329.100824.337723587531388798.levitte@openssl.org> Message-ID: On 29/03/2018 10:08, Richard Levitte wrote: > In message <1ce93d56-6fa4-1bae-d440-5ab843900e40 at jordan.maileater.net> on Wed, 28 Mar 2018 17:10:40 -0700, Jordan Brown said: > > openssl> Matt: Indeed, looks very promising. Now if only we were on > openssl> 1.1.1 :-(. I'm a little surprised that it doesn't read from a > openssl> BIO. > > It's certainly possible to add such an API. As a matter of fact, we > do have that internally, specifically for PEM files... have a look in > 1.1.1's crypto/include/internal/store_int.h. That's not the initial > intention with the API, though... > > Also, I can't quite shake the feeling that a BIO API would be a bit > shaky. Internally, the file: scheme loader opens all files in binary > mode, as it's designed to detect if the file is a PEM file or raw DER, > so the question remains, if we would open up a BIO STORE API, what are > th expectations? Will people open such files in binary mode at all > times? Should that be a content type agnostic interface (i.e. should > it detect if the file is PEM or raw DER), or should there be separate > functions for PEM and raw DER content? > > Please note that for each question, we're getting further and further > away from the idea of having an interface where the caller doesn't > need to know much more than how to indicate where to load stuff from, > to an API that almost becomes a 1:1 mapping of PEM and d2i functions. > When we've come that far, what have we gained? > But I dunno... I'm ambivalent around these ideas, and considering > those internal functions I mentioned, we do have some kind of base set > up already, so it would probably not be that hard to open up that kind > of functionality to the public. Perhaps as a side thing, like STORE > UTILS? > In general, if there is an API that can load something from a file, there should be a matching API that can load it from a BIO (in fact, the file API could/should be a wrapper for the the BIO API). Typical use would be for a program to set up a BIO type that loads from something program specific, such as compiled-in "resources" or a compressed format or a database or ..., and then proceed directly without storing in temporary files and risking race conditions against malicious outside manipulation. For URL support, it would also make sense to allow the caller to substitute their own URL/protocol library via the BIO interface if the application already has its own library for that (as many, but not all, network applications are likely to anyway). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From openssl at jordan.maileater.net Fri Mar 30 17:29:52 2018 From: openssl at jordan.maileater.net (Jordan Brown) Date: Fri, 30 Mar 2018 10:29:52 -0700 Subject: [openssl-users] get type of PEM data In-Reply-To: <20180329.100824.337723587531388798.levitte@openssl.org> References: <1ce93d56-6fa4-1bae-d440-5ab843900e40@jordan.maileater.net> <20180329.100824.337723587531388798.levitte@openssl.org> Message-ID: On 3/29/2018 1:08 AM, Richard Levitte wrote: > In message <1ce93d56-6fa4-1bae-d440-5ab843900e40 at jordan.maileater.net> on Wed, 28 Mar 2018 17:10:40 -0700, Jordan Brown said: > > openssl> Matt: Indeed, looks very promising. Now if only we were on > openssl> 1.1.1 :-(. I'm a little surprised that it doesn't read from a > openssl> BIO. > > It's certainly possible to add such an API. As a matter of fact, we > do have that internally, specifically for PEM files... have a look in > 1.1.1's crypto/include/internal/store_int.h. That's not the initial > intention with the API, though... To be clear:? it doesn't bother me one way or the other.? It just seemed like the general design for "reading data from a stream" for OpenSSL is to read from a BIO, rather than directly providing "read from file", "read from memory buffer", et cetera.? I was surprised to see a new feature that didn't follow that pattern.? I *do* need "read from memory" for my application, but writing a temporary file would not be a problem. > Also, I can't quite shake the feeling that a BIO API would be a bit > shaky. Internally, the file: scheme loader opens all files in binary > mode, as it's designed to detect if the file is a PEM file or raw DER, > so the question remains, if we would open up a BIO STORE API, what are > th expectations? Will people open such files in binary mode at all > times? Should that be a content type agnostic interface (i.e. should > it detect if the file is PEM or raw DER), or should there be separate > functions for PEM and raw DER content? I would expect the behavior to be identical for a BIO interface and any other - which, I guess, would mean that the BIO would need to be in binary mode. > Please note that for each question, we're getting further and further > away from the idea of having an interface where the caller doesn't > need to know much more than how to indicate where to load stuff from, > to an API that almost becomes a 1:1 mapping of PEM and d2i functions. > When we've come that far, what have we gained? Agreed that for this interface the caller shouldn't need to know what's being read. -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Fri Mar 30 18:17:14 2018 From: levitte at openssl.org (Richard Levitte) Date: Fri, 30 Mar 2018 20:17:14 +0200 (CEST) Subject: [openssl-users] STORE (was: get type of PEM data) In-Reply-To: References: <1ce93d56-6fa4-1bae-d440-5ab843900e40@jordan.maileater.net> <20180329.100824.337723587531388798.levitte@openssl.org> Message-ID: <20180330.201714.1298091044592633599.levitte@openssl.org> In message on Fri, 30 Mar 2018 10:29:52 -0700, Jordan Brown said: openssl> [re STORE design] openssl> To be clear: it doesn't bother me one way or the other. It openssl> just seemed like the general design for "reading data from a openssl> stream" for OpenSSL is to read from a BIO, rather than openssl> directly providing "read from file", "read from memory openssl> buffer", et cetera. I was surprised to see a new feature that openssl> didn't follow that pattern. I *do* need "read from memory" openssl> for my application, but writing a temporary file would not be openssl> a problem. Well, thing is that the source of data might not be something that lends itself well for a BIO interface... For example certificates and keys hidden by an HSM of some sort. So the STORE is an abstraction of any sort of storage for that kind of protected data, and to directly translate it to usable objects, something that would be quite difficult with the BIO API. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/