Re: [openssl-users] How to form a proper hash after writing something into SSL handshake.

[Michael Sierchio]

Comic Sans. Need I say more?

On Tue, Dec 26, 2017 at 4:53 AM, Sai Teja Chowdary <
asteja.chowdary.ec...@itbhu.ac.in> wrote:

>
>
> Hi,
>
>
>
> Happy Holidays everyone.
>
>
>
> I want to send client certificate, client key exchange and client verify
> in a single handshake message which appears as multiple handshake messages
> in a single record. But to sent the client verify I need to first make a
> hash of previous messages(client certificate and client key exchange) to
> create the signature.
>
>
>
> Can anyone help me to find the function in OpenSSL 1.1.1-dev  xx XXX 
> (or right procedure that needs to be done before creating a certificate
> verify message)that can do a proper transcript(digest or hash not clear). I
> tried using *ssl3_finish_mac() *on the message containing client
> certificate and client key exchange and then tried to generate the
> signature in certificate verify message.
>
> But it is giving me a digest error. I am new to the mailing list want a
> bit of help to proceed forward stuck here. Please reply in case if anything
> is not clear.
>
>
>
> Here is a code snippet, how I am forming the data containing all client
> certificate , client key exchange and certificate verify messages inside
> write_state_machine().
>
>
>
> if(WPACKET_init(, s->init_buf)){
>
> //Client certificate formation
>
>  if(!ssl_set_handshake_header(s,,mt) || confunc != NULL
> && !confunc(s,) || !ssl_close_construct_packet(s,,mt)){
>
>   printf("PROBLEM\n");
>
> }
>
>  transition(s);  //transition to next state i.e client key
> exchange
>
>
>
>  get_construct_message_f(s, , , );
>
> //client key exchange formation
>
>  if(!ssl_set_handshake_header(s,,mt) || confunc != NULL
> && !confunc(s,) || !ssl_close_construct_packet(s,,mt)){
>
>printf("AGAIN A PROBLEMO\n");
>
> }
>
>
>
> //ssl3_finish_mac(s, >init_buf->data[s->init_off], s->init_num);
>
>  st->write_state_work = post_work(s, st->write_state_work);
>
>  transition(s);  // transition to next state i.e  certificate
> verify
>
>
>
>  get_construct_message_f(s, , , );
>
> //certificate verify message formation.
>
>  if(!ssl_set_handshake_header(s,,mt) || confunc != NULL
> && !confunc(s,) ||
> !ssl_close_construct_packet(s,,mt)){
>
>printf("AGAIN A PROBLEMO\n");
>
> }
>
>  WPACKET_finish();
>
>
>
>
>
> Please take a look at it, appreciate every bit of help.
>
>
>
> Regards,
>
> Saiteja
>
>
>
> --
> 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
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Question as to best options....

[Salz, Rich via openssl-users]

The difference is “auto private key” versus “RSA private key.”

> -BEGIN PRIVATE KEY-

This is a private key wrapped in a PKCS8 container with a key-type identifier.


root@Test-MCP:/usr/local/etc/HD-MCP/ssl/x # openssl rsa -inform pem -in 
test.key -outform der -out key.der
writing RSA key

This just writes the DER of the RSA key.  Different thing.

Try dumping the der files with asn1dump


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Question as to best options....

[Karl Denninger]

On 12/28/2017 18:31, Salz, Rich via openssl-users wrote:
>
> It is hard to follow this thread with all the indenting.
>
>  
>
> >  If I take a PEM-encoded RSA private key file and convert it to
> binary (using b64decode) what I get is not the same thing as I get
> from "openssl rsa -inform pem -in key -outform der -out key.der".
>
> How do you convert it?  Did you strip off the ---BEGIN and END tags? 
> Then it absolutely should have been the same thing.
>
Yes, I certainly did.  And it's not the same thing.

Proof:

root@Test-MCP:/usr/local/etc/HD-MCP/ssl/x # diff key.pem test.key
0a1
> -BEGIN PRIVATE KEY-
26a28
> -END PRIVATE KEY-
root@Test-MCP:/usr/local/etc/HD-MCP/ssl/x # ls -al
total 16
drwxr-xr-x  2 root   wheel   512 Dec 28 18:36 .
drwx--  3 hdmcp  wheel   512 Dec 28 18:33 ..
-rw---  1 root   wheel  1654 Dec 28 18:33 key.pem
-rw---  1 root   wheel  1708 Dec 28 18:35 test.key

Only difference is the barrier lines in the test.key file (which have to
be there for openssl or it throws up.)  Now we run:

root@Test-MCP:/usr/local/etc/HD-MCP/ssl/x # openssl rsa -inform pem -in
test.key -outform der -out key.der
writing RSA key
root@Test-MCP:/usr/local/etc/HD-MCP/ssl/x # b64decode -r key.pem >
key.bin 
root@Test-MCP:/usr/local/etc/HD-MCP/ssl/x # ls -la
total 24
drwxr-xr-x  2 root   wheel   512 Dec 28 18:37 .
drwx--  3 hdmcp  wheel   512 Dec 28 18:33 ..
-rw-r--r--  1 root   wheel  1219 Dec 28 18:37 key.bin
-rw-r--r--  1 root   wheel  1193 Dec 28 18:37 key.der
-rw---  1 root   wheel  1654 Dec 28 18:33 key.pem
-rw---  1 root   wheel  1708 Dec 28 18:35 test.key
root@Test-MCP:/usr/local/etc/HD-MCP/ssl/x #

Those output files (key.bin and key.der) are not the same -- they're
different within the first few bytes on examination with od -t x1, not
just on length (e.g. trash at the end)

If I load key.der into a binary buffer and run d2i_AutoPrivateKey
against it I get a valid EVP_PKEY buffer back and no error.

I'll chase this down further, but I think the easiest way may be to just
run DER files, since those work... :-)

> An internal structure, such as an RSA object, can be converted to DER
> using d2i_RSA.  DER is useful because it is a “flat” format, whereas
> the internal object is useful in the C code.  Make sense?  DER files
> are useful if you already know what the filetype is.  The d2i_ and
> i2d_ functions convert between internal (C structures, with pointers
> etc) to DER encoding.  They basically work on buffers, only.
>

> PEM files are base64 encoded DER, with BEGIN and END tags that specify
> what the middle-part is.  It is useful because it is human readable.
> Also the PEM_read_ functions will check what is expected to what
> the file says it is.
>
> Most objects have PEM_read and PEM_write functions as well.  They are
> not necessarily obvious from scanning the header files, because they
> are declared and implemented as macro’s, as it’s common code with just
> a pointer to an internal description of what the ASN1/DER looks like.
>
> The documentation on the master branch does a much better, and more
> complete, job of explaining this.
>
> The function I think you want is PEM_read_PrivateKey.
>
I'll look in there; my assumption was that I could trivially convert a
PEM file into an internal DER representation by stripping the flag lines
from the front and rear and then decoding the base64 piece.

Thanks; I'll figger it out :-)

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Question as to best options....

[Salz, Rich via openssl-users]

It is hard to follow this thread with all the indenting.

>  If I take a PEM-encoded RSA private key file and convert it to binary (using 
> b64decode) what I get is not the same thing as I get from "openssl rsa 
> -inform pem -in key -outform der -out key.der".

How do you convert it?  Did you strip off the ---BEGIN and END tags?  Then it 
absolutely should have been the same thing.
An internal structure, such as an RSA object, can be converted to DER using 
d2i_RSA.  DER is useful because it is a “flat” format, whereas the internal 
object is useful in the C code.  Make sense?  DER files are useful if you 
already know what the filetype is.  The d2i_ and i2d_ functions convert between 
internal (C structures, with pointers etc) to DER encoding.  They basically 
work on buffers, only.
PEM files are base64 encoded DER, with BEGIN and END tags that specify what the 
middle-part is.  It is useful because it is human readable. Also the 
PEM_read_ functions will check what is expected to what the file says it is.
Most objects have PEM_read and PEM_write functions as well.  They are not 
necessarily obvious from scanning the header files, because they are declared 
and implemented as macro’s, as it’s common code with just a pointer to an 
internal description of what the ASN1/DER looks like.
The documentation on the master branch does a much better, and more complete, 
job of explaining this.
The function I think you want is PEM_read_PrivateKey.


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Question as to best options....

[Karl Denninger]

On 12/28/2017 16:57, Karl Denninger wrote:
> On 12/28/2017 16:15, Karl Denninger wrote:
>> On 12/26/2017 14:07, Kurt Roeckx wrote:
>>> On Tue, Dec 26, 2017 at 01:42:57PM -0600, Karl Denninger wrote:
 On 12/26/2017 13:14, Salz, Rich via openssl-users wrote:
> So if you put locks around the SSL_CTX object when it’s used, then you
> can use the set private key call to update the key; and then all
> SSL_new objects afterwards will use the new credentials.  Does that
> meet your need?
>
 Yes, that I already know how to do.  The issue is how to get the key
 from a PEM file into a format that I can feed it with set private key. 
 There doesn't appear to be a means to "un-file-ify" the set private key
 functions.
>>> You can use the d2i_PrivateKey and i2d_PrivateKey functions to read
>>> and write the file.
>>>
>> "is there a decent way to convert a PEM or DER private key file into
> ASN.1" using OpenSSL calls (from a "C" program, not from the command
> line; we'll assume I have the key and cert files already.)
>
> I assume you mean “native C structure” and not ASN1?  Because DER is
> just the ASN1 serialized, and PEM is base64 encoded DER with marker
> lines. …
>
>
>
 So if I take a PEM private key file, strip the markers, and turn the
 actual key's base64 into binary (assuming an RSA key, so there's no "EC
 parameter" block in front) I now have an "opaque" unsigned character
 array of length "len" (the decoded Base64) which
 SSL_CTX_use_privateKey_ASN1 will accept?  (Assuming the key file is
 unencrypted, of course.)

 What is the parameter "pk" passed to the call in that instance (it's not
 in the man page)
>>> From the manpage:
>>> SSL_CTX_use_PrivateKey_ASN1() adds the private key of type _pk_
>>>
>>> So you would need to know that it's an RSA or EC key. If you used
>>> d2i_AutoPrivateKey you don't need to know the type and get an
>>> EVP_PKEY.
>>>
>>>
>>> Kurt
>> Not sure what I'm doing wrong here but obviously its something!
>>
>> certtemp = *char
>> certstore = unsigned char*  (Both with enough allocated memory to
>> hold the required data, of course)
>> const unsigned char *p;
>>
>> certstore has the Base64 key in it (checked manually, I am reading it
>> properly from the key file with the barrier lines and line feeds
>> omitted.)
>>
>>    ...
>>
>>     strcpy((char *) certstore, certtemp);
>>     p = certstore;
>>     key = d2i_AutoPrivateKey(NULL, , strlen(certtemp));
>>     if (key == NULL) {
>>     ERR_error_string(ERR_get_error(), tmp);
>> >>   return(NULL);
>>     }
>>
>>     ..
>>
>> But I get
>>
>> $4 = 0xbf3f9b90 "error:0D0680A8:asn1 encoding
>> routines:ASN1_CHECK_TLEN:wrong tag"
>> in tmp and a NULL key return from d2i_AutoPrivateKey at the ">>"
>> breakpoint.
>>
>> If I convert the base64 to binary first -- using the Base64 routine
>> in OpenSSL (which I know I've coded correctly as the code in question
>> uses it elsewhere to decode a MIME attachment) and pass a binary
>> buffer and the length of that buffer (instead of a base64 buffer and
>> its length) I still get NULL back for the EVP_PKEY structure and the
>> same error text in tmp.
>>
>> If I load that same key file with (having put the path to the key
>> file in tmp) with:
>>
>> if (SSL_CTX_use_PrivateKey_file(www_context, tmp, SSL_FILETYPE_PEM) <
>> 0) {.
>>
>> It loads and works.
>>
>> What's even MORE odd is that if I do this with the SAME key data I
>> just loaded in base64 (knowing it's an RSA key):
>>
>>      len = (strlen(certtemp) * 3) / 4 +1;
>>  cbin = decode_base64(certtemp, strlen(certtemp));
>>  if (SSL_CTX_use_PrivateKey_ASN1(EVP_PKEY_RSA, www_context,
>> cbin, len)) {
>>  ERR_error_string(ERR_get_error(), tmp);
>>  return(NULL);
>>  }
>>
>> THAT loads (the use_PrivateKey_ASN1 call returns zero -- and thus
>> obviously likes what I passed it)
>>
>> There's probably something obvious I'm missing on what I'm doing
>> wrong with the d2i call -- any quick hit pointers welcome
>>
>> -- 
>> Karl Denninger
>> k...@denninger.net 
>> /The Market Ticker/
>> /[S/MIME encrypted email preferred]/
>>
>>
> Ok, never mind, it appears to take the key but then when I check for
> coherence between the key and certificate it says they don't
> match. so apparently it does NOT like the key load in ASN1, even
> though it doesn't complain about it when I call the "use" function.
>
> H
>
Maybe I'm onto something here

If I take a PEM-encoded RSA private key file and convert it to binary
(using b64decode) what I get is not the same thing as I get from
"openssl rsa -inform pem -in key -outform der -out key.der".

But I thought from the previous discussion a PEM file was simply a
base64 rendition of the binary in a DER file  Doesn't look that way.

So what does 

Re: [openssl-users] Question as to best options....

[Karl Denninger]

On 12/28/2017 16:15, Karl Denninger wrote:
> On 12/26/2017 14:07, Kurt Roeckx wrote:
>> On Tue, Dec 26, 2017 at 01:42:57PM -0600, Karl Denninger wrote:
>>> On 12/26/2017 13:14, Salz, Rich via openssl-users wrote:
 So if you put locks around the SSL_CTX object when it’s used, then you
 can use the set private key call to update the key; and then all
 SSL_new objects afterwards will use the new credentials.  Does that
 meet your need?

>>> Yes, that I already know how to do.  The issue is how to get the key
>>> from a PEM file into a format that I can feed it with set private key. 
>>> There doesn't appear to be a means to "un-file-ify" the set private key
>>> functions.
>> You can use the d2i_PrivateKey and i2d_PrivateKey functions to read
>> and write the file.
>>
> "is there a decent way to convert a PEM or DER private key file into
 ASN.1" using OpenSSL calls (from a "C" program, not from the command
 line; we'll assume I have the key and cert files already.)

 I assume you mean “native C structure” and not ASN1?  Because DER is
 just the ASN1 serialized, and PEM is base64 encoded DER with marker
 lines. …



>>> So if I take a PEM private key file, strip the markers, and turn the
>>> actual key's base64 into binary (assuming an RSA key, so there's no "EC
>>> parameter" block in front) I now have an "opaque" unsigned character
>>> array of length "len" (the decoded Base64) which
>>> SSL_CTX_use_privateKey_ASN1 will accept?  (Assuming the key file is
>>> unencrypted, of course.)
>>>
>>> What is the parameter "pk" passed to the call in that instance (it's not
>>> in the man page)
>> From the manpage:
>> SSL_CTX_use_PrivateKey_ASN1() adds the private key of type _pk_
>>
>> So you would need to know that it's an RSA or EC key. If you used
>> d2i_AutoPrivateKey you don't need to know the type and get an
>> EVP_PKEY.
>>
>>
>> Kurt
> Not sure what I'm doing wrong here but obviously its something!
>
> certtemp = *char
> certstore = unsigned char*  (Both with enough allocated memory to hold
> the required data, of course)
> const unsigned char *p;
>
> certstore has the Base64 key in it (checked manually, I am reading it
> properly from the key file with the barrier lines and line feeds omitted.)
>
>    ...
>
>     strcpy((char *) certstore, certtemp);
>     p = certstore;
>     key = d2i_AutoPrivateKey(NULL, , strlen(certtemp));
>     if (key == NULL) {
>     ERR_error_string(ERR_get_error(), tmp);
> >>   return(NULL);
>     }
>
>     ..
>
> But I get
>
> $4 = 0xbf3f9b90 "error:0D0680A8:asn1 encoding
> routines:ASN1_CHECK_TLEN:wrong tag"
> in tmp and a NULL key return from d2i_AutoPrivateKey at the ">>"
> breakpoint.
>
> If I convert the base64 to binary first -- using the Base64 routine in
> OpenSSL (which I know I've coded correctly as the code in question
> uses it elsewhere to decode a MIME attachment) and pass a binary
> buffer and the length of that buffer (instead of a base64 buffer and
> its length) I still get NULL back for the EVP_PKEY structure and the
> same error text in tmp.
>
> If I load that same key file with (having put the path to the key file
> in tmp) with:
>
> if (SSL_CTX_use_PrivateKey_file(www_context, tmp, SSL_FILETYPE_PEM) <
> 0) {.
>
> It loads and works.
>
> What's even MORE odd is that if I do this with the SAME key data I
> just loaded in base64 (knowing it's an RSA key):
>
>      len = (strlen(certtemp) * 3) / 4 +1;
>  cbin = decode_base64(certtemp, strlen(certtemp));
>  if (SSL_CTX_use_PrivateKey_ASN1(EVP_PKEY_RSA, www_context,
> cbin, len)) {
>  ERR_error_string(ERR_get_error(), tmp);
>  return(NULL);
>  }
>
> THAT loads (the use_PrivateKey_ASN1 call returns zero -- and thus
> obviously likes what I passed it)
>
> There's probably something obvious I'm missing on what I'm doing wrong
> with the d2i call -- any quick hit pointers welcome
>
> -- 
> Karl Denninger
> k...@denninger.net 
> /The Market Ticker/
> /[S/MIME encrypted email preferred]/
>
>
Ok, never mind, it appears to take the key but then when I check for
coherence between the key and certificate it says they don't match.
so apparently it does NOT like the key load in ASN1, even though it
doesn't complain about it when I call the "use" function.

H

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] New usability feature

[Viktor Dukhovni]

> On Dec 28, 2017, at 5:16 PM, Salz, Rich via openssl-users 
>  wrote:
> 
> No, but that would be simple to add if you are up for doing the PR.

For the record, as mentioned in a previous post, this is already
available for self-signed certificates (via openssl req -x509).
What's missing is support for ca-issued certificates
(via openssl x509 -req).

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Can't build OpenSSL on Windows

[Martin Galvan]

Hi all,

I'm trying to build OpenSSL on Windows. I'm using the nmake that came with
Visual Studio 2017, NASM, ActivePerl and have installed the Test::More and
Test::Template modules. nmake, perl and nasm are all visible in my system Path
variable. This is what I'm seeing:

C:\Users\e1\openssl\source>perl Configure VC-WIN64A 
--prefix=\c\Users\e1\openssl\install-windows no-comp no-zlib
Configuring OpenSSL version 1.1.0g (0x1010007fL)
no-asan [default]  OPENSSL_NO_ASAN
no-comp [option]   OPENSSL_NO_COMP (skip dir)
no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG
no-crypto-mdebug-backtrace [default]  OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128
no-egd  [default]  OPENSSL_NO_EGD
no-fuzz-afl [default]  OPENSSL_NO_FUZZ_AFL
no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER
no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS
no-md2  [default]  OPENSSL_NO_MD2 (skip dir)
no-msan [default]  OPENSSL_NO_MSAN
no-rc5  [default]  OPENSSL_NO_RC5 (skip dir)
no-sctp [default]  OPENSSL_NO_SCTP
no-ssl-trace[default]  OPENSSL_NO_SSL_TRACE
no-ssl3 [default]  OPENSSL_NO_SSL3
no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD
no-ubsan[default]  OPENSSL_NO_UBSAN
no-unit-test[default]  OPENSSL_NO_UNIT_TEST
no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS
no-zlib [option]
no-zlib-dynamic [default]
Configuring for VC-WIN64A
CC=cl
CFLAG =-W3 -wd4090 -Gs0 -GF -Gy -nologo -DOPENSSL_SYS_WIN32 
-DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DUNICODE 
-D_UNICODE /MD /O2
SHARED_CFLAG  =
DEFINES   =OPENSSL_USE_APPLINK DSO_WIN32 NDEBUG OPENSSL_THREADS 
OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT 
OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM RC4_ASM 
MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM PADLOCK_ASM 
POLY1305_ASM
LFLAG =/nologo /debug
PLIB_LFLAG=
EX_LIBS   =ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib
APPS_OBJ  =win32_init.o ../ms/applink.o
CPUID_OBJ =x86_64cpuid.o
UPLINK_OBJ=../ms/uplink.o uplink-x86_64.o
BN_ASM=bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o rsaz_exp.o 
rsaz-x86_64.o rsaz-avx2.o
EC_ASM=ecp_nistz256.o ecp_nistz256-x86_64.o
DES_ENC   =des_enc.o fcrypt_b.o
AES_ENC   =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o 
aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
BF_ENC=bf_enc.o
CAST_ENC  =c_enc.o
RC4_ENC   =rc4-x86_64.o rc4-md5-x86_64.o
RC5_ENC   =rc5_enc.o
MD5_OBJ_ASM   =md5-x86_64.o
SHA1_OBJ_ASM  =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o 
sha256-mb-x86_64.o
RMD160_OBJ_ASM=
CMLL_ENC  =cmll-x86_64.o cmll_misc.o
MODES_OBJ =ghash-x86_64.o aesni-gcm-x86_64.o
PADLOCK_OBJ   =e_padlock-x86_64.o
CHACHA_ENC=chacha-x86_64.o
POLY1305_OBJ  =poly1305-x86_64.o
BLAKE2_OBJ=
PROCESSOR =
RANLIB=true
ARFLAGS   =/nologo
PERL  =C:\Perl64\bin\perl.exe

SIXTY_FOUR_BIT mode

Configured for VC-WIN64A.

And then:

C:\Users\e1\openssl\source>nmake

Microsoft (R) Program Maintenance Utility Version 14.11.25547.0
Copyright (C) Microsoft Corporation.  All rights reserved.

"Detected changed: ".\Configure" "Configurations\windows-makefile.tmpl" 
"Configurations\common.tmpl"
"build.info" "crypto\build.info" "ssl\build.info" "engines\build.info" 
"apps\build.info"
"test\build.info" "util\build.info" "tools\build.info" "fuzz\build.info" 
"crypto\objects\build.info"
"crypto\md4\build.info" "crypto\md5\build.info" "crypto\sha\build.info" 
"crypto\mdc2\build.info"
"crypto\hmac\build.info" "crypto\ripemd\build.info" "crypto\whrlpool\build.info"
"crypto\poly1305\build.info" "crypto\blake2\build.info" "crypto\des\build.info" 
"crypto\aes\build.info"
"crypto\rc2\build.info" "crypto\rc4\build.info" "crypto\idea\build.info" 
"crypto\bf\build.info"
"crypto\cast\build.info" "crypto\camellia\build.info" "crypto\seed\build.info" 
"crypto\chacha\build.info"
"crypto\modes\build.info" "crypto\bn\build.info" "crypto\ec\build.info" 
"crypto\rsa\build.info"
"crypto\dsa\build.info" "crypto\dh\build.info" "crypto\dso\build.info" 
"crypto\engine\build.info"
"crypto\buffer\build.info" "crypto\bio\build.info" "crypto\stack\build.info" 
"crypto\lhash\build.info"
"crypto\rand\build.info" "crypto\err\build.info" "crypto\evp\build.info" 
"crypto\asn1\build.info"
"crypto\pem\build.info" "crypto\x509\build.info" "crypto\x509v3\build.info" 
"crypto\conf\build.info"
"crypto\txt_db\build.info" "crypto\pkcs7\build.info" "crypto\pkcs12\build.info" 
"crypto\ocsp\build.info"
"crypto\ui\build.info" "crypto\cms\build.info" "crypto\ts\build.info" 
"crypto\srp\build.info"
"crypto\cmac\build.info" "crypto\ct\build.info" "crypto\async\build.info" 
"crypto\kdf\build.info"

Re: [openssl-users] New usability feature

[Salz, Rich via openssl-users]

No, but that would be simple to add if you are up for doing the PR.

For now, the cert config file would have to copy the extensions.

From: Dmitry Belyavsky 
Date: Thursday, December 28, 2017 at 4:34 PM
To: Rich Salz , openssl-users 
Subject: Re: [openssl-users] New usability feature

Dear Rich,

Great news!
Does it work for certificates too?



On Thu, Dec 28, 2017 at 11:51 PM, Salz, Rich via openssl-users 
> wrote:
Having wrestled with this in the past, I want to point out that with commit 
https://github.com/openssl/openssl/commit/bfa470a4f64313651a35571883e235d3335054eb
 in master, it’s now possible to put a SAN field (or any extension) in a cert 
request via the command line; no special custom config or fancy ENV vars needed.

Hooray!

--
openssl-users mailing list
To unsubscribe: 
https://mta.openssl.org/mailman/listinfo/openssl-users



--
SY, Dmitry Belyavsky
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Question as to best options....

[Karl Denninger]

On 12/26/2017 14:07, Kurt Roeckx wrote:
> On Tue, Dec 26, 2017 at 01:42:57PM -0600, Karl Denninger wrote:
>> On 12/26/2017 13:14, Salz, Rich via openssl-users wrote:
>>> So if you put locks around the SSL_CTX object when it’s used, then you
>>> can use the set private key call to update the key; and then all
>>> SSL_new objects afterwards will use the new credentials.  Does that
>>> meet your need?
>>>
>> Yes, that I already know how to do.  The issue is how to get the key
>> from a PEM file into a format that I can feed it with set private key. 
>> There doesn't appear to be a means to "un-file-ify" the set private key
>> functions.
> You can use the d2i_PrivateKey and i2d_PrivateKey functions to read
> and write the file.
>
 "is there a decent way to convert a PEM or DER private key file into
>>> ASN.1" using OpenSSL calls (from a "C" program, not from the command
>>> line; we'll assume I have the key and cert files already.)
>>>
>>> I assume you mean “native C structure” and not ASN1?  Because DER is
>>> just the ASN1 serialized, and PEM is base64 encoded DER with marker
>>> lines. …
>>>
>>>
>>>
>> So if I take a PEM private key file, strip the markers, and turn the
>> actual key's base64 into binary (assuming an RSA key, so there's no "EC
>> parameter" block in front) I now have an "opaque" unsigned character
>> array of length "len" (the decoded Base64) which
>> SSL_CTX_use_privateKey_ASN1 will accept?  (Assuming the key file is
>> unencrypted, of course.)
>>
>> What is the parameter "pk" passed to the call in that instance (it's not
>> in the man page)
> From the manpage:
> SSL_CTX_use_PrivateKey_ASN1() adds the private key of type _pk_
>
> So you would need to know that it's an RSA or EC key. If you used
> d2i_AutoPrivateKey you don't need to know the type and get an
> EVP_PKEY.
>
>
> Kurt
Not sure what I'm doing wrong here but obviously its something!

certtemp = *char
certstore = unsigned char*  (Both with enough allocated memory to hold
the required data, of course)
const unsigned char *p;

certstore has the Base64 key in it (checked manually, I am reading it
properly from the key file with the barrier lines and line feeds omitted.)

   ...

    strcpy((char *) certstore, certtemp);
    p = certstore;
    key = d2i_AutoPrivateKey(NULL, , strlen(certtemp));
    if (key == NULL) {
    ERR_error_string(ERR_get_error(), tmp);
>>   return(NULL);
    }

    ..

But I get

$4 = 0xbf3f9b90 "error:0D0680A8:asn1 encoding
routines:ASN1_CHECK_TLEN:wrong tag"
in tmp and a NULL key return from d2i_AutoPrivateKey at the ">>" breakpoint.

If I convert the base64 to binary first -- using the Base64 routine in
OpenSSL (which I know I've coded correctly as the code in question uses
it elsewhere to decode a MIME attachment) and pass a binary buffer and
the length of that buffer (instead of a base64 buffer and its length) I
still get NULL back for the EVP_PKEY structure and the same error text
in tmp.

If I load that same key file with (having put the path to the key file
in tmp) with:

if (SSL_CTX_use_PrivateKey_file(www_context, tmp, SSL_FILETYPE_PEM) < 0)
{.

It loads and works.

What's even MORE odd is that if I do this with the SAME key data I just
loaded in base64 (knowing it's an RSA key):

     len = (strlen(certtemp) * 3) / 4 +1;
 cbin = decode_base64(certtemp, strlen(certtemp));
 if (SSL_CTX_use_PrivateKey_ASN1(EVP_PKEY_RSA, www_context,
cbin, len)) {
 ERR_error_string(ERR_get_error(), tmp);
 return(NULL);
 }

THAT loads (the use_PrivateKey_ASN1 call returns zero -- and thus
obviously likes what I passed it)

There's probably something obvious I'm missing on what I'm doing wrong
with the d2i call -- any quick hit pointers welcome

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] New usability feature

[Viktor Dukhovni]

> On Dec 28, 2017, at 4:34 PM, Dmitry Belyavsky  wrote:
> 
> Great news!
> Does it work for certificates too?

The updated documentation says:

+=item B<-addext ext>
+
+Add a specific extension to the certificate (if the B<-x509> option is
+present) or certificate request. The argument must have the form of
+a key=value pair as it would appear in a config file.
+
+This option can be given multiple times.

So it should work for "openssl req -x509".  There should probably be
corresponding changes for "openssl x509 -req", which can be used for
more than just self-signed certs.

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] New usability feature

[Dmitry Belyavsky]

Dear Rich,

Great news!
Does it work for certificates too?



On Thu, Dec 28, 2017 at 11:51 PM, Salz, Rich via openssl-users <
openssl-users@openssl.org> wrote:

> Having wrestled with this in the past, I want to point out that with
> commit https://github.com/openssl/openssl/commit/
> bfa470a4f64313651a35571883e235d3335054eb in master, it’s now possible to
> put a SAN field (or any extension) in a cert request via the command line;
> no special custom config or fancy ENV vars needed.
>
>
>
> Hooray!
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>


-- 
SY, Dmitry Belyavsky
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] New usability feature

[Salz, Rich via openssl-users]

Having wrestled with this in the past, I want to point out that with commit 
https://github.com/openssl/openssl/commit/bfa470a4f64313651a35571883e235d3335054eb
 in master, it’s now possible to put a SAN field (or any extension) in a cert 
request via the command line; no special custom config or fancy ENV vars needed.

Hooray!
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [EXTERNAL] Certificate gets verified OK over SSL-CLI, but not when using SSL-API

[Salz, Rich via openssl-users]

> Hence, if at all, verification requirements must have been lowered in the new 
> OpenSSL version.

No, it is also the case that the new version now more correctly accepts some 
chains as valid that because of bugs, the old version did not.


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Certificate gets verified OK over SSL-CLI, but not when using SSL-API

[Viktor Dukhovni]

> On Dec 28, 2017, at 4:54 AM, Manuel Wagesreither  wrote:
> 
> Thanks for your feedback. Unfortunately I cannot include the certificate raw 
> data as it may contain sensitive information. Also, I'm unable to replace 
> them with self-made certificates as I don't know the parameters the original 
> ones were created with in the first place. The original creators are 
> inaccessible at the moment. If the problem persists, I will reproduce the 
> problem with test certificates (whose raw data I can publish) in a few weeks.

You should be able to publish edited output of:

openssl crl2pkcs7 -nocrl -certfile chain.pem |
openssl pkcs7 -print_certs -text -noout

With any sensitive values hand-replaced with "censored-NNN"
where the "NNN" part uniquely corresponds to each original
value (same values get same "NNN", distinct values get
distinct "NNN").

The "chain.pem" file should have the leaf certificate first,
then its issuer, then the issuer of that certificate, ...
up to the trust anchor.  Please also make sure that the
chain in question passes (with OpenSSL 1.1.0 per your report)
is reported verified with:

$ openssl verify -no-CApath -no-CAfile \
-trusted root.pem -untrusted chain.pem \
chain.pem

Where "root.pem" contains just the last certificate
from the chain.pem file.  Post the output of that
command for 1.1.0.  Please also report similar output
for 1.0.2, with the command modified to:

$ capath=$(mktemp -d empty.XX)
$ cafile=root.pem
$ openssl verify -CApath $capath -CAfile root.pem \
-trusted root.pem -untrusted chain.pem \
chain.pem

Again, if anything in the output is sensitive, censor the
values, with "censoredNNN" matching the replacements in
the certificate chain.

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [EXTERNAL] Certificate gets verified OK over SSL-CLI, but not when using SSL-API

[Manuel Wagesreither]

Am Fr, 22. Dez 2017, um 20:31, schrieb Sands, Daniel:
> On Fri, 2017-12-22 at 11:14 +0100, Manuel Wagesreither wrote:
> > Unfortunately this didn't work either. The end result is the same;
> > OpenSSL still emits a "certificate signature failure" with an error
> > depth of 0.
> > 
> In light of what Salz said about verification, could we assume that the
> openssl verify program that succeeded is based on the older library?

Thanks for your feedback! Actually it's the other way round. Validation 
succeeds with the *new* library (libssl.so.1.1), and fails with the *old* one 
(libssl.so.1.0.0). This is true with the openssl verify program as well: 
`openssl verify` succeeds for OpenSSL 1.1.0f, and fails for OpenSSL 1.0.1g.

Hence, if at all, verification requirements must have been lowered in the new 
OpenSSL version. I'm just about to look for a list of criterias a certificate 
has to pass in order to validate successfully in the two OpenSSL versions.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Certificate gets verified OK over SSL-CLI, but not when using SSL-API

[Manuel Wagesreither]

Thanks for your feedback. Unfortunately I cannot include the certificate raw 
data as it may contain sensitive information. Also, I'm unable to replace them 
with self-made certificates as I don't know the parameters the original ones 
were created with in the first place. The original creators are inaccessible at 
the moment. If the problem persists, I will reproduce the problem with test 
certificates (whose raw data I can publish) in a few weeks.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users