From the_majkl at seznam.cz  Tue Aug  1 08:07:23 2017
From: the_majkl at seznam.cz (majkl majkl)
Date: Tue, 1 Aug 2017 10:07:23 +0200
Subject: [openssl-users] -engine pkcs11 - keyform ENGINE -inkey ABC : NOT in
	command line
Message-ID: <CAJ7z5aetbP1Z7Lez6HPqPbEUa3up9mBvDfZYd4qs9-1mhiUNXg@mail.gmail.com>

I need these openssl parameters to be used without specifying it in command
line. It doesn't matter, if it is in config file or environment variables.

How to do that?

(I need to sign xml documents via xmlsec. xmlsec can use openssl as crypto,
but I do not have idea, how xmlsec call openssl. It does not try to access
the USB token for key. openssl with the command line parameters can access
the key on the USB token with no problems.)

Thanks, Michal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170801/2efd257f/attachment.html>

From michele.mase at gmail.com  Tue Aug  1 12:46:13 2017
From: michele.mase at gmail.com (Michele Mase')
Date: Tue, 1 Aug 2017 14:46:13 +0200
Subject: [openssl-users] private key difference: openssl genrsa vs
 opnessl req newkey
In-Reply-To: <CAC=HuntL4nCvOKNFNCKErub-Z9Ga0wEh03ygwicnETwbhDbeiw@mail.gmail.com>
References: <CAC=HuntL4nCvOKNFNCKErub-Z9Ga0wEh03ygwicnETwbhDbeiw@mail.gmail.com>
Message-ID: <CAC=Hunu=U1A7P4wTTZAn1vHTeq6t-YJZ0dG1Far6c=0gKWfqtA@mail.gmail.com>

Anyone?

On Wed, Jul 26, 2017 at 9:21 PM, Michele Mase' <michele.mase at gmail.com>
wrote:

> Tx.
> So, what should be the command line to use in order to obtain the same key?
> openssl genrsa ....
> openssl req -nodes -newkey rsa:2048 some_extra_parameters ....
> Michele MAs?
>
> On Wed, Jul 26, 2017 at 6:29 PM, Benjamin Kaduk <bkaduk at akamai.com> wrote:
>
>> On 07/26/2017 10:13 AM, Michele Mase' wrote:
>>
>> During the generation of x509 certificates, both commands give the same
>> results:
>>
>> Command "a": openssl req -nodes -newkey rsa:2048 -keyout example.key -out
>> example.csr -subj "/C=GB/ST=London/L=London/O=Global Security/OU=IT
>> Department/CN=example.com
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=SvmGwnxF6Arf5U_XmN1vPPpie6IFH3h5CkVhveCn26I&s=AMT2W-m9xgiUsKMETv-WcWALqfQnX1rujJdNTJsVz1E&e=>
>> "
>> Command "b": openssl genrsa -out example.key
>>
>> Both commands give me a private key without password, a key that is not
>> encrypted.
>> To remove the passphrase from private key, I use the
>> Command "c":openssl rsa -in example.key -out example2.key
>>
>> The command "c" against the example.key generated by command "a", gives
>> the same private key with different content between --BEGIN RSA and --END
>> RSA. Simply, try the following:
>> diff example.key example2.key, the files are different.
>>
>> The command "c" against example.key generate by the command "b" produces
>> the same file. No differences.
>>
>> Why?
>> Perhaps I missed something in openssl manual ... :(
>> These differenced gave me troubles using custom certificates in some
>> software.
>> Any suggestion?
>>
>>
>> The output from openssl req includes an additional layer of encoding and
>> the rsaEncryption OID around the actual key parameters, as can be seen
>> using openssl asn1parse.  The conversion with 'openssl rsa' removes that
>> extra encoding.
>>
>> -Ben
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170801/e44b7088/attachment.html>

From openssl-users at dukhovni.org  Tue Aug  1 16:55:01 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 1 Aug 2017 16:55:01 +0000
Subject: [openssl-users] private key difference: openssl genrsa vs
 opnessl req newkey
In-Reply-To: <CAC=HuntL4nCvOKNFNCKErub-Z9Ga0wEh03ygwicnETwbhDbeiw@mail.gmail.com>
References: <CAC=HuntL4nCvOKNFNCKErub-Z9Ga0wEh03ygwicnETwbhDbeiw@mail.gmail.com>
Message-ID: <20170801165500.GK8146@mournblade.imrryr.org>

On Wed, Jul 26, 2017 at 09:21:43PM +0200, Michele Mase' wrote:

> So, what should be the command line to use in order to obtain the same key?
> openssl genrsa ....

This creates keys in a legacy RSA algorithm-specific format.

> openssl req -nodes -newkey rsa:2048 some_extra_parameters ....

This creates keys in the preferred standard PKCS#8 format.

You can use "openssl pkey" to read legacy RSA keys and output
PKCS#8 keys.  Or you can use "openssl genpkey" to generate
PKCS#8 keys directly:

    # RSA
    (umask 077; openssl genpkey -algorithm rsa -pkeyopt rsa_keygen_bits:2048 -out key.pem)

    # ECDSA P-256
    (umask 077; openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:prime256v1 -pkeyopt ec_param_enc:named_curve -out key.pem)

    # ECDSA P-384
    (umask 077; openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:secp384r1 -pkeyopt ec_param_enc:named_curve -out key.pem)

    # ECDSA P-521
    (umask 077; openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:secp521r1 -pkeyopt ec_param_enc:named_curve -out key.pem)

It is unfortunate that OpenSSL 1.0.2 does not accept curve name
aliases for ec_paramgen_curve.  Thus, for example, only "prime256v1"
is accepted for P-256 and not any of its other names.

I've not checked whether this is fixed in OpenSSL 1.1.0.

-- 
	Viktor.

From npathak2 at ncsu.edu  Tue Aug  1 17:46:38 2017
From: npathak2 at ncsu.edu (Neetish Pathak)
Date: Tue, 1 Aug 2017 10:46:38 -0700
Subject: [openssl-users] session resumption tls1.2/tls1.3
In-Reply-To: <8ecfa5ad-24da-4a08-3168-f0fb97899cfb@openssl.org>
References: <CANWFjKBJ5PVW2_WPAH_FR6EB0hR181a0cdS6R9oJ_5C5GmXREg@mail.gmail.com>
 <d8448365-2c21-8670-3542-4798ac343e1c@openssl.org>
 <CANWFjKDNX9Q7ptk9ZmLM5364f0ejWhvStYb7dxsxT1TeO0XDog@mail.gmail.com>
 <b243ca23-bc91-7d95-c5eb-a891e44a0d86@openssl.org>
 <CANWFjKCjwA-NegusVngj9+_bQMz91xELEQ1r538FQJCfVHmRNw@mail.gmail.com>
 <9782b31f-9472-c476-c98e-802e906b9c48@openssl.org>
 <CANWFjKBCetikoMDx=hmnHvZT-Ufguw04cBmkbeAaU-Y-2sLGQA@mail.gmail.com>
 <727734e1-a450-9b53-41e7-630f953de3c8@akamai.com>
 <CANWFjKDDNGP6eEwha+AY-EyunWz24LNQ-Jx9c8EKk5X5Zz06wA@mail.gmail.com>
 <91195d2f-94ea-6916-59b5-735c5f98a4c9@openssl.org>
 <CANWFjKD_Qnm2HcvtB_wSD3yCEKOMvyuN8Pxjd=vwZ3Oyyefupg@mail.gmail.com>
 <8ecfa5ad-24da-4a08-3168-f0fb97899cfb@openssl.org>
Message-ID: <CANWFjKAgGjHW3=+=cLBR34qv2Po8V6PgCx7jd2rK24RT7+_7vw@mail.gmail.com>

On Mon, Jul 31, 2017 at 2:00 PM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 31/07/17 20:37, Neetish Pathak wrote:
> >     On 26/07/17 00:05, Neetish Pathak wrote:
> >     >>     *Pseudocode for server*
> >     >>     *
> >     >>     *
> >     >>     tcp_accept
> >     >>     *
> >     >>     *
> >     >>     read_early{
> >     >>
> >     >>          if(read_early_success){
> >     >>               write_early(data)
> >     >>           }
> >     >>     }
> >
> >     There is a bit of complexity here (covered in the docs), i.e.
> >     SSL_read_early_data() may return SSL_READ_EARLY_DATA_SUCCESS or
> >     SSL_READ_EARLY_DATA_FINISH. In the latter case this is still a
> success,
> >     but the server may or may not be able to write early data. I assume
> that
> >     you have covered that in your actual code and it's just skimmed over
> >     here in your pseudo code.
> >
> >
> >
> > So, I consider read_early_sucess when  SSL_read_early_data() returns
> > SSL_READ_EARLY_DATA_FINISH. Also, I check that early data was accepted
> > before declaring success. Look at the case checks below
> >
> > *case* SSL_READ_EARLY_DATA_SUCCESS:
> >
> >         totalBytes += readBytes;
> >
> > *         break*;
> >
> > *
> > *
> >
> > *case* SSL_READ_EARLY_DATA_FINISH:
> >
> >        totalBytes += readBytes;
> >
> > *       if* (SSL_EARLY_DATA_ACCEPTED ==
> > SSL_get_early_data_status(*this*->conn) && totalBytes > 0) {
> >
> >              readBuf = string(readBuffer);
> >
> > *             return* SUCCESS;
> >
> >       }
> >
> >
> > So, are you suggesting that early data may not be written from the
> > server side if SSL_READ_EARLY_DATA_FINISH is received. Should I try
> > writing before that (as in when SSL_READ_EARLY_DATA_SUCCESS is received )
>
>
> SSL_READ_EARLY_DATA_FINISH is not returned until we have seen the
> EndOfEarlyData message. Often (but not always - dependent on the
> implementation) the client Finished message is also in the same packet
> which OpenSSL will immediately try and process. As soon as it has done
> so the handshake is complete and it is too late for the server to write
> early data. Calls to SSL_write_early_data() by the server at this point
> should fail (do you not see this???).
>
> You should write early data on the server side as soon as
> SSL_READ_EARLY_DATA_SUCCESS is received.
>


Yes, this is what I tried and it worked. Thanks for the clarification

>
>
>
> >     > No.     Time           Source                Destination
> >     > Protocol Length Info
> >     >     215 18.381122      ::1                   ::1
> >     > TLSv1.3  762    Application Data
> >     > Transmission Control Protocol, Src Port: 12345, Dst Port: 56806,
> Seq:
> >     > 144, Ack: 3738, Len: 686   -----I don't know why this application
> data
> >     > is sent from server. My guess is this is session info
> >
> >     It could be the NewSessionTicket message going from the server to the
> >     client. But if so that is a little strange. The NST message is only
> sent
> >     after the handshake is complete (so no more early data is possible).
> At
> >     this point SSL_read_early_data() should have returned
> >     SSL_READ_EARLY_DATA_SUCCESS, SSL_is_init_finished() will return true,
> >     and any calls to SSL_write_early_data() will fail.
> >
> >
> > Yes, here the handshake is completed. Will the new session ticket be
> > sent each time after the handshake? In theTLS 1.3 draft, it is mentioned
> > that new session tickets may be sent after server receives Finished from
> > the client and it creates a unique association between the ticket value
> > and a secret PSK derived from the resumption master secret.
> > But looks like, I am receiving new session ticket every-time. So, as per
> > the implementation, new session ticket is a must I guess. Am I right?
> > When will I not receive new session ticket in TLS 1.3?
>
> The OpenSSL implementation *always* sends a NewSessionTicket message
> immediately after the handshake is complete. This is not required, but
> is allowed by the spec. Currently there is no way to disable this
> behaviour. Do you need/want it (if so, why)?
>

No, I do not need to disable it per se. The handshake completion at the
client side is independent of the newsession ticket coming from the server
side if I am correct. So the handshake operation (specifically SSL_connect)
will return even if new session ticket has not arrived from the server. I
was asking why new session ticket is needed during the resumption
handshake. Isn't it just an overhead?


>
> >
> > Also, I believe it is different than how new session ticket works in TLS
> > 1.2 where it was sent only once to share the encrypted ticket from the
> > server side when the client indicates support for session tickets.
>
> Yes, TLSv1.2 session tickets share the same name and have a similar
> purpose, but are otherwise *completely* different to TLSv1.3 session
> tickets.
>

Understood

>
>
> >     >
> >     > No.     Time           Source                Destination
> >     > Protocol Length Info
> >     >     217 18.381210      ::1                   ::1
> >     > TLSv1.3  9917   Application Data          ----------*Intended
> >     > Application Data that was intended to be early data *
> >     > Transmission Control Protocol, Src Port: 12345, Dst Port: 56806,
> Seq:
> >     > 830, Ack: 3738, Len: 9841
> >     >
> >     > No.     Time           Source                Destination
> >     > Protocol Length Info
> >     >     219 18.381308      ::1                   ::1
> >     > TLSv1.3  100    Application Data .
>  ---------Application Data
> >     > from client (I also see this application data sent everytime, not
> sure why)
> >     > Transmission Control Protocol, Src Port: 56806, Dst Port: 12345,
> Seq:
> >     > 3738, Ack: 10671, Len: 24
> >     >
> >     >
> >     > No.     Time           Source                Destination
> >     > Protocol Length Info
> >     >     220 18.381309      ::1                   ::1
> >     > TLSv1.3  100    Application Data .  ---------Application Data from
> >     > server (I also see this application data sent everytime, not sure
> why)
> >
> >     Perhaps these are close_notify alerts? Are you shutting down the
> >     connection cleanly at this point?
> >
> >
> > I am shutting down the connection from the client side. Server is up all
> > the time for any new connection.
>
> As soon as you call SSL_shutdown() then a close_notify alert is sent.
> Typically you do that on both the client and the server sides which
> seems to match your wireshark trace.
>

OK Thanks

>
> Matt
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170801/e7296869/attachment.html>

From npathak2 at ncsu.edu  Tue Aug  1 23:14:38 2017
From: npathak2 at ncsu.edu (Neetish Pathak)
Date: Tue, 1 Aug 2017 16:14:38 -0700
Subject: [openssl-users] session resumption tls1.2/tls1.3
In-Reply-To: <CANWFjKAgGjHW3=+=cLBR34qv2Po8V6PgCx7jd2rK24RT7+_7vw@mail.gmail.com>
References: <CANWFjKBJ5PVW2_WPAH_FR6EB0hR181a0cdS6R9oJ_5C5GmXREg@mail.gmail.com>
 <d8448365-2c21-8670-3542-4798ac343e1c@openssl.org>
 <CANWFjKDNX9Q7ptk9ZmLM5364f0ejWhvStYb7dxsxT1TeO0XDog@mail.gmail.com>
 <b243ca23-bc91-7d95-c5eb-a891e44a0d86@openssl.org>
 <CANWFjKCjwA-NegusVngj9+_bQMz91xELEQ1r538FQJCfVHmRNw@mail.gmail.com>
 <9782b31f-9472-c476-c98e-802e906b9c48@openssl.org>
 <CANWFjKBCetikoMDx=hmnHvZT-Ufguw04cBmkbeAaU-Y-2sLGQA@mail.gmail.com>
 <727734e1-a450-9b53-41e7-630f953de3c8@akamai.com>
 <CANWFjKDDNGP6eEwha+AY-EyunWz24LNQ-Jx9c8EKk5X5Zz06wA@mail.gmail.com>
 <91195d2f-94ea-6916-59b5-735c5f98a4c9@openssl.org>
 <CANWFjKD_Qnm2HcvtB_wSD3yCEKOMvyuN8Pxjd=vwZ3Oyyefupg@mail.gmail.com>
 <8ecfa5ad-24da-4a08-3168-f0fb97899cfb@openssl.org>
 <CANWFjKAgGjHW3=+=cLBR34qv2Po8V6PgCx7jd2rK24RT7+_7vw@mail.gmail.com>
Message-ID: <CANWFjKBMcAvWRVevoFsPovEWNadh84Nv6sbGxqdE2qaqHY3Wzw@mail.gmail.com>

On Tue, Aug 1, 2017 at 10:46 AM, Neetish Pathak <npathak2 at ncsu.edu> wrote:

>
>
> On Mon, Jul 31, 2017 at 2:00 PM, Matt Caswell <matt at openssl.org> wrote:
>
>>
>>
>> On 31/07/17 20:37, Neetish Pathak wrote:
>> >     On 26/07/17 00:05, Neetish Pathak wrote:
>> >     >>     *Pseudocode for server*
>> >     >>     *
>> >     >>     *
>> >     >>     tcp_accept
>> >     >>     *
>> >     >>     *
>> >     >>     read_early{
>> >     >>
>> >     >>          if(read_early_success){
>> >     >>               write_early(data)
>> >     >>           }
>> >     >>     }
>> >
>> >     There is a bit of complexity here (covered in the docs), i.e.
>> >     SSL_read_early_data() may return SSL_READ_EARLY_DATA_SUCCESS or
>> >     SSL_READ_EARLY_DATA_FINISH. In the latter case this is still a
>> success,
>> >     but the server may or may not be able to write early data. I assume
>> that
>> >     you have covered that in your actual code and it's just skimmed over
>> >     here in your pseudo code.
>> >
>> >
>> >
>> > So, I consider read_early_sucess when  SSL_read_early_data() returns
>> > SSL_READ_EARLY_DATA_FINISH. Also, I check that early data was accepted
>> > before declaring success. Look at the case checks below
>> >
>> > *case* SSL_READ_EARLY_DATA_SUCCESS:
>> >
>> >         totalBytes += readBytes;
>> >
>> > *         break*;
>> >
>> > *
>> > *
>> >
>> > *case* SSL_READ_EARLY_DATA_FINISH:
>> >
>> >        totalBytes += readBytes;
>> >
>> > *       if* (SSL_EARLY_DATA_ACCEPTED ==
>> > SSL_get_early_data_status(*this*->conn) && totalBytes > 0) {
>> >
>> >              readBuf = string(readBuffer);
>> >
>> > *             return* SUCCESS;
>> >
>> >       }
>> >
>> >
>> > So, are you suggesting that early data may not be written from the
>> > server side if SSL_READ_EARLY_DATA_FINISH is received. Should I try
>> > writing before that (as in when SSL_READ_EARLY_DATA_SUCCESS is received
>> )
>>
>>
>> SSL_READ_EARLY_DATA_FINISH is not returned until we have seen the
>> EndOfEarlyData message. Often (but not always - dependent on the
>> implementation) the client Finished message is also in the same packet
>> which OpenSSL will immediately try and process. As soon as it has done
>> so the handshake is complete and it is too late for the server to write
>> early data. Calls to SSL_write_early_data() by the server at this point
>> should fail (do you not see this???).
>>
>> You should write early data on the server side as soon as
>> SSL_READ_EARLY_DATA_SUCCESS is received.
>>
>
>
> Yes, this is what I tried and it worked. Thanks for the clarification.
> Also, this point is not very clear from the man page on when the write
> early data be sent from the server side (after SUCCESS or FINISH). Can it
> be included?
>
>>
>>
>>
>> >     > No.     Time           Source                Destination
>> >     > Protocol Length Info
>> >     >     215 18.381122      ::1                   ::1
>> >     > TLSv1.3  762    Application Data
>> >     > Transmission Control Protocol, Src Port: 12345, Dst Port: 56806,
>> Seq:
>> >     > 144, Ack: 3738, Len: 686   -----I don't know why this application
>> data
>> >     > is sent from server. My guess is this is session info
>> >
>> >     It could be the NewSessionTicket message going from the server to
>> the
>> >     client. But if so that is a little strange. The NST message is only
>> sent
>> >     after the handshake is complete (so no more early data is
>> possible). At
>> >     this point SSL_read_early_data() should have returned
>> >     SSL_READ_EARLY_DATA_SUCCESS, SSL_is_init_finished() will return
>> true,
>> >     and any calls to SSL_write_early_data() will fail.
>> >
>> >
>> > Yes, here the handshake is completed. Will the new session ticket be
>> > sent each time after the handshake? In theTLS 1.3 draft, it is mentioned
>> > that new session tickets may be sent after server receives Finished from
>> > the client and it creates a unique association between the ticket value
>> > and a secret PSK derived from the resumption master secret.
>> > But looks like, I am receiving new session ticket every-time. So, as per
>> > the implementation, new session ticket is a must I guess. Am I right?
>> > When will I not receive new session ticket in TLS 1.3?
>>
>> The OpenSSL implementation *always* sends a NewSessionTicket message
>> immediately after the handshake is complete. This is not required, but
>> is allowed by the spec. Currently there is no way to disable this
>> behaviour. Do you need/want it (if so, why)?
>>
>
> No, I do not need to disable it per se. The handshake completion at the
> client side is independent of the newsession ticket coming from the server
> side if I am correct. So the handshake operation (specifically SSL_connect)
> will return even if new session ticket has not arrived from the server. I
> was asking why new session ticket is needed during the resumption
> handshake. Isn't it just an overhead?
>
>
>>
>> >
>> > Also, I believe it is different than how new session ticket works in TLS
>> > 1.2 where it was sent only once to share the encrypted ticket from the
>> > server side when the client indicates support for session tickets.
>>
>> Yes, TLSv1.2 session tickets share the same name and have a similar
>> purpose, but are otherwise *completely* different to TLSv1.3 session
>> tickets.
>>
>
> Understood
>
>>
>>
>> >     >
>> >     > No.     Time           Source                Destination
>> >     > Protocol Length Info
>> >     >     217 18.381210      ::1                   ::1
>> >     > TLSv1.3  9917   Application Data          ----------*Intended
>> >     > Application Data that was intended to be early data *
>> >     > Transmission Control Protocol, Src Port: 12345, Dst Port: 56806,
>> Seq:
>> >     > 830, Ack: 3738, Len: 9841
>> >     >
>> >     > No.     Time           Source                Destination
>> >     > Protocol Length Info
>> >     >     219 18.381308      ::1                   ::1
>> >     > TLSv1.3  100    Application Data .
>>  ---------Application Data
>> >     > from client (I also see this application data sent everytime, not
>> sure why)
>> >     > Transmission Control Protocol, Src Port: 56806, Dst Port: 12345,
>> Seq:
>> >     > 3738, Ack: 10671, Len: 24
>> >     >
>> >     >
>> >     > No.     Time           Source                Destination
>> >     > Protocol Length Info
>> >     >     220 18.381309      ::1                   ::1
>> >     > TLSv1.3  100    Application Data .  ---------Application Data from
>> >     > server (I also see this application data sent everytime, not sure
>> why)
>> >
>> >     Perhaps these are close_notify alerts? Are you shutting down the
>> >     connection cleanly at this point?
>> >
>> >
>> > I am shutting down the connection from the client side. Server is up all
>> > the time for any new connection.
>>
>> As soon as you call SSL_shutdown() then a close_notify alert is sent.
>> Typically you do that on both the client and the server sides which
>> seems to match your wireshark trace.
>>
>
> OK Thanks
>
>>
>> Matt
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170801/4224e7ce/attachment-0001.html>

From noloader at gmail.com  Wed Aug  2 02:21:08 2017
From: noloader at gmail.com (Jeffrey Walton)
Date: Tue, 1 Aug 2017 22:21:08 -0400
Subject: [openssl-users] How to get a bye or word from BIGNUM in OpenSSL 1.1?
Message-ID: <CAH8yC8=5NRx3uxX=K6CBmEwGB6fV4KMt9Dm8TDbLk9EFQocFcA@mail.gmail.com>

I'm trying to extract the low-order byte or word from a BIGNUM in
OpenSSL 1.1. We were told to use BN_bn2binpad, but its not clear to me
how to specify the location we want to extract.

For example:

    const char v[] = "ffeeddccbbaa99887766554433221100";
    BIGNUM n = BN_new();

    if (BN_hex2bn(&n, v))
    {
        fprintf(stderr, "failed to parse BIGNUM\n");
        exit (1);
    }

I don't see how to get the low-order word 33221100, or the second to
last byte 11.

Here' the documentation but I don't see how to do it:
https://www.openssl.org/docs/man1.1.0/crypto/BN_bn2binpad.html. Other
libraries, like Java, Botan and Crypto++ allow us to specify a potion
to extract from in cases like these.

How do we extract bytes or words from a BIGNUM?

Thanks in advance.

From jb-openssl at wisemo.com  Wed Aug  2 04:38:53 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 2 Aug 2017 06:38:53 +0200
Subject: [openssl-users] How to get a bye or word from BIGNUM in OpenSSL
 1.1?
In-Reply-To: <CAH8yC8=5NRx3uxX=K6CBmEwGB6fV4KMt9Dm8TDbLk9EFQocFcA@mail.gmail.com>
References: <CAH8yC8=5NRx3uxX=K6CBmEwGB6fV4KMt9Dm8TDbLk9EFQocFcA@mail.gmail.com>
Message-ID: <bc7d7138-e5ae-af0b-71b0-dc640c163d41@wisemo.com>

On 02/08/2017 04:21, Jeffrey Walton wrote:
> I'm trying to extract the low-order byte or word from a BIGNUM in
> OpenSSL 1.1. We were told to use BN_bn2binpad, but its not clear to me
> how to specify the location we want to extract.
>
> For example:
>
>      const char v[] = "ffeeddccbbaa99887766554433221100";
>      BIGNUM n = BN_new();
>
>      if (BN_hex2bn(&n, v))
>      {
>          fprintf(stderr, "failed to parse BIGNUM\n");
>          exit (1);
>      }
>
> I don't see how to get the low-order word 33221100, or the second to
> last byte 11.
>
> Here' the documentation but I don't see how to do it:
> https://www.openssl.org/docs/man1.1.0/crypto/BN_bn2binpad.html. Other
> libraries, like Java, Botan and Crypto++ allow us to specify a potion
> to extract from in cases like these.
>
> How do we extract bytes or words from a BIGNUM?
>
> Thanks in advance.
BN_bn2binpad (and it's friends) always give you *all* the bytes
in the number in a buffer of you own.  You can then extract the
bytes from there.

If you care mostly about the least significant bytes, using
BN_bn2lebinpad may be easier than BN_bn2binpad, as the least
significant bytes will be first, not last, in the result.

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 adamtg at devitron.com  Tue Aug  1 17:57:38 2017
From: adamtg at devitron.com (Adam Grossman)
Date: Tue, 1 Aug 2017 13:57:38 -0400
Subject: [openssl-users] Renegotiation with Client Certs failure
Message-ID: <b30b4ad5-27b5-acd2-8a0c-68a98c57f5ed@devitron.com>

Hello,

I inherited the code for web-server like server that i need to 
maintain.  It is setup that when you request a certain URL, the server 
will renegotiate and request a client certificate.  They said it worked 
when they use OpenSSL 0.9.8, but we are seeing issues with 1.0.2l.  When 
it does the renegotiation, the second SSL_handshake fails with 
"SSL_ERROR_SYSCALL" and ERR_get_error() returns 0.  But if i reload the 
page, it gets the client certificate and everything works and every 
subsequent request for that URL works.  But if i clear the cache and 
connect again, i get the same error.

Any help or pointers on how to further debug this would be greatly 
appreciated.

This is the relevant code:

SSL_set_verify(ssl, SSL_VERIFY_PEER |SSL_VERIFY_FAIL_IF_NO_PEER_CERT, 
verify_callback);
ssl_data->reneg_state = RENEG_ALLOW;
r=SSL_renegotiate(ssl);

if (r<=0)
     { // return error }

r=SSL_do_handshake(ssl);
if (r<=0)
     { // return error }

ssl->state=SSL_ST_ACCEPT;
do {
     ERR_clear_error();
     r=SSL_do_handshake(ssl);  // this is where it fails
     if (r<=0) {
         e=SSL_get_error(ssl,r);
         int errR = ERR_get_error();
         // printf("Error Level 1: e=%d r=%d errR=%d 
errno=%d\n",e,r,errR, errno);
     }
}
while ((r !=1)  &&  ((e == SSL_ERROR_WANT_READ) || (e == 
SSL_ERROR_WANT_WRITE)));


thank you very much,

adamtg



From noloader at gmail.com  Wed Aug  2 07:47:14 2017
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 2 Aug 2017 03:47:14 -0400
Subject: [openssl-users] How to get a bye or word from BIGNUM in OpenSSL
	1.1?
In-Reply-To: <bc7d7138-e5ae-af0b-71b0-dc640c163d41@wisemo.com>
References: <CAH8yC8=5NRx3uxX=K6CBmEwGB6fV4KMt9Dm8TDbLk9EFQocFcA@mail.gmail.com>
 <bc7d7138-e5ae-af0b-71b0-dc640c163d41@wisemo.com>
Message-ID: <CAH8yC8m3psR8OqVQXxHUwPghWD99yNY9UfmFPhBM7RF=hqvSSQ@mail.gmail.com>

On Wed, Aug 2, 2017 at 12:38 AM, Jakob Bohm <jb-openssl at wisemo.com> wrote:
> On 02/08/2017 04:21, Jeffrey Walton wrote:
>>
>> I'm trying to extract the low-order byte or word from a BIGNUM in
>> OpenSSL 1.1. We were told to use BN_bn2binpad, but its not clear to me
>> how to specify the location we want to extract.
>>
>> For example:
>>
>>      const char v[] = "ffeeddccbbaa99887766554433221100";
>>      BIGNUM n = BN_new();
>>
>>      if (BN_hex2bn(&n, v))
>>      {
>>          fprintf(stderr, "failed to parse BIGNUM\n");
>>          exit (1);
>>      }
>>
>> I don't see how to get the low-order word 33221100, or the second to
>> last byte 11.
>>
>> Here' the documentation but I don't see how to do it:
>> https://www.openssl.org/docs/man1.1.0/crypto/BN_bn2binpad.html. Other
>> libraries, like Java, Botan and Crypto++ allow us to specify a potion
>> to extract from in cases like these.
>>
>> How do we extract bytes or words from a BIGNUM?
>>
>> Thanks in advance.
>
> BN_bn2binpad (and it's friends) always give you *all* the bytes
> in the number in a buffer of you own.  You can then extract the
> bytes from there.
>
> If you care mostly about the least significant bytes, using
> BN_bn2lebinpad may be easier than BN_bn2binpad, as the least
> significant bytes will be first, not last, in the result.

Thanks.

It would be nice if the OpenSSL devs ate their own dogfood and
suffered that inefficient crap. I would wager that crap would change.

Jeff

From jb-openssl at wisemo.com  Wed Aug  2 08:07:56 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 2 Aug 2017 10:07:56 +0200
Subject: [openssl-users] How to get a bye or word from BIGNUM in OpenSSL
 1.1?
In-Reply-To: <CAH8yC8m3psR8OqVQXxHUwPghWD99yNY9UfmFPhBM7RF=hqvSSQ@mail.gmail.com>
References: <CAH8yC8=5NRx3uxX=K6CBmEwGB6fV4KMt9Dm8TDbLk9EFQocFcA@mail.gmail.com>
 <bc7d7138-e5ae-af0b-71b0-dc640c163d41@wisemo.com>
 <CAH8yC8m3psR8OqVQXxHUwPghWD99yNY9UfmFPhBM7RF=hqvSSQ@mail.gmail.com>
Message-ID: <02bbb85d-ff56-b275-37b5-7ea223d14b9c@wisemo.com>

On 02/08/2017 09:47, Jeffrey Walton wrote:
> On Wed, Aug 2, 2017 at 12:38 AM, Jakob Bohm <jb-openssl at wisemo.com> wrote:
>> On 02/08/2017 04:21, Jeffrey Walton wrote:
>>> I'm trying to extract the low-order byte or word from a BIGNUM in
>>> OpenSSL 1.1. We were told to use BN_bn2binpad, but its not clear to me
>>> how to specify the location we want to extract.
>>>
>>> For example:
>>>
>>>       const char v[] = "ffeeddccbbaa99887766554433221100";
>>>       BIGNUM n = BN_new();
>>>
>>>       if (BN_hex2bn(&n, v))
>>>       {
>>>           fprintf(stderr, "failed to parse BIGNUM\n");
>>>           exit (1);
>>>       }
>>>
>>> I don't see how to get the low-order word 33221100, or the second to
>>> last byte 11.
>>>
>>> Here' the documentation but I don't see how to do it:
>>> https://www.openssl.org/docs/man1.1.0/crypto/BN_bn2binpad.html. Other
>>> libraries, like Java, Botan and Crypto++ allow us to specify a potion
>>> to extract from in cases like these.
>>>
>>> How do we extract bytes or words from a BIGNUM?
>>>
>>> Thanks in advance.
>> BN_bn2binpad (and it's friends) always give you *all* the bytes
>> in the number in a buffer of you own.  You can then extract the
>> bytes from there.
>>
>> If you care mostly about the least significant bytes, using
>> BN_bn2lebinpad may be easier than BN_bn2binpad, as the least
>> significant bytes will be first, not last, in the result.
> Thanks.
>
> It would be nice if the OpenSSL devs ate their own dogfood and
> suffered that inefficient crap. I would wager that crap would change.
>
> Jeff
Reading single bytes out of a bignum is a very rare operation
(except as part of some mathematical operation that should be
part of the bignum library).

Converting an entire bignum to/from a simple "large" int-like
variable for inclusion in various protocols and data formats is
a common operation which these functions provide.

Are you sure you are not trying to do something already provided
more directly via your "read a byte" operation?

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 rsalz at akamai.com  Wed Aug  2 12:09:43 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 2 Aug 2017 12:09:43 +0000
Subject: [openssl-users] How to get a bye or word from BIGNUM in
	OpenSSL	1.1?
In-Reply-To: <CAH8yC8m3psR8OqVQXxHUwPghWD99yNY9UfmFPhBM7RF=hqvSSQ@mail.gmail.com>
References: <CAH8yC8=5NRx3uxX=K6CBmEwGB6fV4KMt9Dm8TDbLk9EFQocFcA@mail.gmail.com>
 <bc7d7138-e5ae-af0b-71b0-dc640c163d41@wisemo.com>
 <CAH8yC8m3psR8OqVQXxHUwPghWD99yNY9UfmFPhBM7RF=hqvSSQ@mail.gmail.com>
Message-ID: <63a3bdcdf1d44c30907ca1a64322381b@usma1ex-dag1mb1.msg.corp.akamai.com>

> It would be nice if the OpenSSL devs ate their own dogfood and suffered
> that inefficient crap. I would wager that crap would change.

There is a price to be paid with opaque structures.  In most cases the benefits are worth it.

I'm curious why you want that.  A small PR with doc and function should be easy enough.  Are you using BN as an extensible byte array?

From rsalz at akamai.com  Wed Aug  2 12:41:21 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 2 Aug 2017 12:41:21 +0000
Subject: [openssl-users] Code health tuesday is back!
Message-ID: <3c01f8ac264a4e68b2793607c84208ae@usma1ex-dag1mb1.msg.corp.akamai.com>

After a short summer vacation, our biweekly code health Tuesday is back!

Our topic this time is ... documentation.

There have been many updates to the manpages in the past few weeks, typo fixes, additional clarifications, and so on.  We hope that folks will be emboldened to help fill in the gaps, but any PR to make things better will help.

Please submit your fixes by Tuesday; if you can't add a label, put 'code health' somewhere in the commit message.  Please have a CLA onfile; if your commit is trivial and not copyrightable, put "CLA: trivial" in the commit message.  If you have a whole bunch of trivial fixes, put them in one PR (separate commits if you want).  Make sure any changes pass find-doc-nits (a script in util).  You can also use that script to list places where documentation is missing:

; ./util/find-doc-nits -u | fgrep '#'
# Found 4373 in util/libcrypto.num
# Found 1724 missing from util/libcrypto.num
# Found 464 in util/libssl.num
# Found 64 missing from util/libssl.num
# Checking macros (approximate)
# Found 246 macros missing (not all should be documnted)

Thanks for all your help in improving OpenSSL!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170802/e064a2c4/attachment-0001.html>

From michele.mase at gmail.com  Wed Aug  2 21:22:34 2017
From: michele.mase at gmail.com (Michele Mase')
Date: Wed, 2 Aug 2017 23:22:34 +0200
Subject: [openssl-users] private key difference: openssl genrsa vs
 opnessl req newkey
In-Reply-To: <20170801165500.GK8146@mournblade.imrryr.org>
References: <CAC=HuntL4nCvOKNFNCKErub-Z9Ga0wEh03ygwicnETwbhDbeiw@mail.gmail.com>
 <20170801165500.GK8146@mournblade.imrryr.org>
Message-ID: <CAC=HunvGa8j3k5uK_9dmD6bcmjijAoAGrtR+bs0gZLX8Pn1m+A@mail.gmail.com>

tx for the support. I will try a solution with the problematic software.
Best regards
Michele MAs?

On Tue, Aug 1, 2017 at 6:55 PM, Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Wed, Jul 26, 2017 at 09:21:43PM +0200, Michele Mase' wrote:
>
> > So, what should be the command line to use in order to obtain the same
> key?
> > openssl genrsa ....
>
> This creates keys in a legacy RSA algorithm-specific format.
>
> > openssl req -nodes -newkey rsa:2048 some_extra_parameters ....
>
> This creates keys in the preferred standard PKCS#8 format.
>
> You can use "openssl pkey" to read legacy RSA keys and output
> PKCS#8 keys.  Or you can use "openssl genpkey" to generate
> PKCS#8 keys directly:
>
>     # RSA
>     (umask 077; openssl genpkey -algorithm rsa -pkeyopt
> rsa_keygen_bits:2048 -out key.pem)
>
>     # ECDSA P-256
>     (umask 077; openssl genpkey -algorithm ec -pkeyopt
> ec_paramgen_curve:prime256v1 -pkeyopt ec_param_enc:named_curve -out key.pem)
>
>     # ECDSA P-384
>     (umask 077; openssl genpkey -algorithm ec -pkeyopt
> ec_paramgen_curve:secp384r1 -pkeyopt ec_param_enc:named_curve -out key.pem)
>
>     # ECDSA P-521
>     (umask 077; openssl genpkey -algorithm ec -pkeyopt
> ec_paramgen_curve:secp521r1 -pkeyopt ec_param_enc:named_curve -out key.pem)
>
> It is unfortunate that OpenSSL 1.0.2 does not accept curve name
> aliases for ec_paramgen_curve.  Thus, for example, only "prime256v1"
> is accepted for P-256 and not any of its other names.
>
> I've not checked whether this is fixed in OpenSSL 1.1.0.
>
> --
>         Viktor.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170802/a755302d/attachment.html>

From tom.browder at gmail.com  Sat Aug  5 22:08:44 2017
From: tom.browder at gmail.com (Tom Browder)
Date: Sat, 05 Aug 2017 22:08:44 +0000
Subject: [openssl-users] OpenSSl functions ("apps"): Is arg order
	significant?
Message-ID: <CAFMGiz9G=--xoDNig7zTFN5yfrdpVKXntN2HKX4kNN7M1ahqtQ@mail.gmail.com>

Looking at the man page for dsa it doesn't seem that the order of arguments
is critical as long, of course, as each arg that takes a value has an
approriate entry.

If that is true for dsa, is it true for similar functions such as rsa,
x509, etc.?

Thanks.

Best regards,

-Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170805/36e6c69e/attachment.html>

From rsalz at akamai.com  Sun Aug  6 20:55:50 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 6 Aug 2017 20:55:50 +0000
Subject: [openssl-users] OpenSSl functions ("apps"): Is arg
	order	significant?
In-Reply-To: <CAFMGiz9G=--xoDNig7zTFN5yfrdpVKXntN2HKX4kNN7M1ahqtQ@mail.gmail.com>
References: <CAFMGiz9G=--xoDNig7zTFN5yfrdpVKXntN2HKX4kNN7M1ahqtQ@mail.gmail.com>
Message-ID: <2da6294a8456450abecc2e4432538a60@usma1ex-dag1mb1.msg.corp.akamai.com>

> Looking at the man page for dsa it doesn't seem that the order of arguments is critical as long, of course, as each arg that takes a value has an approriate entry.

You mean flags and values, like "-foo" and "-bar asdf" ?  Yes, the order of flags does not matter, except in some special cases that are (hopefully) noted in the docs.


From tom.browder at gmail.com  Sun Aug  6 22:34:48 2017
From: tom.browder at gmail.com (Tom Browder)
Date: Sun, 06 Aug 2017 22:34:48 +0000
Subject: [openssl-users] OpenSSl functions ("apps"): Is arg order
	significant?
In-Reply-To: <2da6294a8456450abecc2e4432538a60@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CAFMGiz9G=--xoDNig7zTFN5yfrdpVKXntN2HKX4kNN7M1ahqtQ@mail.gmail.com>
 <2da6294a8456450abecc2e4432538a60@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CAFMGiz81=ZBYvyUSG_kOb6UNAOm5ipSgvi2-t4MkwZ0W9nBvhg@mail.gmail.com>

On Sun, Aug 6, 2017 at 16:56 Salz, Rich via openssl-users <
openssl-users at openssl.org> wrote:

> > Looking at the man page for dsa it doesn't seem that the order of
> arguments is critical

...

> You mean flags and values, like "-foo" and "-bar asdf" ?  Yes, the order
> of flags does not matter, except in some special cases that are (hopefully)
> noted in the docs.


Thanks, Rich!

Best regards.

-Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170806/30520097/attachment.html>

From rsalz at akamai.com  Mon Aug  7 12:36:58 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 7 Aug 2017 12:36:58 +0000
Subject: [openssl-users] FW: Code health tuesday is back!
In-Reply-To: <3c01f8ac264a4e68b2793607c84208ae@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <3c01f8ac264a4e68b2793607c84208ae@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <2bb4a3d76ad44a61903e11a17f9a64bf@usma1ex-dag1mb1.msg.corp.akamai.com>

A reminder: After a short summer vacation, our biweekly code health Tuesday is back!

Our topic this time is ? documentation.

There have been many updates to the manpages in the past few weeks, typo fixes, additional clarifications, and so on.? We hope that folks will be emboldened to help fill in the gaps, but any PR to make things better will help.

Please submit your fixes by Tuesday; if you can?t add a label, put ?code health? somewhere in the commit message.? Please have a CLA on file; if your commit is trivial and not copyrightable, put ?CLA: trivial? in the commit message.? If you have a whole bunch of trivial fixes, put them in one PR (separate commits if you want).? Make sure any changes pass find-doc-nits (a script in util).? You can also use that script to list places where documentation is missing:

       ; ./util/find-doc-nits -u | fgrep '#'
       # Found 4373 in util/libcrypto.num
       # Found 1724 missing from util/libcrypto.num
       # Found 464 in util/libssl.num
       # Found 64 missing from util/libssl.num
       # Checking macros (approximate)
       # Found 246 macros missing (not all should be documnted) 

Thanks for all your help in improving OpenSSL!


From daniel.andrade at tecnico.ulisboa.pt  Mon Aug  7 19:08:07 2017
From: daniel.andrade at tecnico.ulisboa.pt (Daniel Andrade)
Date: Mon, 7 Aug 2017 20:08:07 +0100
Subject: [openssl-users] Fixed-size digest using EVP with algos ECDSA+SHA256
Message-ID: <14e63164-674d-b7c3-a33f-d3a5e25c7aa8@tecnico.ulisboa.pt>

Hi all,

I'm writing functions to create a digest of a data buffer using 
ECDSA+SHA256. I've been trying to work with only the high-level EVP 
interface, and not use the low-level interfaces.

My understanding is that the resulting digest is an ASN.1 structure. I 
have to feed this digest to the Intel SGX runtime, which requires a 
fixed-size input (they actually have two separates arrays, one for X and 
one for Y, each with 32-byte length).

Is it possible to get a fixed-sized digest using ECDSA/SHA256, I mean 
does OpenSSL have functions for this? Or could someone give me some 
pointers on how to proceed to convert that result to the 64-byte fixed size?

Daniel

From rgm at htt-consult.com  Tue Aug  8 15:12:52 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Tue, 8 Aug 2017 11:12:52 -0400
Subject: [openssl-users] EDDSA certificates
In-Reply-To: <3da85680-edb0-cef5-d6e7-b8f02754d824@akamai.com>
References: <b3bd575f-c65a-25c8-52e2-5601f2ccf75e@htt-consult.com>
 <275dad3d0ada432d9c7b2b5f30db2b8f@usma1ex-dag1mb1.msg.corp.akamai.com>
 <eb949b6e-b5b6-15eb-444e-68d3ccf13590@htt-consult.com>
 <3da85680-edb0-cef5-d6e7-b8f02754d824@akamai.com>
Message-ID: <738e7e29-1c07-3aeb-8003-6f5a82ba4e88@htt-consult.com>

I have read:  https://github.com/openssl/openssl/issues/487

And I am trying to grok its meaning.  I am running Fedora24 (I need to 
buy an new SSD before upgrading to F26) which has openssl 1.0.2k.

There is a note of a patch to 1.0.2j, but talk about 1.1.1.  I have 
attempted to read

https://gist.github.com/ladar/e45e893901f30f480dd49265ba3c42c0

Is there a command line option for creating an ed25519 cert and if so 
what version?  I tried:

openssl req -new -outform PEM -out certs/$commonName.crt -newkey ed25519 
-nodes -keyout private/$commonName.key -keyform PEM -days 3650 -x509 
-extensions v3_req -subj 
"/countryName=$countryName/stateOrProvinceName=$stateOrProvinceName/localityName=$localityName/organizationName=$organizationName/organizationalUnitName=$organizationalUnitName/commonName=$commonName/emailAddress=$emailAddress"

And got:

Unknown algorithm ed25519

thanks.

On 07/27/2017 10:45 AM, Benjamin Kaduk wrote:
> On 07/27/2017 09:18 AM, Robert Moskowitz wrote:
>> Rich,
>>
>> Meant to ask you about this at IETF.
>>
>> Given draft-ietf-curdle-pkix-05.txt sec 10, is there openssl code to 
>> produce these???
>>
>
> There is code to validate them, per commit 
> 4328dd41582bcdca8e4f51f0a3abadfafa2163ee.  I didn't look hard enough 
> to find how to generate them, but it ought to be there too.
>
>> And, relatedly, what do you think about CBOR encoding rather than 
>> ASN.1?  Kill ASN.1 in constrained devices and save on transmission 
>> costs?
>
> It seems hard to shift a big ecosystem and introduce risk of 
> incompatibility, but I haven't really thought about it.
>
> -Ben


From rsalz at akamai.com  Tue Aug  8 15:19:50 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 8 Aug 2017 15:19:50 +0000
Subject: [openssl-users] EDDSA certificates
In-Reply-To: <738e7e29-1c07-3aeb-8003-6f5a82ba4e88@htt-consult.com>
References: <b3bd575f-c65a-25c8-52e2-5601f2ccf75e@htt-consult.com>
 <275dad3d0ada432d9c7b2b5f30db2b8f@usma1ex-dag1mb1.msg.corp.akamai.com>
 <eb949b6e-b5b6-15eb-444e-68d3ccf13590@htt-consult.com>
 <3da85680-edb0-cef5-d6e7-b8f02754d824@akamai.com>
 <738e7e29-1c07-3aeb-8003-6f5a82ba4e88@htt-consult.com>
Message-ID: <48596dd667d94c33bf6c371842cc8db6@usma1ex-dag1mb1.msg.corp.akamai.com>

We don't add features to released versions, just bug-fixes.  Ladar has posted a patch for 1.0.2 for those do-it-yourselfers who are so inclined.

The 'master' branch, which will become 1.1.1 at some point, can do it:
; sh /tmp/x
Generating a 2048 bit ED25519 private key
writing new private key to '/tmp/key.key'
-----
; cat /tmp/x
./apps/openssl req -new -outform PEM -out /tmp/cert.crt -newkey \
 ed25519 -nodes -keyout /tmp/key.key -keyform PEM -days \
 3650 -x509 -extensions v3_req -subj \
 "/C=us/O=organizationName/CN=common-name"


From rgm at htt-consult.com  Tue Aug  8 15:25:57 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Tue, 8 Aug 2017 11:25:57 -0400
Subject: [openssl-users] EDDSA certificates
In-Reply-To: <48596dd667d94c33bf6c371842cc8db6@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <b3bd575f-c65a-25c8-52e2-5601f2ccf75e@htt-consult.com>
 <275dad3d0ada432d9c7b2b5f30db2b8f@usma1ex-dag1mb1.msg.corp.akamai.com>
 <eb949b6e-b5b6-15eb-444e-68d3ccf13590@htt-consult.com>
 <3da85680-edb0-cef5-d6e7-b8f02754d824@akamai.com>
 <738e7e29-1c07-3aeb-8003-6f5a82ba4e88@htt-consult.com>
 <48596dd667d94c33bf6c371842cc8db6@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <1f65186a-c4ae-1c1f-bf12-94dc006e226f@htt-consult.com>

Ah,  thanks for the explanation Rich.

On 08/08/2017 11:19 AM, Salz, Rich via openssl-users wrote:
> We don't add features to released versions, just bug-fixes.  Ladar has posted a patch for 1.0.2 for those do-it-yourselfers who are so inclined.
>
> The 'master' branch, which will become 1.1.1 at some point, can do it:
> ; sh /tmp/x
> Generating a 2048 bit ED25519 private key

Wait, 2048 bit ED25519 key?????

> writing new private key to '/tmp/key.key'
> -----
> ; cat /tmp/x
> ./apps/openssl req -new -outform PEM -out /tmp/cert.crt -newkey \
>   ed25519 -nodes -keyout /tmp/key.key -keyform PEM -days \
>   3650 -x509 -extensions v3_req -subj \
>   "/C=us/O=organizationName/CN=common-name"
>
So I guess the question for me is will it make it into Fedora 27....

Bob


From rsalz at akamai.com  Tue Aug  8 15:28:33 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 8 Aug 2017 15:28:33 +0000
Subject: [openssl-users] EDDSA certificates
In-Reply-To: <1f65186a-c4ae-1c1f-bf12-94dc006e226f@htt-consult.com>
References: <b3bd575f-c65a-25c8-52e2-5601f2ccf75e@htt-consult.com>
 <275dad3d0ada432d9c7b2b5f30db2b8f@usma1ex-dag1mb1.msg.corp.akamai.com>
 <eb949b6e-b5b6-15eb-444e-68d3ccf13590@htt-consult.com>
 <3da85680-edb0-cef5-d6e7-b8f02754d824@akamai.com>
 <738e7e29-1c07-3aeb-8003-6f5a82ba4e88@htt-consult.com>
 <48596dd667d94c33bf6c371842cc8db6@usma1ex-dag1mb1.msg.corp.akamai.com>
 <1f65186a-c4ae-1c1f-bf12-94dc006e226f@htt-consult.com>
Message-ID: <a35149745f7f43a694ade9aea9a52e02@usma1ex-dag1mb1.msg.corp.akamai.com>

> > Generating a 2048 bit ED25519 private key
> 
> Wait, 2048 bit ED25519 key?????

Looks like a printf bug :)

From rgm at htt-consult.com  Wed Aug  9 13:24:34 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Wed, 9 Aug 2017 09:24:34 -0400
Subject: [openssl-users] Howto to create a PKI with Openssl command line
Message-ID: <e466fff8-b19a-2639-58ef-6c480aa5f62e@htt-consult.com>

I want to build a PKI structure of a root CA, intermediate CA(s), and 
user and server certs.  So I went looking for some guidance and found:

https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html

Anything else out there?

The certs will all be ECDSA, P256 SHA256.  Later I will fiddle with 
Ed25519...

I will be doing this on my Fedora24 notebook (at least for now) which 
has OpenSSL 1.0.2k

Thanks for all help.



From rsalz at akamai.com  Wed Aug  9 13:49:20 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 9 Aug 2017 13:49:20 +0000
Subject: [openssl-users] Howto to create a PKI with Openssl command line
In-Reply-To: <e466fff8-b19a-2639-58ef-6c480aa5f62e@htt-consult.com>
References: <e466fff8-b19a-2639-58ef-6c480aa5f62e@htt-consult.com>
Message-ID: <5c43f2fe332046f1ac43dc571cf28ed8@usma1ex-dag1mb1.msg.corp.akamai.com>

https://www.openssl.org/~rsalz/pki.tgz but only a root and end-entity.  Adding an intermediate should not be incredible difficult :)

From haris.phnx at gmail.com  Wed Aug  9 14:06:05 2017
From: haris.phnx at gmail.com (haris iqbal)
Date: Wed, 9 Aug 2017 19:36:05 +0530
Subject: [openssl-users] Fwd: Does TLSv1.2 support 3DES
In-Reply-To: <CAE_WKMyWS5x520DuqoLKZwm-cky7f2k7CLuY43SjF1cWKFixzg@mail.gmail.com>
References: <CAE_WKMyWS5x520DuqoLKZwm-cky7f2k7CLuY43SjF1cWKFixzg@mail.gmail.com>
Message-ID: <CAE_WKMzVA7pTz1xRQVUgkMc1_L2aKxCwaysn2d+pqCRj3sFXVg@mail.gmail.com>

Hi,

I wanted to know if I configure my openssl server to explicitly use
TLSv1.2, the do I have to also mention not to use 3DES (by adding
"!3DES" to the string), or the expicit use of TLSv1.2 remove the
support of 3DES.

>From [this][1] link I can see that TLS1.2 does not have 3DES in their
available cipher list. So I guess it does not support?

The string I am using is "HIGH+TLSv1.2:!MD5:!SHA1"


  [1]: https://www.openssl.org/docs/man1.0.2/apps/ciphers.html


--

With regards,

Md Haris Iqbal,
Contact: +91 8861996962

From rgm at htt-consult.com  Wed Aug  9 14:09:48 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Wed, 9 Aug 2017 10:09:48 -0400
Subject: [openssl-users] Howto to create a PKI with Openssl command line
In-Reply-To: <5c43f2fe332046f1ac43dc571cf28ed8@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <e466fff8-b19a-2639-58ef-6c480aa5f62e@htt-consult.com>
 <5c43f2fe332046f1ac43dc571cf28ed8@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <a4ba0add-9a29-2259-39a5-5ab0e78c0a00@htt-consult.com>

Thanks Rich, I will take a look at this also.

Bob

On 08/09/2017 09:49 AM, Salz, Rich via openssl-users wrote:
> https://www.openssl.org/~rsalz/pki.tgz but only a root and end-entity.  Adding an intermediate should not be incredible difficult :)


From rsalz at akamai.com  Wed Aug  9 16:07:30 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 9 Aug 2017 16:07:30 +0000
Subject: [openssl-users] Fwd: Does TLSv1.2 support 3DES
In-Reply-To: <CAE_WKMzVA7pTz1xRQVUgkMc1_L2aKxCwaysn2d+pqCRj3sFXVg@mail.gmail.com>
References: <CAE_WKMyWS5x520DuqoLKZwm-cky7f2k7CLuY43SjF1cWKFixzg@mail.gmail.com>
 <CAE_WKMzVA7pTz1xRQVUgkMc1_L2aKxCwaysn2d+pqCRj3sFXVg@mail.gmail.com>
Message-ID: <bedb101e832d4338a46a3c2cf36c1819@usma1ex-dag1mb1.msg.corp.akamai.com>

> From [this][1] link I can see that TLS1.2 does not have 3DES in their available
> cipher list. So I guess it does not support?

Right:

; ./apps/openssl ciphers -v HIGH+TLSv1.2:!MD5:!SHA1 | grep DES
; ./apps/openssl ciphers -v TLSv1.2:!MD5:!SHA1 | grep DES
; ./apps/openssl ciphers -v TLSv1.2 | grep DES

From openssl-users at dukhovni.org  Wed Aug  9 18:15:01 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 9 Aug 2017 18:15:01 +0000
Subject: [openssl-users] Fwd: Does TLSv1.2 support 3DES
In-Reply-To: <bedb101e832d4338a46a3c2cf36c1819@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CAE_WKMyWS5x520DuqoLKZwm-cky7f2k7CLuY43SjF1cWKFixzg@mail.gmail.com>
 <CAE_WKMzVA7pTz1xRQVUgkMc1_L2aKxCwaysn2d+pqCRj3sFXVg@mail.gmail.com>
 <bedb101e832d4338a46a3c2cf36c1819@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20170809181501.GT8146@mournblade.imrryr.org>

On Wed, Aug 09, 2017 at 04:07:30PM +0000, Salz, Rich via openssl-users wrote:

> > From [this][1] link I can see that TLS1.2 does not have 3DES in their available
> > cipher list. So I guess it does not support?
> 
> Right:
> 
> ; ./apps/openssl ciphers -v HIGH+TLSv1.2:!MD5:!SHA1 | grep DES
> ; ./apps/openssl ciphers -v TLSv1.2:!MD5:!SHA1 | grep DES
> ; ./apps/openssl ciphers -v TLSv1.2 | grep DES

This is wrong.  The "TLSv1.2" ciphers are just the ciphers that
are *new* in TLS 1.2.  A number of TLS 1.2 ciphers date back to
SSLv3.  The right way to see TLS 1.2 3DES ciphers is:

    $ openssl ciphers -s tls1_2 -V 3DES
          0xC0,0x12 - ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH     Au=RSA  Enc=3DES(168) Mac=SHA1
          0xC0,0x08 - ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH     Au=ECDSA Enc=3DES(168) Mac=SHA1
          0xC0,0x1C - SRP-DSS-3DES-EDE-CBC-SHA SSLv3 Kx=SRP      Au=DSS  Enc=3DES(168) Mac=SHA1
          0xC0,0x1B - SRP-RSA-3DES-EDE-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=3DES(168) Mac=SHA1
          0xC0,0x1A - SRP-3DES-EDE-CBC-SHA    SSLv3 Kx=SRP      Au=SRP  Enc=3DES(168) Mac=SHA1
          0x00,0x16 - EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
          0x00,0x13 - EDH-DSS-DES-CBC3-SHA    SSLv3 Kx=DH       Au=DSS  Enc=3DES(168) Mac=SHA1
          0x00,0x10 - DH-RSA-DES-CBC3-SHA     SSLv3 Kx=DH/RSA   Au=DH   Enc=3DES(168) Mac=SHA1
          0x00,0x0D - DH-DSS-DES-CBC3-SHA     SSLv3 Kx=DH/DSS   Au=DH   Enc=3DES(168) Mac=SHA1
          0xC0,0x17 - AECDH-DES-CBC3-SHA      SSLv3 Kx=ECDH     Au=None Enc=3DES(168) Mac=SHA1
          0x00,0x1B - ADH-DES-CBC3-SHA        SSLv3 Kx=DH       Au=None Enc=3DES(168) Mac=SHA1
          0xC0,0x0D - ECDH-RSA-DES-CBC3-SHA   SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
          0xC0,0x03 - ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1
          0x00,0x0A - DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1
          0x00,0x8B - PSK-3DES-EDE-CBC-SHA    SSLv3 Kx=PSK      Au=PSK  Enc=3DES(168) Mac=SHA1

See Appendix A.5 of RFC5246 for some of the above 3DES codepoints.
See also the IANA TLS ciphersuite registry.

-- 
	Viktor.

From haris.phnx at gmail.com  Wed Aug  9 19:08:49 2017
From: haris.phnx at gmail.com (haris iqbal)
Date: Thu, 10 Aug 2017 00:38:49 +0530
Subject: [openssl-users] Fwd: Does TLSv1.2 support 3DES
In-Reply-To: <20170809181501.GT8146@mournblade.imrryr.org>
References: <CAE_WKMyWS5x520DuqoLKZwm-cky7f2k7CLuY43SjF1cWKFixzg@mail.gmail.com>
 <CAE_WKMzVA7pTz1xRQVUgkMc1_L2aKxCwaysn2d+pqCRj3sFXVg@mail.gmail.com>
 <bedb101e832d4338a46a3c2cf36c1819@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20170809181501.GT8146@mournblade.imrryr.org>
Message-ID: <CAE_WKMxoHy5mVK+W1+FPxFfn7jEYvg+8QkFTtDhrSruhXYK6Vw@mail.gmail.com>

May be my email subject is a little confusing. I'll put my question directly.

If I configure my server with the string "HIGH+TLSv1.2:!MD5:!SHA1",
will it support 3DES?

On Wed, Aug 9, 2017 at 11:45 PM, Viktor Dukhovni
<openssl-users at dukhovni.org> wrote:
> On Wed, Aug 09, 2017 at 04:07:30PM +0000, Salz, Rich via openssl-users wrote:
>
>> > From [this][1] link I can see that TLS1.2 does not have 3DES in their available
>> > cipher list. So I guess it does not support?
>>
>> Right:
>>
>> ; ./apps/openssl ciphers -v HIGH+TLSv1.2:!MD5:!SHA1 | grep DES
>> ; ./apps/openssl ciphers -v TLSv1.2:!MD5:!SHA1 | grep DES
>> ; ./apps/openssl ciphers -v TLSv1.2 | grep DES
>
> This is wrong.  The "TLSv1.2" ciphers are just the ciphers that
> are *new* in TLS 1.2.  A number of TLS 1.2 ciphers date back to
> SSLv3.  The right way to see TLS 1.2 3DES ciphers is:
>
>     $ openssl ciphers -s tls1_2 -V 3DES
>           0xC0,0x12 - ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH     Au=RSA  Enc=3DES(168) Mac=SHA1
>           0xC0,0x08 - ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH     Au=ECDSA Enc=3DES(168) Mac=SHA1
>           0xC0,0x1C - SRP-DSS-3DES-EDE-CBC-SHA SSLv3 Kx=SRP      Au=DSS  Enc=3DES(168) Mac=SHA1
>           0xC0,0x1B - SRP-RSA-3DES-EDE-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=3DES(168) Mac=SHA1
>           0xC0,0x1A - SRP-3DES-EDE-CBC-SHA    SSLv3 Kx=SRP      Au=SRP  Enc=3DES(168) Mac=SHA1
>           0x00,0x16 - EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
>           0x00,0x13 - EDH-DSS-DES-CBC3-SHA    SSLv3 Kx=DH       Au=DSS  Enc=3DES(168) Mac=SHA1
>           0x00,0x10 - DH-RSA-DES-CBC3-SHA     SSLv3 Kx=DH/RSA   Au=DH   Enc=3DES(168) Mac=SHA1
>           0x00,0x0D - DH-DSS-DES-CBC3-SHA     SSLv3 Kx=DH/DSS   Au=DH   Enc=3DES(168) Mac=SHA1
>           0xC0,0x17 - AECDH-DES-CBC3-SHA      SSLv3 Kx=ECDH     Au=None Enc=3DES(168) Mac=SHA1
>           0x00,0x1B - ADH-DES-CBC3-SHA        SSLv3 Kx=DH       Au=None Enc=3DES(168) Mac=SHA1
>           0xC0,0x0D - ECDH-RSA-DES-CBC3-SHA   SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
>           0xC0,0x03 - ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1
>           0x00,0x0A - DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1
>           0x00,0x8B - PSK-3DES-EDE-CBC-SHA    SSLv3 Kx=PSK      Au=PSK  Enc=3DES(168) Mac=SHA1
>
> See Appendix A.5 of RFC5246 for some of the above 3DES codepoints.
> See also the IANA TLS ciphersuite registry.
>
> --
>         Viktor.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



-- 

With regards,

Md Haris Iqbal,
Contact: +91 8861996962

From rsalz at akamai.com  Wed Aug  9 19:11:40 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 9 Aug 2017 19:11:40 +0000
Subject: [openssl-users] Fwd: Does TLSv1.2 support 3DES
In-Reply-To: <CAE_WKMxoHy5mVK+W1+FPxFfn7jEYvg+8QkFTtDhrSruhXYK6Vw@mail.gmail.com>
References: <CAE_WKMyWS5x520DuqoLKZwm-cky7f2k7CLuY43SjF1cWKFixzg@mail.gmail.com>
 <CAE_WKMzVA7pTz1xRQVUgkMc1_L2aKxCwaysn2d+pqCRj3sFXVg@mail.gmail.com>
 <bedb101e832d4338a46a3c2cf36c1819@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20170809181501.GT8146@mournblade.imrryr.org>
 <CAE_WKMxoHy5mVK+W1+FPxFfn7jEYvg+8QkFTtDhrSruhXYK6Vw@mail.gmail.com>
Message-ID: <a2f323cce2ed492bbeb7fca94393792a@usma1ex-dag1mb1.msg.corp.akamai.com>

> May be my email subject is a little confusing. I'll put my question directly.
> 
> If I configure my server with the string "HIGH+TLSv1.2:!MD5:!SHA1", will it
> support 3DES?

No, as I showed.

From steve at openssl.org  Thu Aug 10 01:34:56 2017
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 10 Aug 2017 01:34:56 +0000
Subject: [openssl-users] Fixed-size digest using EVP with algos
 ECDSA+SHA256
In-Reply-To: <14e63164-674d-b7c3-a33f-d3a5e25c7aa8@tecnico.ulisboa.pt>
References: <14e63164-674d-b7c3-a33f-d3a5e25c7aa8@tecnico.ulisboa.pt>
Message-ID: <20170810013456.GA32208@openssl.org>

On Mon, Aug 07, 2017, Daniel Andrade wrote:

> Hi all,
> 
> I'm writing functions to create a digest of a data buffer using
> ECDSA+SHA256. I've been trying to work with only the high-level EVP
> interface, and not use the low-level interfaces.
> 
> My understanding is that the resulting digest is an ASN.1 structure.
> I have to feed this digest to the Intel SGX runtime, which requires
> a fixed-size input (they actually have two separates arrays, one for
> X and one for Y, each with 32-byte length).
> 
> Is it possible to get a fixed-sized digest using ECDSA/SHA256, I
> mean does OpenSSL have functions for this? Or could someone give me
> some pointers on how to proceed to convert that result to the
> 64-byte fixed size?
> 

The size will depend on the curve in use: presumably it's P-256 to produce
64 bytes.

In outline you do this:

1. Decode the signature into an ECDSA_SIG structure using d2i_ECDSA_SIG.
2. Extract the two BIGNUM elements, r and s using ECDSA_SIG_get0().
3. Generate padded encodings for r and s using BN_bn2binpad() or
BN_bn2lebinpad() depending on the format required (big or little endian).

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From openssl at knorrnet.de  Thu Aug 10 08:45:28 2017
From: openssl at knorrnet.de (openssl mailing list)
Date: Thu, 10 Aug 2017 10:45:28 +0200
Subject: [openssl-users] SMime encrypted mail - find out which key was used
Message-ID: <56cf1fcb-767d-15de-041e-04128f9f0dff@knorrnet.de>

Hi,

Is there a command line way to find out with which key an S/Mime
encrypted e-mail was encrypted, so that I can use the correct private
key for decryption?

In my case users can have - for internal reasons - more than one
public/private key pair, so using the e-mail address of the receiver
won't work

Thanks in advance

Horst

From amiya068 at gmail.com  Thu Aug 10 12:57:41 2017
From: amiya068 at gmail.com (Amiya Das)
Date: Thu, 10 Aug 2017 18:27:41 +0530
Subject: [openssl-users] Fwd: Error in Opening SSL Certificate
In-Reply-To: <CAJtg8Ci9ni+OgPree74XhqU28BzYApdpnRKLx90niiVGOBz5tg@mail.gmail.com>
References: <mailman.3946.1502367609.2118.openssl-users@openssl.org>
 <CAJtg8Ci9ni+OgPree74XhqU28BzYApdpnRKLx90niiVGOBz5tg@mail.gmail.com>
Message-ID: <CAJtg8CjruXcfw=17RCBDqhDUt+dis9LAVOn0P+XGujJy8EeXJA@mail.gmail.com>

Hi,

I have written an application for connecting to AzureIOT hub using AMQP
protocol.
When i run the application it fails because of SSL issue stating *14090086:SSL
routines:ssl3_get_server_certificate:certificate verify failed.*

Any help would be appreciate..
Below are the details for the OS
Yocto linux
Kernel 4.4.19-gdb0b54cdad

Info: IoT Hub SDK for C, version 1.1.19

i am not sure why this issue is appearing, it looks like an openssl issue.
But i do have the openssl certificates in the below location,
"/etc/ssl/certs/ca-certificates.crt"

Following are the more information using openssl,

-sh-3.2# openssl version -d
OPENSSLDIR: "/usr/lib/ssl"

But the actual certificates are located under /etc/ssl/ folder, so i copied
all the certificates under /usr/lib/ssl folder but still there was no luck
with this.
OPENSSL version 1.0.2h is currently installed.
CONNECTED(00000004)
depth=1 C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, OU
= Microsoft IT, CN = Microsoft IT SSL SHA2
verify error:num=20:unable to get local issuer certificate
---
Certificate chain
 0 s:/CN=*.azure-devices.net
   i:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft
IT/CN=Microsoft IT SSL SHA2
 1 s:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft
IT/CN=Microsoft IT SSL SHA2
   i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
---
Server certificate
-----BEGIN CERTIFICATE-----
Certificate displayed here properly

-----END CERTIFICATE-----
subject=/CN=*.azure-devices.net
issuer=/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft
IT/CN=Microsoft IT SSL SHA2
---
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SH
A256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SH
A256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1
Peer signing digest: SHA1
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3692 bytes and written 485 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-SHA256
    Session-ID: DA000000F6835606D8F94D7184BE980E23C55D49D08BA33A8A5709A2C476
3848
    Session-ID-ctx:
    Master-Key: EE1BEBA238F3B31AB83419452937BEB989E8A0BEB018E5D77B1148903BA3
5905D86DDF43F2745F593EE73AF0481F6819
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1502367353
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---

Thanks,
Amiya.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170810/ef6da38a/attachment-0001.html>

From jjsbear at hotmail.com  Wed Aug  9 13:08:47 2017
From: jjsbear at hotmail.com (- JinsongJi)
Date: Wed, 9 Aug 2017 13:08:47 +0000
Subject: [openssl-users] Does openssl pick low level interface or high level
 interface to do encrypt?
Message-ID: <HK2PR02MB1140493B7B834262404E98E0A88B0@HK2PR02MB1140.apcprd02.prod.outlook.com>

Hi,


For one simple operation: openssl enc -aes-256-cbc -salt -in foo.txt -out foo.enc
Does openssl pick classic implementation or AES-NI implementation to do this encrypt?

Does any user/application always pick classic implementation for AES operation regardless of AES-NI improves speed much?

Is there any document about this interface selection?

Thanks,
Jinsong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170809/477d4520/attachment.html>

From rsalz at akamai.com  Thu Aug 10 15:16:09 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 10 Aug 2017 15:16:09 +0000
Subject: [openssl-users] Does openssl pick low level interface or high
 level interface to do encrypt?
In-Reply-To: <HK2PR02MB1140493B7B834262404E98E0A88B0@HK2PR02MB1140.apcprd02.prod.outlook.com>
References: <HK2PR02MB1140493B7B834262404E98E0A88B0@HK2PR02MB1140.apcprd02.prod.outlook.com>
Message-ID: <6a3a16b885ba4ae6a45363af6ee0183c@usma1ex-dag1mb1.msg.corp.akamai.com>

What OpenSSL does is not necessarily obvious.  The INSTALL document talks about the no-asm configuration option.  Details about what the assembler code does in terms of optimization are only available by reading the source code comments in the various Perl files that generate the assembler, mostly.

On x86, the assembly code uses the CPUID instruction (see the OPENSSL_ia32cap.pod manpage) to determine if various instructions (AES, SSE, MMX, etc) are available and will use them if so.  For other processors, similar tests are performed if at all possible.

I have added this to the FAQ

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richsalz at jabber.at Twitter: RichSalz

From: - JinsongJi [mailto:jjsbear at hotmail.com]
Sent: Wednesday, August 09, 2017 9:09 AM
To: openssl-users at openssl.org
Subject: [openssl-users] Does openssl pick low level interface or high level interface to do encrypt?

Hi,


For one simple operation: openssl enc -aes-256-cbc -salt -in foo.txt -out foo.enc
Does openssl pick classic implementation or AES-NI implementation to do this encrypt?

Does any user/application always pick classic implementation for AES operation regardless of AES-NI improves speed much?

Is there any document about this interface selection?

Thanks,
Jinsong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170810/2513c555/attachment.html>

From rgm at htt-consult.com  Thu Aug 10 16:03:31 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 10 Aug 2017 12:03:31 -0400
Subject: [openssl-users] Password protect EC private key
Message-ID: <52b17a06-6e93-2a76-6b19-9f20dcd7af18@htt-consult.com>

I am following: 
https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html

But modifying it to produce ECDSA certs.  So the first step is to make 
the private key.  Jamie says:

openssl genrsa -aes256 -out private/ca.key.pem 4096

The -aes256 option supposedly password protects this private key. So 
after some googling I created:

openssl ecparam -name secp256k1 -genkey -noout -out private/ca.key.pem

But openssl ecparam does not have any option equivalent (that I can 
find) to -aes256

What am I missing.

And I successfully generated the root CA ECDSA cert with:

openssl req -config openssl.cnf -key private/ca.key.pem \
       -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
certs/ca.cert.pem

The config file is the one Jamie provides on his pages.

Also the following:

openssl ecparam -in private/ca.key.pem -text -noout

Gives me an error:

unable to load elliptic curve parameters
140598030526328:error:0906D06C:PEM routines:PEM_read_bio:no start 
line:pem_lib.c:707:Expecting: EC PARAMETERS

Is this because I created the private key without including the 
parameters?  I got my ECDSA tips from:

https://wiki.openssl.org/index.php/Command_Line_Elliptic_Curve_Operations

Meanwhile on to the sub-CA cert.

thanks

Bob


From openssl-users at dukhovni.org  Thu Aug 10 18:27:47 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 10 Aug 2017 18:27:47 +0000
Subject: [openssl-users] Password protect EC private key
In-Reply-To: <52b17a06-6e93-2a76-6b19-9f20dcd7af18@htt-consult.com>
References: <52b17a06-6e93-2a76-6b19-9f20dcd7af18@htt-consult.com>
Message-ID: <20170810182747.GY8146@mournblade.imrryr.org>

On Thu, Aug 10, 2017 at 12:03:31PM -0400, Robert Moskowitz wrote:

> openssl ecparam -name secp256k1 -genkey -noout -out private/ca.key.pem
> 
> But openssl ecparam does not have any option equivalent (that I can find) to -aes256

Yes, this command does not currently support key encryption.

> What am I missing.

The command that does is:

   $  openssl genpkey -aes256 -algorithm ec \
	-pkeyopt ec_paramgen_curve:secp256k1 \
	-pkeyopt ec_param_enc:named_curve \
	-out private/ca.key.pem

Are you sure you want secp256k1?  By far the more common choice is
prime256r1 (aka P-256 or secp256r1).

> openssl ecparam -in private/ca.key.pem -text -noout

EC keys are read with "openssl ec" not "openssl ecparam".

-- 
	Viktor.

From rgm at htt-consult.com  Thu Aug 10 18:49:02 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 10 Aug 2017 14:49:02 -0400
Subject: [openssl-users] Password protect EC private key
In-Reply-To: <20170810182747.GY8146@mournblade.imrryr.org>
References: <52b17a06-6e93-2a76-6b19-9f20dcd7af18@htt-consult.com>
 <20170810182747.GY8146@mournblade.imrryr.org>
Message-ID: <56f8c951-447a-eb57-c21a-061f0634fdbb@htt-consult.com>

Thank you, Viktor.

On 08/10/2017 02:27 PM, Viktor Dukhovni wrote:
> On Thu, Aug 10, 2017 at 12:03:31PM -0400, Robert Moskowitz wrote:
>
>> openssl ecparam -name secp256k1 -genkey -noout -out private/ca.key.pem
>>
>> But openssl ecparam does not have any option equivalent (that I can find) to -aes256
> Yes, this command does not currently support key encryption.
>
>> What am I missing.
> The command that does is:
>
>     $  openssl genpkey -aes256 -algorithm ec \
> 	-pkeyopt ec_paramgen_curve:secp256k1 \
> 	-pkeyopt ec_param_enc:named_curve \
> 	-out private/ca.key.pem

So I see that I use this for the CA(s) key generation, but what about a 
Server or Client key pair to feed into a CSR?  I probably do not want 
those keys encrypted (well I do, but we sacrifice protection for easy of 
use, sigh).


> Are you sure you want secp256k1?  By far the more common choice is
> prime256r1 (aka P-256 or secp256r1).

Thanks, I read things wrong and selected the wrong curve.  Yes, I want 
prime256r1.

>
>> openssl ecparam -in private/ca.key.pem -text -noout
> EC keys are read with "openssl ec" not "openssl ecparam".
>

Ah.  I will give this a try.

Bob


From openssl-users at dukhovni.org  Thu Aug 10 18:55:48 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 10 Aug 2017 18:55:48 +0000
Subject: [openssl-users] Fwd: Error in Opening SSL Certificate
In-Reply-To: <CAJtg8CjruXcfw=17RCBDqhDUt+dis9LAVOn0P+XGujJy8EeXJA@mail.gmail.com>
References: <mailman.3946.1502367609.2118.openssl-users@openssl.org>
 <CAJtg8Ci9ni+OgPree74XhqU28BzYApdpnRKLx90niiVGOBz5tg@mail.gmail.com>
 <CAJtg8CjruXcfw=17RCBDqhDUt+dis9LAVOn0P+XGujJy8EeXJA@mail.gmail.com>
Message-ID: <20170810185548.GA8146@mournblade.imrryr.org>

On Thu, Aug 10, 2017 at 06:27:41PM +0530, Amiya Das wrote:

> I have written an application for connecting to AzureIOT hub using AMQP
> protocol.
> When i run the application it fails because of SSL issue stating *14090086:SSL
> routines:ssl3_get_server_certificate:certificate verify failed.*

This means that the certificate chain presented does not chain up
to a locally trusted root CA, or is expired, or some other chain
verification problem.  You need to determine what certificates are
presented by the remote peer, what trust anchors (root CAs) you're
using and why the chain does not verify against these trust-anchors.

> Any help would be appreciate..
> Below are the details for the OS
> Yocto linux
> Kernel 4.4.19-gdb0b54cdad
> 
> Info: IoT Hub SDK for C, version 1.1.19

That's largely irrelevant.

> i am not sure why this issue is appearing, it looks like an openssl issue.
> But i do have the openssl certificates in the below location,
> "/etc/ssl/certs/ca-certificates.crt"

That's not where OpenSSL will look by default, unless:

> Following are the more information using openssl,
> 
> -sh-3.2# openssl version -d
> OPENSSLDIR: "/usr/lib/ssl"

OpenSSL will by default look in:

    <OPENSSLDIR>/certs.pem	- PEM file with multiple trusted certificates
    <OPENSSLDIR>/certs/		- Directory with certificate files "hashed" via c_rehash

Perhaps you have symlinks in place that lead to ca-certificates.crt,
or code to populate the /certs/ directory, but otherwise you'll
need such links, or the application will need to explicity set the
appropriate CAfile or CApath.

>     Verify return code: 20 (unable to get local issuer certificate)

Your CAfile/CApath do not contain a trust-anchor that verifies the
given chain.

-- 
	Viktor.

From openssl-users at dukhovni.org  Thu Aug 10 18:57:27 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 10 Aug 2017 18:57:27 +0000
Subject: [openssl-users] Password protect EC private key
In-Reply-To: <56f8c951-447a-eb57-c21a-061f0634fdbb@htt-consult.com>
References: <52b17a06-6e93-2a76-6b19-9f20dcd7af18@htt-consult.com>
 <20170810182747.GY8146@mournblade.imrryr.org>
 <56f8c951-447a-eb57-c21a-061f0634fdbb@htt-consult.com>
Message-ID: <20170810185727.GB8146@mournblade.imrryr.org>

On Thu, Aug 10, 2017 at 02:49:02PM -0400, Robert Moskowitz wrote:

> > The command that does is:
> > 
> >     $  openssl genpkey -aes256 -algorithm ec \
> > 	-pkeyopt ec_paramgen_curve:secp256k1 \
> > 	-pkeyopt ec_param_enc:named_curve \
> > 	-out private/ca.key.pem
> 
> So I see that I use this for the CA(s) key generation, but what about a
> Server or Client key pair to feed into a CSR?  I probably do not want those
> keys encrypted (well I do, but we sacrifice protection for easy of use,
> sigh).

Just leave off the "-aes256" option.

> > Are you sure you want secp256k1?  By far the more common choice is
> > prime256r1 (aka P-256 or secp256r1).
> 
> Thanks, I read things wrong and selected the wrong curve.  Yes, I want
> prime256r1.
> 
> > > openssl ecparam -in private/ca.key.pem -text -noout
> > EC keys are read with "openssl ec" not "openssl ecparam".
> 
> Ah.  I will give this a try.

Better yet, use "openssl pkey".

-- 
	Viktor.

From rgm at htt-consult.com  Thu Aug 10 19:17:02 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 10 Aug 2017 15:17:02 -0400
Subject: [openssl-users] Password protect EC private key
In-Reply-To: <20170810182747.GY8146@mournblade.imrryr.org>
References: <52b17a06-6e93-2a76-6b19-9f20dcd7af18@htt-consult.com>
 <20170810182747.GY8146@mournblade.imrryr.org>
Message-ID: <ce461722-8a89-eb6b-189b-d994a7ae4f6b@htt-consult.com>



On 08/10/2017 02:27 PM, Viktor Dukhovni wrote:
> On Thu, Aug 10, 2017 at 12:03:31PM -0400, Robert Moskowitz wrote:
>
>> openssl ecparam -name secp256k1 -genkey -noout -out private/ca.key.pem
>>
>> But openssl ecparam does not have any option equivalent (that I can find) to -aes256
> Yes, this command does not currently support key encryption.
>
>> What am I missing.
> The command that does is:
>
>     $  openssl genpkey -aes256 -algorithm ec \
> 	-pkeyopt ec_paramgen_curve:secp256k1 \
> 	-pkeyopt ec_param_enc:named_curve \
> 	-out private/ca.key.pem
>
> Are you sure you want secp256k1?  By far the more common choice is
> prime256r1 (aka P-256 or secp256r1).

Do you mean prime256v1?

$ openssl ecparam -list_curves
   secp256k1 : SECG curve over a 256 bit prime field
   secp384r1 : NIST/SECG curve over a 384 bit prime field
   secp521r1 : NIST/SECG curve over a 521 bit prime field
   prime256v1: X9.62/SECG curve over a 256 bit prime field


>
>> openssl ecparam -in private/ca.key.pem -text -noout
> EC keys are read with "openssl ec" not "openssl ecparam".
>


From openssl-users at dukhovni.org  Thu Aug 10 20:26:55 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 10 Aug 2017 20:26:55 +0000
Subject: [openssl-users] Password protect EC private key
In-Reply-To: <ce461722-8a89-eb6b-189b-d994a7ae4f6b@htt-consult.com>
References: <52b17a06-6e93-2a76-6b19-9f20dcd7af18@htt-consult.com>
 <20170810182747.GY8146@mournblade.imrryr.org>
 <ce461722-8a89-eb6b-189b-d994a7ae4f6b@htt-consult.com>
Message-ID: <20170810202655.GC8146@mournblade.imrryr.org>

On Thu, Aug 10, 2017 at 03:17:02PM -0400, Robert Moskowitz wrote:

> > Are you sure you want secp256k1?  By far the more common choice is
> > prime256r1 (aka P-256 or secp256r1).
> 
> Do you mean prime256v1?

Yes, it is the primary name in OpenSSL for secp256r1 aka (NIST) P-256.

-- 
	Viktor.

From rgm at htt-consult.com  Thu Aug 10 20:42:10 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 10 Aug 2017 16:42:10 -0400
Subject: [openssl-users] Password protect EC private key
In-Reply-To: <20170810202655.GC8146@mournblade.imrryr.org>
References: <52b17a06-6e93-2a76-6b19-9f20dcd7af18@htt-consult.com>
 <20170810182747.GY8146@mournblade.imrryr.org>
 <ce461722-8a89-eb6b-189b-d994a7ae4f6b@htt-consult.com>
 <20170810202655.GC8146@mournblade.imrryr.org>
Message-ID: <21cce159-9f8a-c7b2-558f-24deb2664e8d@htt-consult.com>



On 08/10/2017 04:26 PM, Viktor Dukhovni wrote:
> On Thu, Aug 10, 2017 at 03:17:02PM -0400, Robert Moskowitz wrote:
>
>>> Are you sure you want secp256k1?  By far the more common choice is
>>> prime256r1 (aka P-256 or secp256r1).
>> Do you mean prime256v1?
> Yes, it is the primary name in OpenSSL for secp256r1 aka (NIST) P-256.
>
Thank you for the help.  I now have a simple guide and a complement of 
files to work on a new project.

Did not do CRL or OCSP, but I don't need them yet.



From openssl-users at dukhovni.org  Thu Aug 10 23:01:05 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 10 Aug 2017 23:01:05 +0000
Subject: [openssl-users] Does openssl pick low level interface or high
 level interface to do encrypt?
In-Reply-To: <HK2PR02MB1140493B7B834262404E98E0A88B0@HK2PR02MB1140.apcprd02.prod.outlook.com>
References: <HK2PR02MB1140493B7B834262404E98E0A88B0@HK2PR02MB1140.apcprd02.prod.outlook.com>
Message-ID: <20170810230104.GD8146@mournblade.imrryr.org>

On Wed, Aug 09, 2017 at 01:08:47PM +0000, - JinsongJi wrote:

> For one simple operation: openssl enc -aes-256-cbc -salt -in foo.txt -out foo.enc
> Does openssl pick classic implementation or AES-NI implementation to do this encrypt?

The enc(1) command uses the EVP API to access the requested symmetric
cipher.  As a result, AES-NI and the like will be used when supported
by the hardware and enabled in your OpenSSL library.

> Does any user/application always pick classic implementation for
> AES operation regardless of AES-NI improves speed much?

If the application uses EVP_get_cipherbyname() and the like, it
gets the best available implementation of the cipher.  If it
bypasses EVP it may get a slower implementation and/or one that
has less side-channel resistance.

Bottom-line, use EVP.

-- 
	Viktor.

From rgm at htt-consult.com  Fri Aug 11 14:27:55 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Fri, 11 Aug 2017 10:27:55 -0400
Subject: [openssl-users] 802.1AR certificate generation and the config file
Message-ID: <1f4452df-cb49-aa85-2c0d-55ff1639215b@htt-consult.com>

Now that I can build a generic PKI with EDDSA, the next step is to add 
creation of 802.1AR iDevID certificates.  I am using the current draft, 
sec 8, 802.1ARce-d2-2, but for this purpose it is essentially the same 
(but clearer written) as sec 7, 802.1AR-2009.

I start with making the following section in my openssl.cnf file:

[ 8021AR_idevid ]
# Extensions for IEEE 802.1AR iDevID certificates (`man ????`).
basicConstraints = CA:FALSE
# subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment

Note that clause 7.6 says:

"The Subject Key Identifier extension should not be included in DevID 
certificates."

The clause goes on to state that Subject Key Identifier IS included in 
CA certificates for certificate path building.

My challenge comes to subjectAltName and its subfield hardwareModuleName 
per RFC 4108.   I guess I am not 'getting' the subjectAltName section of 
'man x509v3_config'.

Any help greatly appreciated.



From rsalz at akamai.com  Fri Aug 11 15:14:42 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 11 Aug 2017 15:14:42 +0000
Subject: [openssl-users] 802.1AR certificate generation and the config
 file
In-Reply-To: <1f4452df-cb49-aa85-2c0d-55ff1639215b@htt-consult.com>
References: <1f4452df-cb49-aa85-2c0d-55ff1639215b@htt-consult.com>
Message-ID: <2e01f77bd2e74da0845c73f60d4375e9@usma1ex-dag1mb1.msg.corp.akamai.com>

> My challenge comes to subjectAltName and its subfield
> hardwareModuleName
> per RFC 4108.   I guess I am not 'getting' the subjectAltName section of
> 'man x509v3_config'.

Not all forms of SAN names are supported.  If you look in include/openssl/x509v3.h you see the following:
# define GEN_OTHERNAME   0
# define GEN_EMAIL       1
# define GEN_DNS         2
# define GEN_X400        3
# define GEN_DIRNAME     4
# define GEN_EDIPARTY    5
# define GEN_URI         6
# define GEN_IPADD       7
# define GEN_RID         8

crypto/x509v3/v3_alt.c you can find details and corner-case information.


From rgm at htt-consult.com  Fri Aug 11 15:23:25 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Fri, 11 Aug 2017 11:23:25 -0400
Subject: [openssl-users] 802.1AR certificate generation and the config
 file
In-Reply-To: <2e01f77bd2e74da0845c73f60d4375e9@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <1f4452df-cb49-aa85-2c0d-55ff1639215b@htt-consult.com>
 <2e01f77bd2e74da0845c73f60d4375e9@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <01c4c907-bebe-649e-2d99-28cb9b116230@htt-consult.com>

Thanks for the response, Rich.

On 08/11/2017 11:14 AM, Salz, Rich via openssl-users wrote:
>> My challenge comes to subjectAltName and its subfield
>> hardwareModuleName
>> per RFC 4108.   I guess I am not 'getting' the subjectAltName section of
>> 'man x509v3_config'.
> Not all forms of SAN names are supported.  If you look in include/openssl/x509v3.h you see the following:
> # define GEN_OTHERNAME   0
> # define GEN_EMAIL       1
> # define GEN_DNS         2
> # define GEN_X400        3
> # define GEN_DIRNAME     4
> # define GEN_EDIPARTY    5
> # define GEN_URI         6
> # define GEN_IPADD       7
> # define GEN_RID         8
>
> crypto/x509v3/v3_alt.c you can find details and corner-case information.
>
A couple things.  As we have discussed directly, I am not a coder; 
haven't coded since working with 'B' on Honeywells in the mid-80s. So 
looking at 'C' code is a bit of a struggle.  That said,

Given these supported names, what goes into the config file to create a 
SAN without having to specify it on the command line?

And further it seems you are saying there is no support for HMN at all.



From rsalz at akamai.com  Fri Aug 11 15:29:25 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 11 Aug 2017 15:29:25 +0000
Subject: [openssl-users] 802.1AR certificate generation and the config
 file
In-Reply-To: <01c4c907-bebe-649e-2d99-28cb9b116230@htt-consult.com>
References: <1f4452df-cb49-aa85-2c0d-55ff1639215b@htt-consult.com>
 <2e01f77bd2e74da0845c73f60d4375e9@usma1ex-dag1mb1.msg.corp.akamai.com>
 <01c4c907-bebe-649e-2d99-28cb9b116230@htt-consult.com>
Message-ID: <9d0082386eca4925a55aeedd64b80368@usma1ex-dag1mb1.msg.corp.akamai.com>

> Given these supported names, what goes into the config file to create a SAN
> without having to specify it on the command line?

In the certificate extensions section you do something like:
	subjectAltName = dns:www.example.com, IP:127.0.0.1
and so on.  The "pki.tgz"

> And further it seems you are saying there is no support for HMN at all.

Right.

From rgm at htt-consult.com  Fri Aug 11 15:54:36 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Fri, 11 Aug 2017 11:54:36 -0400
Subject: [openssl-users] 802.1AR certificate generation and the config
 file
In-Reply-To: <9d0082386eca4925a55aeedd64b80368@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <1f4452df-cb49-aa85-2c0d-55ff1639215b@htt-consult.com>
 <2e01f77bd2e74da0845c73f60d4375e9@usma1ex-dag1mb1.msg.corp.akamai.com>
 <01c4c907-bebe-649e-2d99-28cb9b116230@htt-consult.com>
 <9d0082386eca4925a55aeedd64b80368@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <9d3237cc-215f-7dfa-b304-5e3d305ce2a2@htt-consult.com>



On 08/11/2017 11:29 AM, Salz, Rich wrote:
>> Given these supported names, what goes into the config file to create a SAN
>> without having to specify it on the command line?
> In the certificate extensions section you do something like:
> 	subjectAltName = dns:www.example.com, IP:127.0.0.1
> and so on.  The "pki.tgz"

OK.  I am beginning to get this.  Will set some things up and test.

>
>> And further it seems you are saying there is no support for HMN at all.
> Right.

What is the procedure to get it added.  RFC 4108 has been around for a 
while, as has 802.1AR-2009.

Though I am assuming from a prior comment that even if it were added 
today, it would not be available until the 1.1.1 release?

thanks

Bob


From rsalz at akamai.com  Fri Aug 11 15:56:12 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 11 Aug 2017 15:56:12 +0000
Subject: [openssl-users] 802.1AR certificate generation and the config
 file
In-Reply-To: <9d3237cc-215f-7dfa-b304-5e3d305ce2a2@htt-consult.com>
References: <1f4452df-cb49-aa85-2c0d-55ff1639215b@htt-consult.com>
 <2e01f77bd2e74da0845c73f60d4375e9@usma1ex-dag1mb1.msg.corp.akamai.com>
 <01c4c907-bebe-649e-2d99-28cb9b116230@htt-consult.com>
 <9d0082386eca4925a55aeedd64b80368@usma1ex-dag1mb1.msg.corp.akamai.com>
 <9d3237cc-215f-7dfa-b304-5e3d305ce2a2@htt-consult.com>
Message-ID: <a6d37bdf346d4faaa9c4ebf6acf2ad93@usma1ex-dag1mb1.msg.corp.akamai.com>

> What is the procedure to get it added.  RFC 4108 has been around for a while,
> as has 802.1AR-2009.

Simplest way is to (get someone to) write the code and make a github pull requests.

Next way is to post a patch.

Next way is to open an issue and hope someone gets around to it.
 
> Though I am assuming from a prior comment that even if it were added
> today, it would not be available until the 1.1.1 release?

Right.  But someone could always backport the changes to their own 1.1.0 release.

From rgm at htt-consult.com  Fri Aug 11 16:01:28 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Fri, 11 Aug 2017 12:01:28 -0400
Subject: [openssl-users] 802.1AR certificate generation and the config
 file
In-Reply-To: <a6d37bdf346d4faaa9c4ebf6acf2ad93@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <1f4452df-cb49-aa85-2c0d-55ff1639215b@htt-consult.com>
 <2e01f77bd2e74da0845c73f60d4375e9@usma1ex-dag1mb1.msg.corp.akamai.com>
 <01c4c907-bebe-649e-2d99-28cb9b116230@htt-consult.com>
 <9d0082386eca4925a55aeedd64b80368@usma1ex-dag1mb1.msg.corp.akamai.com>
 <9d3237cc-215f-7dfa-b304-5e3d305ce2a2@htt-consult.com>
 <a6d37bdf346d4faaa9c4ebf6acf2ad93@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <6994ed53-d96d-9ae7-3aa8-b0fff6fcadac@htt-consult.com>

Sigh.  Well let's see want I can get done on this by the next 
IEEE802/IETF week pair.

On 08/11/2017 11:56 AM, Salz, Rich wrote:
>> What is the procedure to get it added.  RFC 4108 has been around for a while,
>> as has 802.1AR-2009.
> Simplest way is to (get someone to) write the code and make a github pull requests.
>
> Next way is to post a patch.
>
> Next way is to open an issue and hope someone gets around to it.
>   
>> Though I am assuming from a prior comment that even if it were added
>> today, it would not be available until the 1.1.1 release?
> Right.  But someone could always backport the changes to their own 1.1.0 release.


From openssl-users at dukhovni.org  Fri Aug 11 16:47:46 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 11 Aug 2017 16:47:46 +0000
Subject: [openssl-users] 802.1AR certificate generation and the config
 file
In-Reply-To: <9d0082386eca4925a55aeedd64b80368@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <1f4452df-cb49-aa85-2c0d-55ff1639215b@htt-consult.com>
 <2e01f77bd2e74da0845c73f60d4375e9@usma1ex-dag1mb1.msg.corp.akamai.com>
 <01c4c907-bebe-649e-2d99-28cb9b116230@htt-consult.com>
 <9d0082386eca4925a55aeedd64b80368@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20170811164746.GG8146@mournblade.imrryr.org>

On Fri, Aug 11, 2017 at 03:29:25PM +0000, Salz, Rich via openssl-users wrote:

> In the certificate extensions section you do something like:
> 	subjectAltName = dns:www.example.com, IP:127.0.0.1
> and so on.  The "pki.tgz"
> 
> > And further it seems you are saying there is no support for HMN at all.
> 
> Right.

>From the x509v3_config manpage:

    ARBITRARY EXTENSIONS
       If an extension is not supported by the OpenSSL code then it must be
       encoded using the arbitrary extension format. It is also possible to
       use the arbitrary format for supported extensions. Extreme care should
       be taken to ensure that the data is formatted correctly for the given
       extension type.

       There are two ways to encode arbitrary extensions.

       The first way is to use the word ASN1 followed by the extension content
       using the same syntax as ASN1_generate_nconf(3).  For example:

        1.2.3.4=critical,ASN1:UTF8String:Some random data

        1.2.3.4=ASN1:SEQUENCE:seq_sect

        [seq_sect]

        field1 = UTF8:field1
        field2 = UTF8:field2

       It is also possible to use the word DER to include the raw encoded data
       in any extension.

        1.2.3.4=critical,DER:01:02:03:04
        1.2.3.4=DER:01020304

       The value following DER is a hex dump of the DER encoding of the
       extension Any extension can be placed in this form to override the
       default behaviour.  For example:

        basicConstraints=critical,DER:00:01:02:03

-- 
	Viktor.

From rgm at htt-consult.com  Fri Aug 11 17:08:22 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Fri, 11 Aug 2017 13:08:22 -0400
Subject: [openssl-users] 802.1AR certificate generation and the config
 file
In-Reply-To: <20170811164746.GG8146@mournblade.imrryr.org>
References: <1f4452df-cb49-aa85-2c0d-55ff1639215b@htt-consult.com>
 <2e01f77bd2e74da0845c73f60d4375e9@usma1ex-dag1mb1.msg.corp.akamai.com>
 <01c4c907-bebe-649e-2d99-28cb9b116230@htt-consult.com>
 <9d0082386eca4925a55aeedd64b80368@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20170811164746.GG8146@mournblade.imrryr.org>
Message-ID: <aab3fd66-b300-44d1-cafe-c712fb5dd30b@htt-consult.com>

Why thank you, Viktor.  Let's see if I can get this right from RFC4108

On 08/11/2017 12:47 PM, Viktor Dukhovni wrote:
> On Fri, Aug 11, 2017 at 03:29:25PM +0000, Salz, Rich via openssl-users wrote:
>
>> In the certificate extensions section you do something like:
>> 	subjectAltName = dns:www.example.com, IP:127.0.0.1
>> and so on.  The "pki.tgz"
>>
>>> And further it seems you are saying there is no support for HMN at all.
>> Right.
> >From the x509v3_config manpage:
>
>      ARBITRARY EXTENSIONS
>         If an extension is not supported by the OpenSSL code then it must be
>         encoded using the arbitrary extension format. It is also possible to
>         use the arbitrary format for supported extensions. Extreme care should
>         be taken to ensure that the data is formatted correctly for the given
>         extension type.
>
>         There are two ways to encode arbitrary extensions.
>
>         The first way is to use the word ASN1 followed by the extension content
>         using the same syntax as ASN1_generate_nconf(3).  For example:
>
>          1.2.3.4=critical,ASN1:UTF8String:Some random data
>
>          1.2.3.4=ASN1:SEQUENCE:seq_sect
>
>          [seq_sect]
>
>          field1 = UTF8:field1
>          field2 = UTF8:field2
>
>         It is also possible to use the word DER to include the raw encoded data
>         in any extension.
>
>          1.2.3.4=critical,DER:01:02:03:04
>          1.2.3.4=DER:01020304
>
>         The value following DER is a hex dump of the DER encoding of the
>         extension Any extension can be placed in this form to override the
>         default behaviour.  For example:
>
>          basicConstraints=critical,DER:00:01:02:03
>
       id-on-hardwareModuleName OBJECT IDENTIFIER ::= {
         iso(1) identified-organization(3) dod(6) internet(1) security(5)
         mechanisms(5) pkix(7) on(8) 4 }


       HardwareModuleName ::= SEQUENCE {
         hwType OBJECT IDENTIFIER,
         hwSerialNum OCTET STRING }

    The fields of the HardwareModuleName type have the following
    meanings:

    hwType is an object identifier that identifies the type of hardware
       module.  A unique object identifier names a hardware model and
       revision.

    hwSerialNum is the serial number of the hardware module.  No
       particular structure is imposed on the serial number; it need not
       be an integer.  However, the combination of the hwType and
       hwSerialNum uniquely identifies the hardware module.

In my [ 8021ar_idevid ] section I would have a line:

1.3.6.1.5.5.7.8.4=ASN1:SEQUENCE:HardwareModuleName

then have:

[ HardwareModuleName ]
hwType= ??
hwSerialNum= ??

I would want the 'openssl req' command to prompt for hwType and 
hsSerialNum.  At least for now.



From rgm at htt-consult.com  Fri Aug 11 17:57:23 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Fri, 11 Aug 2017 13:57:23 -0400
Subject: [openssl-users] 802.1AR certificate generation and the config
 file
In-Reply-To: <2e01f77bd2e74da0845c73f60d4375e9@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <1f4452df-cb49-aa85-2c0d-55ff1639215b@htt-consult.com>
 <2e01f77bd2e74da0845c73f60d4375e9@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <a9c803f5-af9f-40b1-eed4-1e8a4c86ba99@htt-consult.com>

Frustrated...

On 08/11/2017 11:14 AM, Salz, Rich via openssl-users wrote:
>> My challenge comes to subjectAltName and its subfield
>> hardwareModuleName
>> per RFC 4108.   I guess I am not 'getting' the subjectAltName section of
>> 'man x509v3_config'.
> Not all forms of SAN names are supported.  If you look in include/openssl/x509v3.h you see the following:
> # define GEN_OTHERNAME   0
> # define GEN_EMAIL       1
> # define GEN_DNS         2
> # define GEN_X400        3
> # define GEN_DIRNAME     4
> # define GEN_EDIPARTY    5
> # define GEN_URI         6
> # define GEN_IPADD       7
> # define GEN_RID         8

I just spent over an hour googling around as well as reading openssl 
docs to get a list of distinguished_name fields.  Both in their full 
form and abbreviated form.  All I fined are the common ones in examples.

And for the list above for SAN, how are they presented in the openssl 
cli/config.  Again, just not finding it.

My search foo is weak.

pointers greatly appreciated.

Bob


From steve at openssl.org  Fri Aug 11 18:39:11 2017
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 11 Aug 2017 18:39:11 +0000
Subject: [openssl-users] 802.1AR certificate generation and the config
 file
In-Reply-To: <a9c803f5-af9f-40b1-eed4-1e8a4c86ba99@htt-consult.com>
References: <1f4452df-cb49-aa85-2c0d-55ff1639215b@htt-consult.com>
 <2e01f77bd2e74da0845c73f60d4375e9@usma1ex-dag1mb1.msg.corp.akamai.com>
 <a9c803f5-af9f-40b1-eed4-1e8a4c86ba99@htt-consult.com>
Message-ID: <20170811183911.GA9338@openssl.org>

On Fri, Aug 11, 2017, Robert Moskowitz wrote:

> Frustrated...
> 
> On 08/11/2017 11:14 AM, Salz, Rich via openssl-users wrote:
> >>My challenge comes to subjectAltName and its subfield
> >>hardwareModuleName
> >>per RFC 4108.   I guess I am not 'getting' the subjectAltName section of
> >>'man x509v3_config'.
> >Not all forms of SAN names are supported.  If you look in include/openssl/x509v3.h you see the following:
> ># define GEN_OTHERNAME   0
> ># define GEN_EMAIL       1
> ># define GEN_DNS         2
> ># define GEN_X400        3
> ># define GEN_DIRNAME     4
> ># define GEN_EDIPARTY    5
> ># define GEN_URI         6
> ># define GEN_IPADD       7
> ># define GEN_RID         8
> 
> I just spent over an hour googling around as well as reading openssl
> docs to get a list of distinguished_name fields.  Both in their full
> form and abbreviated form.  All I fined are the common ones in
> examples.
> 
> And for the list above for SAN, how are they presented in the
> openssl cli/config.  Again, just not finding it.
> 
> My search foo is weak.
> 
> pointers greatly appreciated.
> 

You can use the mini-ASN.1 compiler with the otherName syntax. This will
create the extension in the appropriate form but you wont get it displayed.

In outline it's like this:

----
# Use id-on-hardwareModuleName OID with otherName
subjectAltName = otherName:1.3.6.1.5.5.7.8.4;SEQ:hmodname

[hmodname]
hwType = OID:1.2.3.4 # Whatever OID you want.
hwSerialNum = FORMAT:HEX,OCT:01020304 # Some hex
----

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From jqian at tibco.com  Fri Aug 11 18:43:37 2017
From: jqian at tibco.com (Jason Qian)
Date: Fri, 11 Aug 2017 14:43:37 -0400
Subject: [openssl-users] Core dump on DSA_free -- libssl.so.1.0.0
Message-ID: <CAGxzrjZRqQJrCb2CVUNu1LK-OEX4rfDj6A6ZdwiecfbHzbfcDg@mail.gmail.com>

Thanks for the help,


DSA *pDSA = d2i_DSA_PUBKEY(NULL, (const unsigned char **) &pKey, dwKeySize);
bool bRet = false;
if (pDSA)
{
bRet = DSA_verify(0, signature, 20, (BYTE *) pFile, dwSize, (DSA *) pDSA)
== 1 ? true : false;
DSA_free(pDSA);
}

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170811/6cafda53/attachment.html>

From steve at openssl.org  Fri Aug 11 18:47:23 2017
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 11 Aug 2017 18:47:23 +0000
Subject: [openssl-users] 802.1AR certificate generation and the config
 file
In-Reply-To: <aab3fd66-b300-44d1-cafe-c712fb5dd30b@htt-consult.com>
References: <1f4452df-cb49-aa85-2c0d-55ff1639215b@htt-consult.com>
 <2e01f77bd2e74da0845c73f60d4375e9@usma1ex-dag1mb1.msg.corp.akamai.com>
 <01c4c907-bebe-649e-2d99-28cb9b116230@htt-consult.com>
 <9d0082386eca4925a55aeedd64b80368@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20170811164746.GG8146@mournblade.imrryr.org>
 <aab3fd66-b300-44d1-cafe-c712fb5dd30b@htt-consult.com>
Message-ID: <20170811184723.GA10839@openssl.org>

On Fri, Aug 11, 2017, Robert Moskowitz wrote:

> 
> I would want the 'openssl req' command to prompt for hwType and
> hsSerialNum.  At least for now.
> 

Note that you can't get the 'openssl req' command prompt for this but you can
generate the extension in an appropriate syntax: see my other message for
details.

You could prompt externally and pass the values as environment variables to
openssl req of constuct the whole config file on the fly.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From rgm at htt-consult.com  Fri Aug 11 18:55:01 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Fri, 11 Aug 2017 14:55:01 -0400
Subject: [openssl-users] 802.1AR certificate generation and the config
 file
In-Reply-To: <20170811184723.GA10839@openssl.org>
References: <1f4452df-cb49-aa85-2c0d-55ff1639215b@htt-consult.com>
 <2e01f77bd2e74da0845c73f60d4375e9@usma1ex-dag1mb1.msg.corp.akamai.com>
 <01c4c907-bebe-649e-2d99-28cb9b116230@htt-consult.com>
 <9d0082386eca4925a55aeedd64b80368@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20170811164746.GG8146@mournblade.imrryr.org>
 <aab3fd66-b300-44d1-cafe-c712fb5dd30b@htt-consult.com>
 <20170811184723.GA10839@openssl.org>
Message-ID: <e3f38c6a-b58d-884a-e444-661311473018@htt-consult.com>



On 08/11/2017 02:47 PM, Dr. Stephen Henson wrote:
> On Fri, Aug 11, 2017, Robert Moskowitz wrote:
>
>> I would want the 'openssl req' command to prompt for hwType and
>> hsSerialNum.  At least for now.
>>
> Note that you can't get the 'openssl req' command prompt for this but you can
> generate the extension in an appropriate syntax: see my other message for
> details.
>
> You could prompt externally and pass the values as environment variables to
> openssl req of constuct the whole config file on the fly.

Sigh.

Making some headway.  Figured out you cannot have an alternative [ req ] 
section in the config; no way to specify it.  Thus a completely separate 
config_8021AR to specify a different distinguishedname set of fields.  
Got that, now to get started on SAN.  Will read your previous message.

thanks


From rsalz at akamai.com  Fri Aug 11 18:57:07 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 11 Aug 2017 18:57:07 +0000
Subject: [openssl-users] Core dump on DSA_free -- libssl.so.1.0.0
In-Reply-To: <CAGxzrjZRqQJrCb2CVUNu1LK-OEX4rfDj6A6ZdwiecfbHzbfcDg@mail.gmail.com>
References: <CAGxzrjZRqQJrCb2CVUNu1LK-OEX4rfDj6A6ZdwiecfbHzbfcDg@mail.gmail.com>
Message-ID: <e7444a199e3f482c8358237d49207741@usma1ex-dag1mb1.msg.corp.akamai.com>

> DSA *pDSA = d2i_DSA_PUBKEY(NULL, (const unsigned char **) &pKey, dwKeySize);

Where and how is pKey set?  Not that the manpage says it's incremented to point *past* the object, so you need something like
	unsigned char data = .....whatever your data source is .....
	unsigned char *pKey = data
and then use &pKey in your call


From rgm at htt-consult.com  Fri Aug 11 18:58:42 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Fri, 11 Aug 2017 14:58:42 -0400
Subject: [openssl-users] 802.1AR certificate generation and the config
 file
In-Reply-To: <20170811183911.GA9338@openssl.org>
References: <1f4452df-cb49-aa85-2c0d-55ff1639215b@htt-consult.com>
 <2e01f77bd2e74da0845c73f60d4375e9@usma1ex-dag1mb1.msg.corp.akamai.com>
 <a9c803f5-af9f-40b1-eed4-1e8a4c86ba99@htt-consult.com>
 <20170811183911.GA9338@openssl.org>
Message-ID: <8e51834b-d77e-4402-89da-7291ab31fd2f@htt-consult.com>



On 08/11/2017 02:39 PM, Dr. Stephen Henson wrote:
> On Fri, Aug 11, 2017, Robert Moskowitz wrote:
>
>> Frustrated...
>>
>> On 08/11/2017 11:14 AM, Salz, Rich via openssl-users wrote:
>>>> My challenge comes to subjectAltName and its subfield
>>>> hardwareModuleName
>>>> per RFC 4108.   I guess I am not 'getting' the subjectAltName section of
>>>> 'man x509v3_config'.
>>> Not all forms of SAN names are supported.  If you look in include/openssl/x509v3.h you see the following:
>>> # define GEN_OTHERNAME   0
>>> # define GEN_EMAIL       1
>>> # define GEN_DNS         2
>>> # define GEN_X400        3
>>> # define GEN_DIRNAME     4
>>> # define GEN_EDIPARTY    5
>>> # define GEN_URI         6
>>> # define GEN_IPADD       7
>>> # define GEN_RID         8
>> I just spent over an hour googling around as well as reading openssl
>> docs to get a list of distinguished_name fields.  Both in their full
>> form and abbreviated form.  All I fined are the common ones in
>> examples.
>>
>> And for the list above for SAN, how are they presented in the
>> openssl cli/config.  Again, just not finding it.
>>
>> My search foo is weak.
>>
>> pointers greatly appreciated.
>>
> You can use the mini-ASN.1 compiler with the otherName syntax. This will
> create the extension in the appropriate form but you wont get it displayed.
>
> In outline it's like this:
>
> ----
> # Use id-on-hardwareModuleName OID with otherName
> subjectAltName = otherName:1.3.6.1.5.5.7.8.4;SEQ:hmodname

Is that suppose to be a semi-colon before SEQ?  Or a typo?

>
> [hmodname]
> hwType = OID:1.2.3.4 # Whatever OID you want.
> hwSerialNum = FORMAT:HEX,OCT:01020304 # Some hex
> ----
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org


From jqian at tibco.com  Fri Aug 11 19:14:03 2017
From: jqian at tibco.com (Jason Qian)
Date: Fri, 11 Aug 2017 15:14:03 -0400
Subject: [openssl-users] Core dump on DSA_free -- libssl.so.1.0.0
In-Reply-To: <e7444a199e3f482c8358237d49207741@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CAGxzrjZRqQJrCb2CVUNu1LK-OEX4rfDj6A6ZdwiecfbHzbfcDg@mail.gmail.com>
 <e7444a199e3f482c8358237d49207741@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CAGxzrjYGT29PCU-W6izS_Vy+uR=vvgr7hDZLgFEayZeuJBJeDg@mail.gmail.com>

Thanks for look into this,

void * pKey = LockResource(hHandle);

The code works most of the time, only occasionally generates exception and
Not sure why on DSA_free(pDSA);




On Fri, Aug 11, 2017 at 2:57 PM, Salz, Rich <rsalz at akamai.com> wrote:

> > DSA *pDSA = d2i_DSA_PUBKEY(NULL, (const unsigned char **) &pKey,
> dwKeySize);
>
> Where and how is pKey set?  Not that the manpage says it's incremented to
> point *past* the object, so you need something like
>         unsigned char data = .....whatever your data source is .....
>         unsigned char *pKey = data
> and then use &pKey in your call
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170811/c4b9f1a1/attachment-0001.html>

From rsalz at akamai.com  Fri Aug 11 19:42:12 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 11 Aug 2017 19:42:12 +0000
Subject: [openssl-users] Core dump on DSA_free -- libssl.so.1.0.0
In-Reply-To: <CAGxzrjYGT29PCU-W6izS_Vy+uR=vvgr7hDZLgFEayZeuJBJeDg@mail.gmail.com>
References: <CAGxzrjZRqQJrCb2CVUNu1LK-OEX4rfDj6A6ZdwiecfbHzbfcDg@mail.gmail.com>
 <e7444a199e3f482c8358237d49207741@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAGxzrjYGT29PCU-W6izS_Vy+uR=vvgr7hDZLgFEayZeuJBJeDg@mail.gmail.com>
Message-ID: <f0fbc4c083014fd080ae3f174418f655@usma1ex-dag1mb1.msg.corp.akamai.com>

Please read what I wrote.

The d2i functions *modify the pointer they are given.*  You have to give them a temporary copy.

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richsalz at jabber.at Twitter: RichSalz

From: Jason Qian [mailto:jqian at tibco.com]
Sent: Friday, August 11, 2017 3:14 PM
To: Salz, Rich <rsalz at akamai.com>
Cc: openssl-users at openssl.org
Subject: Re: [openssl-users] Core dump on DSA_free -- libssl.so.1.0.0

Thanks for look into this,

void * pKey = LockResource(hHandle);

The code works most of the time, only occasionally generates exception and Not sure why on DSA_free(pDSA);




On Fri, Aug 11, 2017 at 2:57 PM, Salz, Rich <rsalz at akamai.com<mailto:rsalz at akamai.com>> wrote:
> DSA *pDSA = d2i_DSA_PUBKEY(NULL, (const unsigned char **) &pKey, dwKeySize);

Where and how is pKey set?  Not that the manpage says it's incremented to point *past* the object, so you need something like
        unsigned char data = .....whatever your data source is .....
        unsigned char *pKey = data
and then use &pKey in your call

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170811/2d539506/attachment.html>

From michael at stroeder.com  Sat Aug 12 14:28:49 2017
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Sat, 12 Aug 2017 16:28:49 +0200
Subject: [openssl-users] 802.1AR certificate generation and the config
 file
In-Reply-To: <e3f38c6a-b58d-884a-e444-661311473018@htt-consult.com>
References: <1f4452df-cb49-aa85-2c0d-55ff1639215b@htt-consult.com>
 <2e01f77bd2e74da0845c73f60d4375e9@usma1ex-dag1mb1.msg.corp.akamai.com>
 <01c4c907-bebe-649e-2d99-28cb9b116230@htt-consult.com>
 <9d0082386eca4925a55aeedd64b80368@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20170811164746.GG8146@mournblade.imrryr.org>
 <aab3fd66-b300-44d1-cafe-c712fb5dd30b@htt-consult.com>
 <20170811184723.GA10839@openssl.org>
 <e3f38c6a-b58d-884a-e444-661311473018@htt-consult.com>
Message-ID: <3930e39b-5411-eaf0-7713-e71fc105ae52@stroeder.com>

Robert Moskowitz wrote:
> On 08/11/2017 02:47 PM, Dr. Stephen Henson wrote:
>> On Fri, Aug 11, 2017, Robert Moskowitz wrote:
>>
>>> I would want the 'openssl req' command to prompt for hwType and
>>> hsSerialNum.  At least for now.
>>>
>> Note that you can't get the 'openssl req' command prompt for this but you can
>> generate the extension in an appropriate syntax: see my other message for
>> details.
>>
>> You could prompt externally and pass the values as environment variables to
>> openssl req of constuct the whole config file on the fly.
> 
> Sigh.
> 
> Making some headway.  Figured out you cannot have an alternative [ req ] section in the
> config; no way to specify it.  Thus a completely separate config_8021AR to specify a
> different distinguishedname set of fields.  Got that, now to get started on SAN.  Will
> read your previous message.

Maybe you should look at the following CLI options for "openssl req":

 -subj arg      set or modify request subject
[..]
 -extensions .. specify certificate extension section (override value in config file)
 -reqexts ..    specify request extension section (override value in config file)

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3829 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170812/f28e636f/attachment.bin>

From sudarshan.t.raghavan at gmail.com  Sun Aug 13 15:39:36 2017
From: sudarshan.t.raghavan at gmail.com (Sudarshan Raghavan)
Date: Sun, 13 Aug 2017 08:39:36 -0700
Subject: [openssl-users] certificate chains and verification requirements
Message-ID: <CAGxgQ08PsHXMM5J-rtKBwZwbGbj4hYj4sVx+Q6P_LR1gZdLaRw@mail.gmail.com>

Hello OpenSSL users,

I have this certificate chain, root ca -> intermediate ca 1 -> intermediate
ca 2 -> leaf certificate. With this chain, I attempted combinations of
openssl verify commands to understand how it works with certificate chains.

1. openssl verify -CAfile <chain containing certificates of intermediate ca
2, intermediate ca 1 and root ca in that order> <leaf certificate>. This
verifies ok as expected.
2. openssl verify -CAfile <same ca chain as in 1> <chain containing leaf,
intermediate ca 2, intermediate ca 1 and root ca in that order>. This
verifies ok as expected.
3. openssl verify -CAfile <root ca> <chain containing leaf, intermediate ca
2, intermediate ca 1 and root ca in that order>. This fails with this error

"error 20 at 0 depth lookup: unable to get local issuer certificate
error leafchain.pem: verification failed"

I understand the reason for this is, the issuer of leaf certificate
(intermediate ca 2) is not part of the trusted chain. But, the leaf chain
has all the certificates to root ca and root ca is the trusted CA I am
verifying against. I thought this would verify ok but, I am clearly wrong.
I can pass in the intermediate ca certificates using -untrusted option and
it will work. But, I was stumped by 3 and I am curious to know if there is
a document or rfc section explaining the behaviour. I have been trying to
search for something and I am clearly doing a bad job of it cause I have
not been able to find any.

Regards,
Sudarshan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170813/03f32b62/attachment-0001.html>

From openssl-users at dukhovni.org  Sun Aug 13 16:49:49 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 13 Aug 2017 12:49:49 -0400
Subject: [openssl-users] certificate chains and verification requirements
In-Reply-To: <CAGxgQ08PsHXMM5J-rtKBwZwbGbj4hYj4sVx+Q6P_LR1gZdLaRw@mail.gmail.com>
References: <CAGxgQ08PsHXMM5J-rtKBwZwbGbj4hYj4sVx+Q6P_LR1gZdLaRw@mail.gmail.com>
Message-ID: <E747F58C-EB19-48C7-9AFD-DC24779CADC0@dukhovni.org>


> On Aug 13, 2017, at 11:39 AM, Sudarshan Raghavan <sudarshan.t.raghavan at gmail.com> wrote:
> 
> 3. openssl verify -CAfile <root ca> <chain containing leaf, intermediate ca 2, intermediate ca 1 and root ca in that order>. This fails with this error
> 
> "error 20 at 0 depth lookup: unable to get local issuer certificate
> error leafchain.pem: verification failed"
> 
> I understand the reason for this is, the issuer of leaf certificate (intermediate ca 2) is not part of the trusted chain.

Actually, that's not the reason.  The positional [certificates]
arguments to verify(1) are not "chains".  Only the first (leaf)
certificate of each of the argument files is processed.

To import additional chain elements use the [-untrusted file]
argument to provide additional untrusted certificates with
which to build the chain.

-- 
	Viktor.


From sudarshan.t.raghavan at gmail.com  Sun Aug 13 17:24:05 2017
From: sudarshan.t.raghavan at gmail.com (Sudarshan Raghavan)
Date: Sun, 13 Aug 2017 10:24:05 -0700
Subject: [openssl-users] certificate chains and verification requirements
In-Reply-To: <E747F58C-EB19-48C7-9AFD-DC24779CADC0@dukhovni.org>
References: <CAGxgQ08PsHXMM5J-rtKBwZwbGbj4hYj4sVx+Q6P_LR1gZdLaRw@mail.gmail.com>
 <E747F58C-EB19-48C7-9AFD-DC24779CADC0@dukhovni.org>
Message-ID: <CAGxgQ09-6G-VDH4NXodhNcSC5Ahboko-GSgGJA+E56zNHOn4rg@mail.gmail.com>

>> Actually, that's not the reason.  The positional [certificates]
>> arguments to verify(1) are not "chains".  Only the first (leaf)
>> certificate of each of the argument files is processed.

Ok, that makes sense. Thanks for the update. I was trying this experiment
to understand a client authentication failure in a similar scenario. I can
now look at the code to figure out what is going on.

Regards,
Sudarshan

On Sun, Aug 13, 2017 at 9:49 AM, Viktor Dukhovni <openssl-users at dukhovni.org
> wrote:

>
> > On Aug 13, 2017, at 11:39 AM, Sudarshan Raghavan <
> sudarshan.t.raghavan at gmail.com> wrote:
> >
> > 3. openssl verify -CAfile <root ca> <chain containing leaf, intermediate
> ca 2, intermediate ca 1 and root ca in that order>. This fails with this
> error
> >
> > "error 20 at 0 depth lookup: unable to get local issuer certificate
> > error leafchain.pem: verification failed"
> >
> > I understand the reason for this is, the issuer of leaf certificate
> (intermediate ca 2) is not part of the trusted chain.
>
> Actually, that's not the reason.  The positional [certificates]
> arguments to verify(1) are not "chains".  Only the first (leaf)
> certificate of each of the argument files is processed.
>
> To import additional chain elements use the [-untrusted file]
> argument to provide additional untrusted certificates with
> which to build the chain.
>
> --
>         Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170813/56c50f71/attachment.html>

From luke1410 at slikesoft.com  Sun Aug 13 23:23:52 2017
From: luke1410 at slikesoft.com (Stefan Hett)
Date: Mon, 14 Aug 2017 01:23:52 +0200
Subject: [openssl-users] OpenSSL used in our network engine (SLikeNet)
Message-ID: <80a1ac4a-3145-12cd-584c-8c301aec3687@slikesoft.com>

Hi,

I'd just like to quickly reach out to let you know that we released a new (open source) network engine in which we also utilize the OpenSSL library and want to thank you for the work you put into OpenSSL.

Obviously OpenSSL is used as as the backbone to provide any kind of network encryption in the network engine.

In order to not have this acknowledgement mail be misinterpreted as an advertisement mail from our side, I refrained from adding links to the project pages. If you are interested in the project, feel free to send me a mail and I'll give you the links to the project pages.

Please note that I'll likely unsubscribe from the mailing list in about a week from now. In case you decide to reply to this message later than that, I'd appreciate to be CCed directly.

-- 
Regards,
Stefan Hett, CEO SLikeSoft

SLikeSoft UG (haftungsbeschr?nkt), Dresdener Str. 8, 52068 Aachen, Germany
Tel: +49 157 74050303
Gesch?ftsf?hrer: Stefan Hett, Handelsregister Aachen HRB 20706


From rgm at htt-consult.com  Mon Aug 14 04:02:49 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Mon, 14 Aug 2017 00:02:49 -0400
Subject: [openssl-users] 802.1AR certificate generation and the config
 file
In-Reply-To: <3930e39b-5411-eaf0-7713-e71fc105ae52@stroeder.com>
References: <1f4452df-cb49-aa85-2c0d-55ff1639215b@htt-consult.com>
 <2e01f77bd2e74da0845c73f60d4375e9@usma1ex-dag1mb1.msg.corp.akamai.com>
 <01c4c907-bebe-649e-2d99-28cb9b116230@htt-consult.com>
 <9d0082386eca4925a55aeedd64b80368@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20170811164746.GG8146@mournblade.imrryr.org>
 <aab3fd66-b300-44d1-cafe-c712fb5dd30b@htt-consult.com>
 <20170811184723.GA10839@openssl.org>
 <e3f38c6a-b58d-884a-e444-661311473018@htt-consult.com>
 <3930e39b-5411-eaf0-7713-e71fc105ae52@stroeder.com>
Message-ID: <572abb97-e131-f35b-47fd-e72630c7e50b@htt-consult.com>

I am getting a SAN in the csr e.g.:

         Attributes:
         Requested Extensions:
             X509v3 Subject Alternative Name:
                 IP Address:192.168.2.1

this is with the following in the config:

[ req ]
# Options for the `req` tool (`man req`).
default_bits        = 2048
distinguished_name  = req_distinguished_name
string_mask         = utf8only
req_extensions = req_ext

....

[ req_ext ]
subjectAltName = IP:192.168.2.1

But I am not getting SAN in the cert.  Perhaps I need something for SAN 
in the -extensions section?  Right now I only have:

[ 8021ar_idevid ]
# Extensions for IEEE 802.1AR iDevID certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment

????


On 08/12/2017 10:28 AM, Michael Str?der wrote:
> Robert Moskowitz wrote:
>> On 08/11/2017 02:47 PM, Dr. Stephen Henson wrote:
>>> On Fri, Aug 11, 2017, Robert Moskowitz wrote:
>>>
>>>> I would want the 'openssl req' command to prompt for hwType and
>>>> hsSerialNum.  At least for now.
>>>>
>>> Note that you can't get the 'openssl req' command prompt for this but you can
>>> generate the extension in an appropriate syntax: see my other message for
>>> details.
>>>
>>> You could prompt externally and pass the values as environment variables to
>>> openssl req of constuct the whole config file on the fly.
>> Sigh.
>>
>> Making some headway.  Figured out you cannot have an alternative [ req ] section in the
>> config; no way to specify it.  Thus a completely separate config_8021AR to specify a
>> different distinguishedname set of fields.  Got that, now to get started on SAN.  Will
>> read your previous message.
> Maybe you should look at the following CLI options for "openssl req":
>
>   -subj arg      set or modify request subject
> [..]
>   -extensions .. specify certificate extension section (override value in config file)
>   -reqexts ..    specify request extension section (override value in config file)
>
> Ciao, Michael.
>


From michael at stroeder.com  Mon Aug 14 11:16:13 2017
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Mon, 14 Aug 2017 13:16:13 +0200
Subject: [openssl-users] 802.1AR certificate generation and the config
 file
In-Reply-To: <572abb97-e131-f35b-47fd-e72630c7e50b@htt-consult.com>
References: <1f4452df-cb49-aa85-2c0d-55ff1639215b@htt-consult.com>
 <2e01f77bd2e74da0845c73f60d4375e9@usma1ex-dag1mb1.msg.corp.akamai.com>
 <01c4c907-bebe-649e-2d99-28cb9b116230@htt-consult.com>
 <9d0082386eca4925a55aeedd64b80368@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20170811164746.GG8146@mournblade.imrryr.org>
 <aab3fd66-b300-44d1-cafe-c712fb5dd30b@htt-consult.com>
 <20170811184723.GA10839@openssl.org>
 <e3f38c6a-b58d-884a-e444-661311473018@htt-consult.com>
 <3930e39b-5411-eaf0-7713-e71fc105ae52@stroeder.com>
 <572abb97-e131-f35b-47fd-e72630c7e50b@htt-consult.com>
Message-ID: <470334bc-a63a-1a68-8373-7d9c7222a9b2@stroeder.com>

Robert Moskowitz wrote:
> I am getting a SAN in the csr e.g.:
> 
>         Attributes:
>         Requested Extensions:
>             X509v3 Subject Alternative Name:
>                 IP Address:192.168.2.1
> [..]
> But I am not getting SAN in the cert.  Perhaps I need something for SAN in the
> -extensions section?  Right now I only have:

Are you using "openssl ca" for signing the cert?

If yes, you could add the line

copy_extensions = copy

to your CA config section.

http://cmrg.fifthhorseman.net/wiki/SubjectAltName

https://wiki.openssl.org/index.php/Manual:Ca%281%29#CONFIGURATION_FILE_OPTIONS

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3829 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170814/4af74aef/attachment.bin>

From rsalz at akamai.com  Mon Aug 14 12:53:40 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 14 Aug 2017 12:53:40 +0000
Subject: [openssl-users] OpenSSL used in our network engine (SLikeNet)
In-Reply-To: <80a1ac4a-3145-12cd-584c-8c301aec3687@slikesoft.com>
References: <80a1ac4a-3145-12cd-584c-8c301aec3687@slikesoft.com>
Message-ID: <1AF866DD-8215-4C49-BA56-C74ED2610C11@akamai.com>

? I'd just like to quickly reach out to let you know that we released a new (open source) network engine in which we also utilize the OpenSSL library and want to thank you for the work you put into OpenSSL.
    

Congratulations.  Please post a link, especially since it is open source!


From rgm at htt-consult.com  Mon Aug 14 16:55:34 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Mon, 14 Aug 2017 12:55:34 -0400
Subject: [openssl-users] 802.1AR certificate generation and the config
 file
In-Reply-To: <470334bc-a63a-1a68-8373-7d9c7222a9b2@stroeder.com>
References: <1f4452df-cb49-aa85-2c0d-55ff1639215b@htt-consult.com>
 <2e01f77bd2e74da0845c73f60d4375e9@usma1ex-dag1mb1.msg.corp.akamai.com>
 <01c4c907-bebe-649e-2d99-28cb9b116230@htt-consult.com>
 <9d0082386eca4925a55aeedd64b80368@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20170811164746.GG8146@mournblade.imrryr.org>
 <aab3fd66-b300-44d1-cafe-c712fb5dd30b@htt-consult.com>
 <20170811184723.GA10839@openssl.org>
 <e3f38c6a-b58d-884a-e444-661311473018@htt-consult.com>
 <3930e39b-5411-eaf0-7713-e71fc105ae52@stroeder.com>
 <572abb97-e131-f35b-47fd-e72630c7e50b@htt-consult.com>
 <470334bc-a63a-1a68-8373-7d9c7222a9b2@stroeder.com>
Message-ID: <62c46c6e-40bb-0718-575d-23b83256b7d4@htt-consult.com>



On 08/14/2017 07:16 AM, Michael Str?der wrote:
> Robert Moskowitz wrote:
>> I am getting a SAN in the csr e.g.:
>>
>>          Attributes:
>>          Requested Extensions:
>>              X509v3 Subject Alternative Name:
>>                  IP Address:192.168.2.1
>> [..]
>> But I am not getting SAN in the cert.  Perhaps I need something for SAN in the
>> -extensions section?  Right now I only have:
> Are you using "openssl ca" for signing the cert?

Yes, I am.

> If yes, you could add the line
>
> copy_extensions = copy
>
> to your CA config section.
>
> http://cmrg.fifthhorseman.net/wiki/SubjectAltName
>
> https://wiki.openssl.org/index.php/Manual:Ca%281%29#CONFIGURATION_FILE_OPTIONS
>
> Ciao, Michael.

Thanks.  That works.  Now that I can get a SAN into the certs I need to 
research using othername and what a hardwaremodulename OID looks like 
and make it happen.  Got to google some and ask around more.

Again thanks for helping me get this far.

Bob


From rgm at htt-consult.com  Mon Aug 14 18:02:02 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Mon, 14 Aug 2017 14:02:02 -0400
Subject: [openssl-users] Displaying subjectAtlName othername content
Message-ID: <db5a2e25-4e1f-a376-f4a1-718bd024567a@htt-consult.com>

I am now working on using the othername option.  I see it go in, but I 
can't display it.  All I get is:

             X509v3 Subject Alternative Name:
                 othername:<unsupported>

I seem to recall encountering some way to display this in a google 
search, but I have not found that search yet in my history.

Is there anyway to display the basic ASN.1 structure here so I can see 
what was stored in the cert?

thanks

Bob


From rsalz at akamai.com  Mon Aug 14 18:04:31 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 14 Aug 2017 18:04:31 +0000
Subject: [openssl-users] Displaying subjectAtlName othername content
In-Reply-To: <db5a2e25-4e1f-a376-f4a1-718bd024567a@htt-consult.com>
References: <db5a2e25-4e1f-a376-f4a1-718bd024567a@htt-consult.com>
Message-ID: <4596B0B1-C473-4B39-B945-664F06539289@akamai.com>

? Is there anyway to display the basic ASN.1 structure here so I can see 
    what was stored in the cert?
    
openssl asn1parse



From rgm at htt-consult.com  Mon Aug 14 18:55:12 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Mon, 14 Aug 2017 14:55:12 -0400
Subject: [openssl-users] Displaying subjectAtlName othername content
In-Reply-To: <4596B0B1-C473-4B39-B945-664F06539289@akamai.com>
References: <db5a2e25-4e1f-a376-f4a1-718bd024567a@htt-consult.com>
 <4596B0B1-C473-4B39-B945-664F06539289@akamai.com>
Message-ID: <4a79998b-7988-6128-fd1b-fe45ea6247c4@htt-consult.com>



On 08/14/2017 02:04 PM, Salz, Rich via openssl-users wrote:
> ? Is there anyway to display the basic ASN.1 structure here so I can see
>      what was stored in the cert?
>      
> openssl asn1parse

Humpf.  I looked at that a few times and did not see the obvious. Sigh.

So some progress.  using -i and got:

   573:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Subject 
Alternative Name
   578:d=5  hl=2 l=  29 prim:      OCTET STRING      [HEX 
DUMP]:301BA01906082B06010505070804A00D300B06032A0304040401020304

Added -strparse 578 and got:

     0:d=0  hl=2 l=  27 cons: SEQUENCE
     2:d=1  hl=2 l=  25 cons:  cont [ 0 ]
     4:d=2  hl=2 l=   8 prim:   OBJECT            :1.3.6.1.5.5.7.8.4
    14:d=2  hl=2 l=  13 cons:   cont [ 0 ]
    16:d=3  hl=2 l=  11 cons:    SEQUENCE
    18:d=4  hl=2 l=   3 prim:     OBJECT            :1.2.3.4
    23:d=4  hl=2 l=   4 prim:     OCTET STRING      [HEX DUMP]:01020304

Since I don't know that SubjectAltName content will always start at 578, 
I have to do the asn1parse in two steps.

It is a start...

Again, Thanks

Bob


From luke1410 at slikesoft.com  Mon Aug 14 19:25:46 2017
From: luke1410 at slikesoft.com (Stefan Hett)
Date: Mon, 14 Aug 2017 21:25:46 +0200
Subject: [openssl-users] OpenSSL used in our network engine (SLikeNet)
In-Reply-To: <1AF866DD-8215-4C49-BA56-C74ED2610C11@akamai.com>
References: <80a1ac4a-3145-12cd-584c-8c301aec3687@slikesoft.com>
 <1AF866DD-8215-4C49-BA56-C74ED2610C11@akamai.com>
Message-ID: <9f9e4128-7f8e-b202-c3e6-bd9ade2fad4b@slikesoft.com>

Hi Rich,

On 8/14/2017 14:53, Salz, Rich via openssl-users wrote:
> ? I'd just like to quickly reach out to let you know that we released a new (open source) network engine in which we also utilize the OpenSSL library and want to thank you for the work you put into OpenSSL.
>     
>
> Congratulations.  Please post a link, especially since it is open source!
>
Thanks. So if you are really fine with that, here's the link:

Project page: https://www.slikesoft.com/?page_id=1221&lang=de
Also available on GitHub: https://github.com/SLikeSoft/SLikeNet

-- 
Regards,
Stefan Hett


From jb-openssl at wisemo.com  Mon Aug 14 19:28:32 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 14 Aug 2017 21:28:32 +0200
Subject: [openssl-users] Displaying subjectAtlName othername content
In-Reply-To: <4a79998b-7988-6128-fd1b-fe45ea6247c4@htt-consult.com>
References: <db5a2e25-4e1f-a376-f4a1-718bd024567a@htt-consult.com>
 <4596B0B1-C473-4B39-B945-664F06539289@akamai.com>
 <4a79998b-7988-6128-fd1b-fe45ea6247c4@htt-consult.com>
Message-ID: <94ad3902-20f5-88be-3303-04aae941ad0b@wisemo.com>

On 14/08/2017 20:55, Robert Moskowitz wrote:
>
>
> On 08/14/2017 02:04 PM, Salz, Rich via openssl-users wrote:
>> ? Is there anyway to display the basic ASN.1 structure here so I can see
>>      what was stored in the cert?
>>      openssl asn1parse
>
> Humpf.  I looked at that a few times and did not see the obvious. Sigh.
>
> So some progress.  using -i and got:
>
>   573:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Subject 
> Alternative Name
>   578:d=5  hl=2 l=  29 prim:      OCTET STRING      [HEX 
> DUMP]:301BA01906082B06010505070804A00D300B06032A0304040401020304
>
> Added -strparse 578 and got:
>
>     0:d=0  hl=2 l=  27 cons: SEQUENCE
>     2:d=1  hl=2 l=  25 cons:  cont [ 0 ]
>     4:d=2  hl=2 l=   8 prim:   OBJECT :1.3.6.1.5.5.7.8.4
>    14:d=2  hl=2 l=  13 cons:   cont [ 0 ]
>    16:d=3  hl=2 l=  11 cons:    SEQUENCE
>    18:d=4  hl=2 l=   3 prim:     OBJECT            :1.2.3.4
>    23:d=4  hl=2 l=   4 prim:     OCTET STRING      [HEX DUMP]:01020304
>
> Since I don't know that SubjectAltName content will always start at 
> 578, I have to do the asn1parse in two steps.
>
> It is a start...
Try using dumpasn1.c by Peter Gutmann instead, it has nicer output and
automatically descends into these structures.  However it requires that
you convert from Base64 to binary before calling it.

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 rgm at htt-consult.com  Mon Aug 14 19:38:20 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Mon, 14 Aug 2017 15:38:20 -0400
Subject: [openssl-users] Displaying subjectAtlName othername content
In-Reply-To: <94ad3902-20f5-88be-3303-04aae941ad0b@wisemo.com>
References: <db5a2e25-4e1f-a376-f4a1-718bd024567a@htt-consult.com>
 <4596B0B1-C473-4B39-B945-664F06539289@akamai.com>
 <4a79998b-7988-6128-fd1b-fe45ea6247c4@htt-consult.com>
 <94ad3902-20f5-88be-3303-04aae941ad0b@wisemo.com>
Message-ID: <8059d643-5fa9-fd9e-e738-ce8baa2e3930@htt-consult.com>



On 08/14/2017 03:28 PM, Jakob Bohm wrote:
> On 14/08/2017 20:55, Robert Moskowitz wrote:
>>
>>
>> On 08/14/2017 02:04 PM, Salz, Rich via openssl-users wrote:
>>> ? Is there anyway to display the basic ASN.1 structure here so I can 
>>> see
>>>      what was stored in the cert?
>>>      openssl asn1parse
>>
>> Humpf.  I looked at that a few times and did not see the obvious. Sigh.
>>
>> So some progress.  using -i and got:
>>
>>   573:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Subject 
>> Alternative Name
>>   578:d=5  hl=2 l=  29 prim:      OCTET STRING      [HEX 
>> DUMP]:301BA01906082B06010505070804A00D300B06032A0304040401020304
>>
>> Added -strparse 578 and got:
>>
>>     0:d=0  hl=2 l=  27 cons: SEQUENCE
>>     2:d=1  hl=2 l=  25 cons:  cont [ 0 ]
>>     4:d=2  hl=2 l=   8 prim:   OBJECT :1.3.6.1.5.5.7.8.4
>>    14:d=2  hl=2 l=  13 cons:   cont [ 0 ]
>>    16:d=3  hl=2 l=  11 cons:    SEQUENCE
>>    18:d=4  hl=2 l=   3 prim:     OBJECT            :1.2.3.4
>>    23:d=4  hl=2 l=   4 prim:     OCTET STRING      [HEX DUMP]:01020304
>>
>> Since I don't know that SubjectAltName content will always start at 
>> 578, I have to do the asn1parse in two steps.
>>
>> It is a start...
> Try using dumpasn1.c by Peter Gutmann instead, it has nicer output and
> automatically descends into these structures.  However it requires that
> you convert from Base64 to binary before calling it.


And build your own version of openssl!  I am too far behind on this and 
other work to invest more time building my own modules.  Sigh.

Thanks, though.  Perhaps get to it later.

Bob


From jb-openssl at wisemo.com  Mon Aug 14 20:00:13 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 14 Aug 2017 22:00:13 +0200
Subject: [openssl-users] Displaying subjectAtlName othername content
In-Reply-To: <8059d643-5fa9-fd9e-e738-ce8baa2e3930@htt-consult.com>
References: <db5a2e25-4e1f-a376-f4a1-718bd024567a@htt-consult.com>
 <4596B0B1-C473-4B39-B945-664F06539289@akamai.com>
 <4a79998b-7988-6128-fd1b-fe45ea6247c4@htt-consult.com>
 <94ad3902-20f5-88be-3303-04aae941ad0b@wisemo.com>
 <8059d643-5fa9-fd9e-e738-ce8baa2e3930@htt-consult.com>
Message-ID: <b1c8f9b4-e0e6-4f1f-db14-6a909be21807@wisemo.com>

On 14/08/2017 21:38, Robert Moskowitz wrote:
> 
> 
> On 08/14/2017 03:28 PM, Jakob Bohm wrote:
>> On 14/08/2017 20:55, Robert Moskowitz wrote:
>>>
>>>
>>> On 08/14/2017 02:04 PM, Salz, Rich via openssl-users wrote:
>>>> ? Is there anyway to display the basic ASN.1 structure here so I can 
>>>> see
>>>>      what was stored in the cert?
>>>>      openssl asn1parse
>>>
>>> Humpf.  I looked at that a few times and did not see the obvious. Sigh.
>>>
>>> So some progress.  using -i and got:
>>>
>>>   573:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Subject 
>>> Alternative Name
>>>   578:d=5  hl=2 l=  29 prim:      OCTET STRING      [HEX 
>>> DUMP]:301BA01906082B06010505070804A00D300B06032A0304040401020304
>>>
>>> Added -strparse 578 and got:
>>>
>>>     0:d=0  hl=2 l=  27 cons: SEQUENCE
>>>     2:d=1  hl=2 l=  25 cons:  cont [ 0 ]
>>>     4:d=2  hl=2 l=   8 prim:   OBJECT :1.3.6.1.5.5.7.8.4
>>>    14:d=2  hl=2 l=  13 cons:   cont [ 0 ]
>>>    16:d=3  hl=2 l=  11 cons:    SEQUENCE
>>>    18:d=4  hl=2 l=   3 prim:     OBJECT            :1.2.3.4
>>>    23:d=4  hl=2 l=   4 prim:     OCTET STRING      [HEX DUMP]:01020304
>>>
>>> Since I don't know that SubjectAltName content will always start at 
>>> 578, I have to do the asn1parse in two steps.
>>>
>>> It is a start...
>> Try using dumpasn1.c by Peter Gutmann instead, it has nicer output and
>> automatically descends into these structures.  However it requires that
>> you convert from Base64 to binary before calling it.
> 
> 
> And build your own version of openssl!  I am too far behind on this and 
> other work to invest more time building my own modules.  Sigh.
> 
> Thanks, though.  Perhaps get to it later.
> 

dumpasn1.c is a useful ready-to-use tool that just needs a trivial
compile from a single file to a program for your computer type.  It has
saved me a lot of time over the years.



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 vakul.garg at nxp.com  Tue Aug 15 04:30:17 2017
From: vakul.garg at nxp.com (Vakul Garg)
Date: Tue, 15 Aug 2017 04:30:17 +0000
Subject: [openssl-users] SSL_CTX_set_msg_callback does not invoke for
 received change_cipher_spec
Message-ID: <HE1PR04MB3082F78504371E571F4517108B8D0@HE1PR04MB3082.eurprd04.prod.outlook.com>

Hi

I am using openssl s_server and s_client with '-msg' option to track tls1.2 records being exchanged.
I notice that while transmitted change_cipher_spec record gets printed.
But the reception of change_cipher_spec record is not reported.

For the received change_cipher_spec record, the callback (registered using SSL_set_msg_callback_arg) gets invoked only for record header, but not for the record content.
So there is no callback for received SSL3_RT_CHANGE_CIPHER_SPEC. For the transmitted change_cipher_spec record, things are fine.

Further, message callback invocation is correct for DTLS1.2 case as well.

Regards

Vakul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170815/1aab528e/attachment.html>

From bkaduk at akamai.com  Tue Aug 15 14:08:02 2017
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Tue, 15 Aug 2017 09:08:02 -0500
Subject: [openssl-users] SSL_CTX_set_msg_callback does not invoke for
 received change_cipher_spec
In-Reply-To: <HE1PR04MB3082F78504371E571F4517108B8D0@HE1PR04MB3082.eurprd04.prod.outlook.com>
References: <HE1PR04MB3082F78504371E571F4517108B8D0@HE1PR04MB3082.eurprd04.prod.outlook.com>
Message-ID: <9b54c528-3242-0f94-488c-d3623c02d23f@akamai.com>

On 08/14/2017 11:30 PM, Vakul Garg wrote:
>
> Hi
>
>  
>
> I am using openssl s_server and s_client with ?-msg? option to track
> tls1.2 records being exchanged.
>
> I notice that while transmitted change_cipher_spec record gets printed.
>
> But the reception of change_cipher_spec record is not reported.
>
>  
>
> For the received change_cipher_spec record, the callback (registered
> using SSL_set_msg_callback_arg) gets invoked only for record header,
> but not for the record content.
>
> So there is no callback for received SSL3_RT_CHANGE_CIPHER_SPEC. For
> the transmitted change_cipher_spec record, things are fine.
>

There is no variable content in a ChangeCipherSpec message -- a single
byte of value 1.  Are you trying to argue that the callback still ought
to be invoked out of some philosophical sense of consistency? 

In any case, if I remember correctly, ChangeCipherSpec is processed at a
very low layer and isn't propagated up to the layer that invokes the
message callback, and if one looks at the tradeoff between extra
complexity to propagate it up versus not having a message callback event
for it, there are some reasonable reasons to prefer the status quo.

>  
>
> Further, message callback invocation is correct for DTLS1.2 case as well.
>
>

(Just with respect to ChangeCipherSpec?)

-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170815/556d5e99/attachment.html>

From tom.browder at gmail.com  Wed Aug 16 13:24:49 2017
From: tom.browder at gmail.com (Tom Browder)
Date: Wed, 16 Aug 2017 13:24:49 +0000
Subject: [openssl-users] Personal CA: are cert serial numbers critical?
Message-ID: <CAFMGiz__xQ24OjNoELomGaTUY2VvyCS9QzLXz=eXaG6B-X_YQA@mail.gmail.com>

Many years ago I started a CA for one group I manage for a private website,
and now I want to update members' client certs for the stricter
requirements for browsers.

My original cert generation was entirely automated including the following:

+ CN for each is an e-mail address for the member

+ the passphrase for each member's cert is determined from a pre-generated
list by me, it will not change

I plan to tidy my automation before the issue of new certs, but I wonder
how critical it is to ensure unique certificate serial numbers given that
the certs are only used for us.  I'm not even sure I'll ever revoke any
cert (they were issued to expire sometime in 2030).

So, in summary, do I need to ensure cert serial numbers are unique for my
CA?

With warmest regards,

-Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170816/6c61da5b/attachment.html>

From michael at stroeder.com  Wed Aug 16 13:32:10 2017
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Wed, 16 Aug 2017 15:32:10 +0200
Subject: [openssl-users] Personal CA: are cert serial numbers critical?
In-Reply-To: <CAFMGiz__xQ24OjNoELomGaTUY2VvyCS9QzLXz=eXaG6B-X_YQA@mail.gmail.com>
References: <CAFMGiz__xQ24OjNoELomGaTUY2VvyCS9QzLXz=eXaG6B-X_YQA@mail.gmail.com>
Message-ID: <13a9a2ce-13f2-759d-8652-31c7fa9c313d@stroeder.com>

Tom Browder wrote:
> I plan to tidy my automation before the issue of new certs, but I wonder
> how critical it is to ensure unique certificate serial numbers given that
> the certs are only used for us.  I'm not even sure I'll ever revoke any
> cert (they were issued to expire sometime in 2030).
> 
> So, in summary, do I need to ensure cert serial numbers are unique for my
> CA?

Yes, serial numbers should be unique per issuer-DN because the 2-tuple
(issuer-DN, cert serial no.) is expected to be unique in several protocols.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3829 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170816/96835b8e/attachment-0001.bin>

From rsalz at akamai.com  Wed Aug 16 13:35:47 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 16 Aug 2017 13:35:47 +0000
Subject: [openssl-users] Personal CA: are cert serial numbers critical?
In-Reply-To: <CAFMGiz__xQ24OjNoELomGaTUY2VvyCS9QzLXz=eXaG6B-X_YQA@mail.gmail.com>
References: <CAFMGiz__xQ24OjNoELomGaTUY2VvyCS9QzLXz=eXaG6B-X_YQA@mail.gmail.com>
Message-ID: <A9BFA3C0-94D2-4966-AEB7-F0360443B82C@akamai.com>

? So, in summary, do I need to ensure cert serial numbers are unique for my CA?

Why would you not?  The specifications require it, but those specifications are for interoperability. If nobody is ever going to see your certs, then who cares what?s in them?  


From tom.browder at gmail.com  Wed Aug 16 14:23:05 2017
From: tom.browder at gmail.com (Tom Browder)
Date: Wed, 16 Aug 2017 14:23:05 +0000
Subject: [openssl-users] Personal CA: are cert serial numbers critical?
In-Reply-To: <13a9a2ce-13f2-759d-8652-31c7fa9c313d@stroeder.com>
References: <CAFMGiz__xQ24OjNoELomGaTUY2VvyCS9QzLXz=eXaG6B-X_YQA@mail.gmail.com>
 <13a9a2ce-13f2-759d-8652-31c7fa9c313d@stroeder.com>
Message-ID: <CAFMGiz_vS=th1GszA+Eh4zuj4BK=P7CCY5Rj6zDOqzT-yZDp=A@mail.gmail.com>

On Wed, Aug 16, 2017 at 08:32 Michael Str?der <michael at stroeder.com> wrote:

> Tom Browder wrote:

...

> > So, in summary, do I need to ensure cert serial numbers are unique for my
> > CA?
>
> Yes, serial numbers should be unique per issuer-DN because the 2-tuple
> (issuer-DN, cert serial no.) is expected to be unique in several protocols.


Okay, that's good enough reason for me,

Thanks, Michael.

Cheers!

-Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170816/7dbcc085/attachment.html>

From tom.browder at gmail.com  Wed Aug 16 14:32:16 2017
From: tom.browder at gmail.com (Tom Browder)
Date: Wed, 16 Aug 2017 14:32:16 +0000
Subject: [openssl-users] Personal CA: are cert serial numbers critical?
In-Reply-To: <A9BFA3C0-94D2-4966-AEB7-F0360443B82C@akamai.com>
References: <CAFMGiz__xQ24OjNoELomGaTUY2VvyCS9QzLXz=eXaG6B-X_YQA@mail.gmail.com>
 <A9BFA3C0-94D2-4966-AEB7-F0360443B82C@akamai.com>
Message-ID: <CAFMGiz-b7NF9S5TK21_S5RY3mooagPpoghbk04AipQehoZcr1w@mail.gmail.com>

On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users <
openssl-users at openssl.org> wrote:

> ? So, in summary, do I need to ensure cert serial numbers are unique for
> my CA?
>
> Why would you not?  The specifications require it, but those
> specifications are for interoperability. If nobody is ever going to see
> your certs, then who cares what?s in them?


Well, I do like to abide by specs, and they will be used in various
browsers, so I think I will continue the unique serial numbering.

Thanks, Rich.

Best regards,

-Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170816/89454947/attachment.html>

From jb-openssl at wisemo.com  Wed Aug 16 14:51:26 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 16 Aug 2017 16:51:26 +0200
Subject: [openssl-users] Personal CA: are cert serial numbers critical?
In-Reply-To: <CAFMGiz-b7NF9S5TK21_S5RY3mooagPpoghbk04AipQehoZcr1w@mail.gmail.com>
References: <CAFMGiz__xQ24OjNoELomGaTUY2VvyCS9QzLXz=eXaG6B-X_YQA@mail.gmail.com>
 <A9BFA3C0-94D2-4966-AEB7-F0360443B82C@akamai.com>
 <CAFMGiz-b7NF9S5TK21_S5RY3mooagPpoghbk04AipQehoZcr1w@mail.gmail.com>
Message-ID: <3f736c65-199b-5e6d-1096-29bc6e9da445@wisemo.com>

On 16/08/2017 16:32, Tom Browder wrote:
> On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users 
> <openssl-users at openssl.org <mailto:openssl-users at openssl.org>> wrote:
>
>     ? So, in summary, do I need to ensure cert serial numbers are
>     unique for my CA?
>
>     Why would you not?  The specifications require it, but those
>     specifications are for interoperability. If nobody is ever going
>     to see your certs, then who cares what?s in them?
>
>
> Well, I do like to abide by specs, and they will be used in various 
> browsers, so I think I will continue the unique serial numbering.
>
> Thanks, Rich.

Modern browsers increasingly presume that such private CAs behave exactly
like the public CAs regulated through the CA/Browsers Forum (CAB/F) and
the per-browser root CA inclusion programs (the administrative processes
that determine which CAs are listed in browsers by default).

Among the relevant requirements now needed:

- Serial numbers are *exactly* 20 bytes (153 to 159 bits) both as 
standalone
  numbers and as DER-encoded numbers.  Note that this is not the default in
  the openssl ca program.

- Serial numbers contain cryptographically strong random bits, currently at
  least 64 random bits, though it is best if the entire serial number looks
  random from the outside.  This is not implemented by the openssl ca 
program.

- Certificates are valid for at most 2 years (actually 825 days).

- SHA-1 (and other weak algorithms such as MD5) are no longer permitted and
  is already disappearing from Browser code.

- RSA shorter than 2048 bits (and other weak settings such as equally short
  DSA keys) are no longer permitted and is already disappearing from 
Browser
  code.

- If the certificate is issued to an e-mail address, that e-mail address 
must
  also be listed as an rfc822Name in a "Subject Alternative Name" 
certificate
  extension.

- End user certificates must be issued from an Intermediary CA whose
  certificate is is in turn issued from a longer term root CA.

- If revocation is implemented (it should be, just in case someone gets 
their
  computer or other key storage hacked/stolen), it needs to support 
OCSP, but
  should ideally do so without having the actual CA keys online 
(standard trick:
  Issue 3-month non-revocable OCSP-signing certificates and provide the
  corresponding private key to the server running the OCSP responder 
program).
   I would recommend to also implement traditional CRLs, since for 
smaller CAs
  it is a better solution for browsers and servers that support it.


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 gregs at sloop.net  Wed Aug 16 15:54:54 2017
From: gregs at sloop.net (Gregory Sloop)
Date: Wed, 16 Aug 2017 08:54:54 -0700
Subject: [openssl-users] Personal CA: are cert serial numbers critical?
In-Reply-To: <3f736c65-199b-5e6d-1096-29bc6e9da445@wisemo.com>
References: <CAFMGiz__xQ24OjNoELomGaTUY2VvyCS9QzLXz=eXaG6B-X_YQA@mail.gmail.com> 
 <A9BFA3C0-94D2-4966-AEB7-F0360443B82C@akamai.com>
 <CAFMGiz-b7NF9S5TK21_S5RY3mooagPpoghbk04AipQehoZcr1w@mail.gmail.com>
 <3f736c65-199b-5e6d-1096-29bc6e9da445@wisemo.com>
Message-ID: <1001231540.20170816085454@sloop.net>

Replying personally:

I'm a nobody, and you have no reason to know me - but wanted to thank you for the input you give here.

You're nearly always quite thoughtful, careful in what you say, respectful, and give such [IMO] good insightful feedback and information to people looking for help. I follow quite a number of lists, and IMO, it's a rare breed of individuals who do such a fine job.

Perhaps you care nothing for such accolades, and I'm truly a "nobody" in giving them - but still I wanted to recognize excellence when I see it.

So, Thanks!

-Greg

JB> On 16/08/2017 16:32, Tom Browder wrote:
>> On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users 
>> <openssl-users at openssl.org <mailto:openssl-users at openssl.org>> wrote:

>>     ? So, in summary, do I need to ensure cert serial numbers are
>>     unique for my CA?

>>     Why would you not?  The specifications require it, but those
>>     specifications are for interoperability. If nobody is ever going
>>     to see your certs, then who cares what?s in them?


>> Well, I do like to abide by specs, and they will be used in various 
>> browsers, so I think I will continue the unique serial numbering.

>> Thanks, Rich.

JB> Modern browsers increasingly presume that such private CAs behave exactly
JB> like the public CAs regulated through the CA/Browsers Forum (CAB/F) and
JB> the per-browser root CA inclusion programs (the administrative processes
JB> that determine which CAs are listed in browsers by default).

JB> Among the relevant requirements now needed:

JB> - Serial numbers are *exactly* 20 bytes (153 to 159 bits) both as 
JB> standalone
JB>   numbers and as DER-encoded numbers.  Note that this is not the default in
JB>   the openssl ca program.

JB> - Serial numbers contain cryptographically strong random bits, currently at
JB>   least 64 random bits, though it is best if the entire serial number looks
JB>   random from the outside.  This is not implemented by the openssl ca 
JB> program.

JB> - Certificates are valid for at most 2 years (actually 825 days).

JB> - SHA-1 (and other weak algorithms such as MD5) are no longer permitted and
JB>   is already disappearing from Browser code.

JB> - RSA shorter than 2048 bits (and other weak settings such as equally short
JB>   DSA keys) are no longer permitted and is already disappearing from 
JB> Browser
JB>   code.

JB> - If the certificate is issued to an e-mail address, that e-mail address
JB> must
JB>   also be listed as an rfc822Name in a "Subject Alternative Name" 
JB> certificate
JB>   extension.

JB> - End user certificates must be issued from an Intermediary CA whose
JB>   certificate is is in turn issued from a longer term root CA.

JB> - If revocation is implemented (it should be, just in case someone gets
JB> their
JB>   computer or other key storage hacked/stolen), it needs to support 
JB> OCSP, but
JB>   should ideally do so without having the actual CA keys online 
JB> (standard trick:
JB>   Issue 3-month non-revocable OCSP-signing certificates and provide the
JB>   corresponding private key to the server running the OCSP responder 
JB> program).
JB>    I would recommend to also implement traditional CRLs, since for 
JB> smaller CAs
JB>   it is a better solution for browsers and servers that support it.


JB> Enjoy

JB> Jakob
JB> -- 
JB> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
JB> Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
JB> This public discussion message is non-binding and may contain errors.
JB> WiseMo - Remote Service Management for PCs, Phones and Embedded


-- 
Gregory Sloop, Principal: Sloop Network & Computer Consulting
Voice: 503.251.0452 x82
EMail: gregs at sloop.net
http://www.sloop.net
---
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170816/da61ac19/attachment-0001.html>

From rgm at htt-consult.com  Wed Aug 16 16:52:16 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Wed, 16 Aug 2017 12:52:16 -0400
Subject: [openssl-users] Personal CA: are cert serial numbers critical?
In-Reply-To: <3f736c65-199b-5e6d-1096-29bc6e9da445@wisemo.com>
References: <CAFMGiz__xQ24OjNoELomGaTUY2VvyCS9QzLXz=eXaG6B-X_YQA@mail.gmail.com>
 <A9BFA3C0-94D2-4966-AEB7-F0360443B82C@akamai.com>
 <CAFMGiz-b7NF9S5TK21_S5RY3mooagPpoghbk04AipQehoZcr1w@mail.gmail.com>
 <3f736c65-199b-5e6d-1096-29bc6e9da445@wisemo.com>
Message-ID: <a68af903-ca93-a284-dca7-78aa05231b41@htt-consult.com>



On 08/16/2017 10:51 AM, Jakob Bohm wrote:
> On 16/08/2017 16:32, Tom Browder wrote:
>> On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users 
>> <openssl-users at openssl.org <mailto:openssl-users at openssl.org>> wrote:
>>
>>     ? So, in summary, do I need to ensure cert serial numbers are
>>     unique for my CA?
>>
>>     Why would you not?  The specifications require it, but those
>>     specifications are for interoperability. If nobody is ever going
>>     to see your certs, then who cares what?s in them?
>>
>>
>> Well, I do like to abide by specs, and they will be used in various 
>> browsers, so I think I will continue the unique serial numbering.
>>
>> Thanks, Rich.
>
> Modern browsers increasingly presume that such private CAs behave exactly
> like the public CAs regulated through the CA/Browsers Forum (CAB/F) and
> the per-browser root CA inclusion programs (the administrative processes
> that determine which CAs are listed in browsers by default).
>
> Among the relevant requirements now needed:
>
> - Serial numbers are *exactly* 20 bytes (153 to 159 bits) both as 
> standalone
>  numbers and as DER-encoded numbers.  Note that this is not the 
> default in
>  the openssl ca program.
>
> - Serial numbers contain cryptographically strong random bits, 
> currently at
>  least 64 random bits, though it is best if the entire serial number 
> looks
>  random from the outside.  This is not implemented by the openssl ca 
> program.
>
> - Certificates are valid for at most 2 years (actually 825 days).
>
> - SHA-1 (and other weak algorithms such as MD5) are no longer 
> permitted and
>  is already disappearing from Browser code.
>
> - RSA shorter than 2048 bits (and other weak settings such as equally 
> short
>  DSA keys) are no longer permitted and is already disappearing from 
> Browser
>  code.

How universal is ECDSA p-256 support?

>
> - If the certificate is issued to an e-mail address, that e-mail 
> address must
>  also be listed as an rfc822Name in a "Subject Alternative Name" 
> certificate
>  extension.

Which is also a problem in openssl.  You have to put the SAN into the 
cnf file.  There are a number of hacks to do this from the command line.



From openssl-users at dukhovni.org  Wed Aug 16 17:12:34 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 16 Aug 2017 13:12:34 -0400
Subject: [openssl-users] Personal CA: are cert serial numbers critical?
In-Reply-To: <a68af903-ca93-a284-dca7-78aa05231b41@htt-consult.com>
References: <CAFMGiz__xQ24OjNoELomGaTUY2VvyCS9QzLXz=eXaG6B-X_YQA@mail.gmail.com>
 <A9BFA3C0-94D2-4966-AEB7-F0360443B82C@akamai.com>
 <CAFMGiz-b7NF9S5TK21_S5RY3mooagPpoghbk04AipQehoZcr1w@mail.gmail.com>
 <3f736c65-199b-5e6d-1096-29bc6e9da445@wisemo.com>
 <a68af903-ca93-a284-dca7-78aa05231b41@htt-consult.com>
Message-ID: <C9620466-3F15-4B9C-A9F7-3F3887A92AD1@dukhovni.org>


> On Aug 16, 2017, at 12:52 PM, Robert Moskowitz <rgm at htt-consult.com> wrote:
> 
> Which is also a problem in openssl.  You have to put the SAN into the cnf file.  There are a number of hacks to do this from the command line.

Yep.  For an approach that uses "bash" in-line files see:

   https://github.com/openssl/openssl/blob/master/test/certs/mkcert.sh#L95

-- 
	Viktor.

From rgm at htt-consult.com  Wed Aug 16 17:54:55 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Wed, 16 Aug 2017 13:54:55 -0400
Subject: [openssl-users] Personal CA: are cert serial numbers critical?
In-Reply-To: <C9620466-3F15-4B9C-A9F7-3F3887A92AD1@dukhovni.org>
References: <CAFMGiz__xQ24OjNoELomGaTUY2VvyCS9QzLXz=eXaG6B-X_YQA@mail.gmail.com>
 <A9BFA3C0-94D2-4966-AEB7-F0360443B82C@akamai.com>
 <CAFMGiz-b7NF9S5TK21_S5RY3mooagPpoghbk04AipQehoZcr1w@mail.gmail.com>
 <3f736c65-199b-5e6d-1096-29bc6e9da445@wisemo.com>
 <a68af903-ca93-a284-dca7-78aa05231b41@htt-consult.com>
 <C9620466-3F15-4B9C-A9F7-3F3887A92AD1@dukhovni.org>
Message-ID: <ca2ef83e-57f5-9b44-1677-309cab1cbb03@htt-consult.com>



On 08/16/2017 01:12 PM, Viktor Dukhovni wrote:
>> On Aug 16, 2017, at 12:52 PM, Robert Moskowitz <rgm at htt-consult.com> wrote:
>>
>> Which is also a problem in openssl.  You have to put the SAN into the cnf file.  There are a number of hacks to do this from the command line.
> Yep.  For an approach that uses "bash" in-line files see:
>
>     https://github.com/openssl/openssl/blob/master/test/certs/mkcert.sh#L95
>
I prefer something like this:

openssl req -new -sha256 -key domain.key -subj "/C=US/ST=CA/O=Acme, 
Inc./CN=example.com"\
  -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf 
"[SAN]\nsubjectAltName=DNS:example.com,DNS:www.example.com"))\
  -out domain.csr

Bob


From jb-openssl at wisemo.com  Wed Aug 16 18:29:42 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 16 Aug 2017 20:29:42 +0200
Subject: [openssl-users] Personal CA: are cert serial numbers critical?
In-Reply-To: <ca2ef83e-57f5-9b44-1677-309cab1cbb03@htt-consult.com>
References: <CAFMGiz__xQ24OjNoELomGaTUY2VvyCS9QzLXz=eXaG6B-X_YQA@mail.gmail.com>
 <A9BFA3C0-94D2-4966-AEB7-F0360443B82C@akamai.com>
 <CAFMGiz-b7NF9S5TK21_S5RY3mooagPpoghbk04AipQehoZcr1w@mail.gmail.com>
 <3f736c65-199b-5e6d-1096-29bc6e9da445@wisemo.com>
 <a68af903-ca93-a284-dca7-78aa05231b41@htt-consult.com>
 <C9620466-3F15-4B9C-A9F7-3F3887A92AD1@dukhovni.org>
 <ca2ef83e-57f5-9b44-1677-309cab1cbb03@htt-consult.com>
Message-ID: <41d9c4a9-9261-19be-3c25-73a971afbbe0@wisemo.com>

On 16/08/2017 19:54, Robert Moskowitz wrote:
>
>
> On 08/16/2017 01:12 PM, Viktor Dukhovni wrote:
>>> On Aug 16, 2017, at 12:52 PM, Robert Moskowitz <rgm at htt-consult.com> 
>>> wrote:
>>>
>>> Which is also a problem in openssl.  You have to put the SAN into 
>>> the cnf file.  There are a number of hacks to do this from the 
>>> command line.
>> Yep.  For an approach that uses "bash" in-line files see:
>>
>> https://github.com/openssl/openssl/blob/master/test/certs/mkcert.sh#L95
>>
> I prefer something like this:
>
> openssl req -new -sha256 -key domain.key -subj "/C=US/ST=CA/O=Acme, 
> Inc./CN=example.com"\
>  -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf 
> "[SAN]\nsubjectAltName=DNS:example.com,DNS:www.example.com"))\
>  -out domain.csr
Another option is to use a config file that includes environment variables
in the relevant fields.

So it becomes something like
export FOREMAIL=moe at example.com
export FORUSER="Moe Madman"
export CERTFN=moe
openssl req -config /etc/cacfg/ca2017-mail.conf -newkey rsa:3072 -keyout 
${CERTFN}.key -out ${CERTFN}.csr

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 Erwann.Abalea at docusign.com  Wed Aug 16 15:58:59 2017
From: Erwann.Abalea at docusign.com (Erwann Abalea)
Date: Wed, 16 Aug 2017 15:58:59 +0000
Subject: [openssl-users] Personal CA: are cert serial numbers critical?
In-Reply-To: <3f736c65-199b-5e6d-1096-29bc6e9da445@wisemo.com>
References: <CAFMGiz__xQ24OjNoELomGaTUY2VvyCS9QzLXz=eXaG6B-X_YQA@mail.gmail.com>
 <A9BFA3C0-94D2-4966-AEB7-F0360443B82C@akamai.com>
 <CAFMGiz-b7NF9S5TK21_S5RY3mooagPpoghbk04AipQehoZcr1w@mail.gmail.com>
 <3f736c65-199b-5e6d-1096-29bc6e9da445@wisemo.com>
Message-ID: <202F992A-3BDC-469F-A3D8-53A979B284B2@docusign.com>

Bonjour,

> Le 16 ao?t 2017 ? 16:51, Jakob Bohm <jb-openssl at wisemo.com> a ?crit :
> 
> On 16/08/2017 16:32, Tom Browder wrote:
>> On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users <openssl-users at openssl.org <mailto:openssl-users at openssl.org>> wrote:
>> 
>>    ? So, in summary, do I need to ensure cert serial numbers are
>>    unique for my CA?
>> 
>>    Why would you not?  The specifications require it, but those
>>    specifications are for interoperability. If nobody is ever going
>>    to see your certs, then who cares what?s in them?
>> 
>> 
>> Well, I do like to abide by specs, and they will be used in various browsers, so I think I will continue the unique serial numbering.
>> 
>> Thanks, Rich.
> 
> Modern browsers increasingly presume that such private CAs behave exactly
> like the public CAs regulated through the CA/Browsers Forum (CAB/F) and
> the per-browser root CA inclusion programs (the administrative processes
> that determine which CAs are listed in browsers by default).
> 
> Among the relevant requirements now needed:
> 
> - Serial numbers are *exactly* 20 bytes (153 to 159 bits) both as standalone
> numbers and as DER-encoded numbers.  Note that this is not the default in
> the openssl ca program.

There?s no such requirement. It MUST be at most 20 octets long.

> - Serial numbers contain cryptographically strong random bits, currently at
> least 64 random bits, though it is best if the entire serial number looks
> random from the outside.  This is not implemented by the openssl ca program.

It can be easily done by an external script. Generate a secret key for your CA for a 128bits block cipher, keep the monotonic counter, but instead of putting the value of the counter in the serial number, encrypt the counter with the key+cipher, and use the resulting cipher text as the serial number. Of course, increment the counter.

> - Certificates are valid for at most 2 years (actually 825 days).
> 
> - SHA-1 (and other weak algorithms such as MD5) are no longer permitted and
> is already disappearing from Browser code.
> 
> - RSA shorter than 2048 bits (and other weak settings such as equally short
> DSA keys) are no longer permitted and is already disappearing from Browser
> code.
> 
> - If the certificate is issued to an e-mail address, that e-mail address must
> also be listed as an rfc822Name in a "Subject Alternative Name" certificate
> extension.
> 
> - End user certificates must be issued from an Intermediary CA whose
> certificate is is in turn issued from a longer term root CA.

I doubt browsers impose this on purely private CAs.

> - If revocation is implemented (it should be, just in case someone gets their
> computer or other key storage hacked/stolen), it needs to support OCSP, but
> should ideally do so without having the actual CA keys online (standard trick:
> Issue 3-month non-revocable OCSP-signing certificates and provide the
> corresponding private key to the server running the OCSP responder program).
>  I would recommend to also implement traditional CRLs, since for smaller CAs
> it is a better solution for browsers and servers that support it.

Another requirement is that a TLS server certificate shall have its identity (FQDN) in the SAN extension. Use of the commonName attribute has been deprecated long ago.

Cordialement,
Erwann Abalea


From rgm at htt-consult.com  Wed Aug 16 20:24:59 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Wed, 16 Aug 2017 16:24:59 -0400
Subject: [openssl-users] Personal CA: are cert serial numbers critical?
In-Reply-To: <202F992A-3BDC-469F-A3D8-53A979B284B2@docusign.com>
References: <CAFMGiz__xQ24OjNoELomGaTUY2VvyCS9QzLXz=eXaG6B-X_YQA@mail.gmail.com>
 <A9BFA3C0-94D2-4966-AEB7-F0360443B82C@akamai.com>
 <CAFMGiz-b7NF9S5TK21_S5RY3mooagPpoghbk04AipQehoZcr1w@mail.gmail.com>
 <3f736c65-199b-5e6d-1096-29bc6e9da445@wisemo.com>
 <202F992A-3BDC-469F-A3D8-53A979B284B2@docusign.com>
Message-ID: <e8683482-24d7-2eca-8349-2575c95732cd@htt-consult.com>



On 08/16/2017 11:58 AM, Erwann Abalea via openssl-users wrote:
> Bonjour,
>
>> Le 16 ao?t 2017 ? 16:51, Jakob Bohm <jb-openssl at wisemo.com> a ?crit :
>>
>> On 16/08/2017 16:32, Tom Browder wrote:
>>> On Wed, Aug 16, 2017 at 08:36 Salz, Rich via openssl-users <openssl-users at openssl.org <mailto:openssl-users at openssl.org>> wrote:
>>>
>>>     ? So, in summary, do I need to ensure cert serial numbers are
>>>     unique for my CA?
>>>
>>>     Why would you not?  The specifications require it, but those
>>>     specifications are for interoperability. If nobody is ever going
>>>     to see your certs, then who cares what?s in them?
>>>
>>>
>>> Well, I do like to abide by specs, and they will be used in various browsers, so I think I will continue the unique serial numbering.
>>>
>>> Thanks, Rich.
>> Modern browsers increasingly presume that such private CAs behave exactly
>> like the public CAs regulated through the CA/Browsers Forum (CAB/F) and
>> the per-browser root CA inclusion programs (the administrative processes
>> that determine which CAs are listed in browsers by default).
>>
>> Among the relevant requirements now needed:
>>
>> - Serial numbers are *exactly* 20 bytes (153 to 159 bits) both as standalone
>> numbers and as DER-encoded numbers.  Note that this is not the default in
>> the openssl ca program.
> There?s no such requirement. It MUST be at most 20 octets long.
>
>> - Serial numbers contain cryptographically strong random bits, currently at
>> least 64 random bits, though it is best if the entire serial number looks
>> random from the outside.  This is not implemented by the openssl ca program.
> It can be easily done by an external script. Generate a secret key for your CA for a 128bits block cipher, keep the monotonic counter, but instead of putting the value of the counter in the serial number, encrypt the counter with the key+cipher, and use the resulting cipher text as the serial number. Of course, increment the counter.
>
>> - Certificates are valid for at most 2 years (actually 825 days).
>>
>> - SHA-1 (and other weak algorithms such as MD5) are no longer permitted and
>> is already disappearing from Browser code.
>>
>> - RSA shorter than 2048 bits (and other weak settings such as equally short
>> DSA keys) are no longer permitted and is already disappearing from Browser
>> code.
>>
>> - If the certificate is issued to an e-mail address, that e-mail address must
>> also be listed as an rfc822Name in a "Subject Alternative Name" certificate
>> extension.
>>
>> - End user certificates must be issued from an Intermediary CA whose
>> certificate is is in turn issued from a longer term root CA.
> I doubt browsers impose this on purely private CAs.

But it is easy to do, and it allows you to store your root CA totally 
offline.  Like on a mSD in a firebox (I am writing this into my guide).  
It also gives you flexibility to add another leaf for other sorts of 
devices/usages.

For an RSA guide see:

https://jamielinux.com/docs/openssl-certificate-authority/introduction.html

For a roughish ECDSA guide see my recent effort:

http://www.htt-consult.com/pki.html  # this will be evolving as I add 
more in (like looking into your seqNum recommendation).

>
>> - If revocation is implemented (it should be, just in case someone gets their
>> computer or other key storage hacked/stolen), it needs to support OCSP, but
>> should ideally do so without having the actual CA keys online (standard trick:
>> Issue 3-month non-revocable OCSP-signing certificates and provide the
>> corresponding private key to the server running the OCSP responder program).
>>   I would recommend to also implement traditional CRLs, since for smaller CAs
>> it is a better solution for browsers and servers that support it.
> Another requirement is that a TLS server certificate shall have its identity (FQDN) in the SAN extension. Use of the commonName attribute has been deprecated long ago.

Where is this documented?

thanks

Bob


From michel.sales at free.fr  Wed Aug 16 20:57:05 2017
From: michel.sales at free.fr (Michel)
Date: Wed, 16 Aug 2017 22:57:05 +0200
Subject: [openssl-users] Personal CA: are cert serial numbers critical?
In-Reply-To: <e8683482-24d7-2eca-8349-2575c95732cd@htt-consult.com>
References: <CAFMGiz__xQ24OjNoELomGaTUY2VvyCS9QzLXz=eXaG6B-X_YQA@mail.gmail.com>
 <A9BFA3C0-94D2-4966-AEB7-F0360443B82C@akamai.com>
 <CAFMGiz-b7NF9S5TK21_S5RY3mooagPpoghbk04AipQehoZcr1w@mail.gmail.com>
 <3f736c65-199b-5e6d-1096-29bc6e9da445@wisemo.com>
 <202F992A-3BDC-469F-A3D8-53A979B284B2@docusign.com>
 <e8683482-24d7-2eca-8349-2575c95732cd@htt-consult.com>
Message-ID: <002901d316d2$3848e180$a8daa480$@sales@free.fr>

>> Another requirement is that a TLS server certificate shall have its identity (FQDN) in the SAN extension. Use of the commonName attribute has been deprecated long ago.

> Where is this documented ?

Might be of interest : https://stackoverflow.com/questions/5935369/ssl-how-do-common-names-cn-and-subject-alternative-names-san-work-together



From rsalz at akamai.com  Wed Aug 16 21:01:40 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 16 Aug 2017 21:01:40 +0000
Subject: [openssl-users] Personal CA: are cert serial numbers critical?
In-Reply-To: <e8683482-24d7-2eca-8349-2575c95732cd@htt-consult.com>
References: <CAFMGiz__xQ24OjNoELomGaTUY2VvyCS9QzLXz=eXaG6B-X_YQA@mail.gmail.com>
 <A9BFA3C0-94D2-4966-AEB7-F0360443B82C@akamai.com>
 <CAFMGiz-b7NF9S5TK21_S5RY3mooagPpoghbk04AipQehoZcr1w@mail.gmail.com>
 <3f736c65-199b-5e6d-1096-29bc6e9da445@wisemo.com>
 <202F992A-3BDC-469F-A3D8-53A979B284B2@docusign.com>
 <e8683482-24d7-2eca-8349-2575c95732cd@htt-consult.com>
Message-ID: <A45648C2-6448-42E8-B8DF-2920E475B5F2@akamai.com>

> There?s no such requirement. It MUST be at most 20 octets long.
    >
    >> - Serial numbers contain cryptographically strong random bits, currently at
    >> least 64 random bits, though it is best if the entire serial number looks
    >> random from the outside.  This is not implemented by the openssl ca program.

Edit apps/apps.h to change SERIAL_RAND_BITS and use the ?create_serial flag.

I?ll be making a patch to do this more easily for master.

>Use of the commonName attribute has been deprecated long ago.
    
 >   Where is this documented?
   
RFC 2818 in 2000.  See aslo  https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/IGT2fLJrAeo



From rgm at htt-consult.com  Wed Aug 16 21:06:33 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Wed, 16 Aug 2017 17:06:33 -0400
Subject: [openssl-users] Personal CA: are cert serial numbers critical?
In-Reply-To: <A45648C2-6448-42E8-B8DF-2920E475B5F2@akamai.com>
References: <CAFMGiz__xQ24OjNoELomGaTUY2VvyCS9QzLXz=eXaG6B-X_YQA@mail.gmail.com>
 <A9BFA3C0-94D2-4966-AEB7-F0360443B82C@akamai.com>
 <CAFMGiz-b7NF9S5TK21_S5RY3mooagPpoghbk04AipQehoZcr1w@mail.gmail.com>
 <3f736c65-199b-5e6d-1096-29bc6e9da445@wisemo.com>
 <202F992A-3BDC-469F-A3D8-53A979B284B2@docusign.com>
 <e8683482-24d7-2eca-8349-2575c95732cd@htt-consult.com>
 <A45648C2-6448-42E8-B8DF-2920E475B5F2@akamai.com>
Message-ID: <c9de666f-8928-2829-b476-8c1d8b99d337@htt-consult.com>



On 08/16/2017 05:01 PM, Salz, Rich via openssl-users wrote:
>> There?s no such requirement. It MUST be at most 20 octets long.
>      >
>      >> - Serial numbers contain cryptographically strong random bits, currently at
>      >> least 64 random bits, though it is best if the entire serial number looks
>      >> random from the outside.  This is not implemented by the openssl ca program.
>
> Edit apps/apps.h to change SERIAL_RAND_BITS and use the ?create_serial flag.
>
> I?ll be making a patch to do this more easily for master.

So we will have to wait for the next release or build our own...

Will there be some option to control the behavior?

>
>> Use of the commonName attribute has been deprecated long ago.
>      
>   >   Where is this documented?
>     
> RFC 2818 in 2000.  See aslo  https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/IGT2fLJrAeo

No wonder I missed it.  My attention was off PKIX then as I was focused 
on HIP...

Bob


From rsalz at akamai.com  Wed Aug 16 21:12:08 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 16 Aug 2017 21:12:08 +0000
Subject: [openssl-users] Personal CA: are cert serial numbers critical?
In-Reply-To: <c9de666f-8928-2829-b476-8c1d8b99d337@htt-consult.com>
References: <CAFMGiz__xQ24OjNoELomGaTUY2VvyCS9QzLXz=eXaG6B-X_YQA@mail.gmail.com>
 <A9BFA3C0-94D2-4966-AEB7-F0360443B82C@akamai.com>
 <CAFMGiz-b7NF9S5TK21_S5RY3mooagPpoghbk04AipQehoZcr1w@mail.gmail.com>
 <3f736c65-199b-5e6d-1096-29bc6e9da445@wisemo.com>
 <202F992A-3BDC-469F-A3D8-53A979B284B2@docusign.com>
 <e8683482-24d7-2eca-8349-2575c95732cd@htt-consult.com>
 <A45648C2-6448-42E8-B8DF-2920E475B5F2@akamai.com>
 <c9de666f-8928-2829-b476-8c1d8b99d337@htt-consult.com>
Message-ID: <EE58398F-C0E7-4D2B-A5C3-6EFE8ABDEED9@akamai.com>

 
>    So we will have to wait for the next release or build our own...
  
Yes, as always.  Features go into the next release; fixes into existing ones.
  
>    Will there be some option to control the behavior?
  
Yes, like ?rand_serial or some such in the ca and x509 commands.


From rgm at htt-consult.com  Wed Aug 16 21:15:53 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Wed, 16 Aug 2017 17:15:53 -0400
Subject: [openssl-users] Personal CA: are cert serial numbers critical?
In-Reply-To: <A45648C2-6448-42E8-B8DF-2920E475B5F2@akamai.com>
References: <CAFMGiz__xQ24OjNoELomGaTUY2VvyCS9QzLXz=eXaG6B-X_YQA@mail.gmail.com>
 <A9BFA3C0-94D2-4966-AEB7-F0360443B82C@akamai.com>
 <CAFMGiz-b7NF9S5TK21_S5RY3mooagPpoghbk04AipQehoZcr1w@mail.gmail.com>
 <3f736c65-199b-5e6d-1096-29bc6e9da445@wisemo.com>
 <202F992A-3BDC-469F-A3D8-53A979B284B2@docusign.com>
 <e8683482-24d7-2eca-8349-2575c95732cd@htt-consult.com>
 <A45648C2-6448-42E8-B8DF-2920E475B5F2@akamai.com>
Message-ID: <d2077a6b-e566-07fa-45d4-89eefb275d98@htt-consult.com>



On 08/16/2017 05:01 PM, Salz, Rich via openssl-users wrote:
>> There?s no such requirement. It MUST be at most 20 octets long.
>      >
>      >> - Serial numbers contain cryptographically strong random bits, currently at
>      >> least 64 random bits, though it is best if the entire serial number looks
>      >> random from the outside.  This is not implemented by the openssl ca program.
>
> Edit apps/apps.h to change SERIAL_RAND_BITS and use the ?create_serial flag.
>
> I?ll be making a patch to do this more easily for master.
>
>> Use of the commonName attribute has been deprecated long ago.
>      
>   >   Where is this documented?
>     
> RFC 2818 in 2000.  See aslo  https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/IGT2fLJrAeo


OK.  NOW I remember those debates in the PKIX sessions...

Boy is THIS rattling some old brain cells!



From wouter.verhelst at fedict.be  Wed Aug 16 13:43:08 2017
From: wouter.verhelst at fedict.be (Wouter Verhelst)
Date: Wed, 16 Aug 2017 15:43:08 +0200
Subject: [openssl-users] Personal CA: are cert serial numbers critical?
In-Reply-To: <CAFMGiz__xQ24OjNoELomGaTUY2VvyCS9QzLXz=eXaG6B-X_YQA@mail.gmail.com>
References: <CAFMGiz__xQ24OjNoELomGaTUY2VvyCS9QzLXz=eXaG6B-X_YQA@mail.gmail.com>
Message-ID: <4263ae9c-b91e-baf3-2cd9-06940386f033@fedict.be>

On 16-08-17 15:24, Tom Browder wrote:
[...]
> I plan to tidy my automation before the issue of new certs, but I wonder
> how critical it is to ensure unique certificate serial numbers given
> that the certs are only used for us.  I'm not even sure I'll ever revoke
> any cert (they were issued to expire sometime in 2030).

You should revoke certificates when their private keys are compromised;
e.g., when the machine on which they were stored is stolen, lost, or
broken into by a remote attacker based on password guessing, user error,
social engineering, or something of the sorts. You aren't sure that any
of that will happen now, but usually people who are compromised never
expected that. Don't assume that just because they are
password-protected that they are safe; passwords will delay the
attacker, but not stop them.

To accomodate for that, you should generate the CRLs for your
certificates now, even if they're empty, and make sure that the software
you've configured to use your private CA are set up check the CRLs. That
way, when you become aware of a compromised private key of one of the
certificates, you don't need to hurry to reconfigure all those services,
but can simply revoke the certificate and possibly force critical
applications to reread the CRL (e.g., by restarting the service),
thereby turning a possibly full-day panicked "help I was compromised"
into a five-minute "certificate revoked, done" session.

> So, in summary, do I need to ensure cert serial numbers are unique for
> my CA?

Since CRLs expect that your serial numbers are unique, yes, you do need
to ensure that.

-- 
Wouter Verhelst

From aerowolf at gmail.com  Thu Aug 17 02:33:46 2017
From: aerowolf at gmail.com (Kyle Hamilton)
Date: Wed, 16 Aug 2017 19:33:46 -0700
Subject: [openssl-users] Personal CA: are cert serial numbers critical?
In-Reply-To: <CAFMGiz__xQ24OjNoELomGaTUY2VvyCS9QzLXz=eXaG6B-X_YQA@mail.gmail.com>
References: <CAFMGiz__xQ24OjNoELomGaTUY2VvyCS9QzLXz=eXaG6B-X_YQA@mail.gmail.com>
Message-ID: <CAPMEXDaAx17boawX1usZ9tJA6weNfe90AtYmUS-2EsDUt7BoDQ@mail.gmail.com>

Certificate serial numbers must be unique.  They need not be sequential or
increasing.  (Mozilla's NSS will complain and refuse to work if there are
duplicate serial numbers.)

I tend not to re-use keys, so I've found that putting 20 bytes (while
clearing the high bit) of a digest of the SubjectPublicKeyInfo as the
serial number works in that circumstance.  [if you leave the high bit set,
then DER mandates that it be encoded with a leading 0x00 byte, which makes
it 21 bytes... which can cause problems with things built for PKIX.]

-Kyle H

On Wed, Aug 16, 2017 at 6:24 AM, Tom Browder <tom.browder at gmail.com> wrote:

> Many years ago I started a CA for one group I manage for a private
> website, and now I want to update members' client certs for the stricter
> requirements for browsers.
>
> My original cert generation was entirely automated including the following:
>
> + CN for each is an e-mail address for the member
>
> + the passphrase for each member's cert is determined from a pre-generated
> list by me, it will not change
>
> I plan to tidy my automation before the issue of new certs, but I wonder
> how critical it is to ensure unique certificate serial numbers given that
> the certs are only used for us.  I'm not even sure I'll ever revoke any
> cert (they were issued to expire sometime in 2030).
>
> So, in summary, do I need to ensure cert serial numbers are unique for my
> CA?
>
> With warmest regards,
>
> -Tom
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170816/2ad04739/attachment.html>

From rgm at htt-consult.com  Thu Aug 17 04:28:52 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 17 Aug 2017 00:28:52 -0400
Subject: [openssl-users] Implementing deprecation of commonname and
	emailaddress
Message-ID: <c3f8cc53-7ffc-bc61-92bb-76963ab2ca9a@htt-consult.com>

I have skimmed through a few RFCs following today's postings and a few 
web sites.  It would seem to me that I should:

Remove commonName and emailAddress completely from the cnf file. They no 
longer belong in any cert, root or intermediate CA certs, server or user 
certs.

For servers include something like in the cnf file:

subjectAltName = DNS:www.example.com, DNS:example.com, DNS=localhost, 
EMAIL:postmaster at example.com

(That is all suppose to be on a single line in case your mail viewer 
wraps it).

Um, I can specify 'localhost' in this manner if I am on the server and 
connecting in the browser with https://localhost ??

And for clients:

subjectAltName = EMAIL:user at example.com

I am looking at how to build the above line using ENV variables. It is 
more a matter of how I do it than can I do it...

thanks for any advice

Bob


From noloader at gmail.com  Thu Aug 17 04:56:20 2017
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 17 Aug 2017 00:56:20 -0400
Subject: [openssl-users] Implementing deprecation of commonname and
	emailaddress
In-Reply-To: <c3f8cc53-7ffc-bc61-92bb-76963ab2ca9a@htt-consult.com>
References: <c3f8cc53-7ffc-bc61-92bb-76963ab2ca9a@htt-consult.com>
Message-ID: <CAH8yC8=mmfrokh7TxqQ1X7YVWEBUTh4Ma0uGwQJJvfAtjfU-_w@mail.gmail.com>

On Thu, Aug 17, 2017 at 12:28 AM, Robert Moskowitz <rgm at htt-consult.com> wrote:
> I have skimmed through a few RFCs following today's postings and a few web
> sites.  It would seem to me that I should:
>
> Remove commonName and emailAddress completely from the cnf file. They no
> longer belong in any cert, root or intermediate CA certs, server or user
> certs.

CommonName is supplied for viewing by tools like certificate viewers.
It should probably be a friendly name, like "Example Web Services".

Don't include hostnames in the CN. If you list it in the CN, then it
must be listed in the SAN, too. You must list it twice.

When you see a name like "example.com" in the CN, its usually a CA
including a domain name and not a hostname. It confusing for users and
user agents. I've seen user agents match a hostname based on the
domain name.

On the backend, there's usually a redirect for the domain example.com
to send user agents to a host like www.example.com. It happens up at
layer 7, not at layer 4.

> For servers include something like in the cnf file:
>
> subjectAltName = DNS:www.example.com, DNS:example.com, DNS=localhost,
> EMAIL:postmaster at example.com

Don't include an email address.

X.509 and PKIX certificates don't really have a proper field for email
addresses. That's why they get mashed into CommonName.

> (That is all suppose to be on a single line in case your mail viewer wraps
> it).
>
> Um, I can specify 'localhost' in this manner if I am on the server and
> connecting in the browser with https://localhost ??

Yes.

You can also put IP addresses there. The RFC's mostly allow it. The
CA/Browser Forum Baseline Requirements (CA/B BR) forbids it, but its
not clear (to me) what current browser behavior is.

For completeness, non-browser user agents, like wget and openssl,
follow the RFC standards and issuing policies. Browsers follow the
CA/B BR. That's why you often see browsers reject something accepted
by other user agents.

You might also be interested in
https://stackoverflow.com/questions/21297139/how-do-you-sign-certificate-signing-request-with-your-certification-authority/21340898#21340898
and https://stackoverflow.com/questions/10175812/how-to-create-a-self-signed-certificate-with-openssl.
They questions and answers reference about 6 different standards.

> And for clients:
>
> subjectAltName = EMAIL:user at example.com
>
> I am looking at how to build the above line using ENV variables. It is more
> a matter of how I do it than can I do it...

This is a whole 'nother can of worms. Also see
https://security.stackexchange.com/questions/62746/how-to-encode-a-username-in-pkix-certificate.

Jeff

From rgm at htt-consult.com  Thu Aug 17 13:09:12 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 17 Aug 2017 09:09:12 -0400
Subject: [openssl-users] Implementing deprecation of commonname and
 emailaddress
In-Reply-To: <CAH8yC8=mmfrokh7TxqQ1X7YVWEBUTh4Ma0uGwQJJvfAtjfU-_w@mail.gmail.com>
References: <c3f8cc53-7ffc-bc61-92bb-76963ab2ca9a@htt-consult.com>
 <CAH8yC8=mmfrokh7TxqQ1X7YVWEBUTh4Ma0uGwQJJvfAtjfU-_w@mail.gmail.com>
Message-ID: <88641674-0807-9d75-ac33-85eac0af3584@htt-consult.com>



On 08/17/2017 12:56 AM, Jeffrey Walton wrote:
> On Thu, Aug 17, 2017 at 12:28 AM, Robert Moskowitz <rgm at htt-consult.com> wrote:
>> I have skimmed through a few RFCs following today's postings and a few web
>> sites.  It would seem to me that I should:
>>
>> Remove commonName and emailAddress completely from the cnf file. They no
>> longer belong in any cert, root or intermediate CA certs, server or user
>> certs.
> CommonName is supplied for viewing by tools like certificate viewers.
> It should probably be a friendly name, like "Example Web Services".
>
> Don't include hostnames in the CN. If you list it in the CN, then it
> must be listed in the SAN, too. You must list it twice.
>
> When you see a name like "example.com" in the CN, its usually a CA
> including a domain name and not a hostname. It confusing for users and
> user agents. I've seen user agents match a hostname based on the
> domain name.
>
> On the backend, there's usually a redirect for the domain example.com
> to send user agents to a host like www.example.com. It happens up at
> layer 7, not at layer 4.

So commonName does make some sense, for those that want to verbosely 
define the name.  But not for fqdns.

>
>> For servers include something like in the cnf file:
>>
>> subjectAltName = DNS:www.example.com, DNS:example.com, DNS=localhost,
>> EMAIL:postmaster at example.com
> Don't include an email address.
>
> X.509 and PKIX certificates don't really have a proper field for email
> addresses. That's why they get mashed into CommonName.

I have looked through a lot of rfcs and do not see this.  If you mean a 
full email address like

Jeffrey Walton <noloader at gmail.com>

I see that.  And it explains the mashing you see when you display the 
subjectName:

CN=www.htt-consult.com/emailAddress=admin at htt-consult.com

Yes, I now know I should not have put the fqdn in there....

But

subjectAltName      = email:hostmaster at example.org

Clearly is a valid rfc822name and is a proper email address for server 
contact and even user certs.

So why do you recommend NOT putting email address in SAN when so many 
others DO recommend it.  Is there some clear directive from some forum 
(CA/B BR)?  And it seems this is how Microsoft encodes email addresses 
(but not user names, see below).

>
>> (That is all suppose to be on a single line in case your mail viewer wraps
>> it).
>>
>> Um, I can specify 'localhost' in this manner if I am on the server and
>> connecting in the browser with https://localhost ??
> Yes.
>
> You can also put IP addresses there. The RFC's mostly allow it. The
> CA/Browser Forum Baseline Requirements (CA/B BR) forbids it, but its
> not clear (to me) what current browser behavior is.
>
> For completeness, non-browser user agents, like wget and openssl,
> follow the RFC standards and issuing policies. Browsers follow the
> CA/B BR. That's why you often see browsers reject something accepted
> by other user agents.
>
> You might also be interested in
> https://stackoverflow.com/questions/21297139/how-do-you-sign-certificate-signing-request-with-your-certification-authority/21340898#21340898
> and https://stackoverflow.com/questions/10175812/how-to-create-a-self-signed-certificate-with-openssl.
> They questions and answers reference about 6 different standards.
>
>> And for clients:
>>
>> subjectAltName = EMAIL:user at example.com
>>
>> I am looking at how to build the above line using ENV variables. It is more
>> a matter of how I do it than can I do it...
> This is a whole 'nother can of worms. Also see
> https://security.stackexchange.com/questions/62746/how-to-encode-a-username-in-pkix-certificate.

Fun read.  Since I am not striving for MS coordination, and so far I 
have not dove into LDAP issues, I would go for DN/UID added to the user 
cnf file.

thanks

Bob


From rgm at htt-consult.com  Thu Aug 17 13:20:52 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 17 Aug 2017 09:20:52 -0400
Subject: [openssl-users] keyusage digitalSignature in CA certs
Message-ID: <4efb5c1a-ad92-d335-6504-a308005ed8d8@htt-consult.com>

Should digitalSignature be included in keyusage in CA certs?


https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html

Includes it.

https://stackoverflow.com/questions/21297139/how-do-you-sign-certificate-signing-request-with-your-certification-authority/21340898#21340898

Does not include it.

It seems to make a root or intermediate CA be able to have more purposes 
than it should?  e.g.

SSL client : Yes
SSL server : Yes
S/MIME signing : Yes

So which is the right for a CA's key usage?

thanks

Bob


From uri at ll.mit.edu  Thu Aug 17 13:32:39 2017
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Thu, 17 Aug 2017 13:32:39 +0000
Subject: [openssl-users] keyusage digitalSignature in CA certs
In-Reply-To: <4efb5c1a-ad92-d335-6504-a308005ed8d8@htt-consult.com>
References: <4efb5c1a-ad92-d335-6504-a308005ed8d8@htt-consult.com>
Message-ID: <24DDF48A-43C7-43D5-8DA5-FBABD2EA3E99@ll.mit.edu>

AFAIK it must.

Regards,
Uri

Sent from my iPhone

> On Aug 17, 2017, at 09:21, Robert Moskowitz <rgm at htt-consult.com> wrote:
> 
> Should digitalSignature be included in keyusage in CA certs?
> 
> 
> https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html
> 
> Includes it.
> 
> https://stackoverflow.com/questions/21297139/how-do-you-sign-certificate-signing-request-with-your-certification-authority/21340898#21340898
> 
> Does not include it.
> 
> It seems to make a root or intermediate CA be able to have more purposes than it should?  e.g.
> 
> SSL client : Yes
> SSL server : Yes
> S/MIME signing : Yes
> 
> So which is the right for a CA's key usage?
> 
> thanks
> 
> Bob
> 
> -- 
> 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: 4223 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170817/6c13267a/attachment-0001.bin>

From Erwann.Abalea at docusign.com  Thu Aug 17 13:50:46 2017
From: Erwann.Abalea at docusign.com (Erwann Abalea)
Date: Thu, 17 Aug 2017 13:50:46 +0000
Subject: [openssl-users] keyusage digitalSignature in CA certs
In-Reply-To: <4efb5c1a-ad92-d335-6504-a308005ed8d8@htt-consult.com>
References: <4efb5c1a-ad92-d335-6504-a308005ed8d8@htt-consult.com>
Message-ID: <D83A2816-5269-4686-B3EC-F51A56F98DE9@docusign.com>

Bonjour,

> Le 17 ao?t 2017 ? 15:20, Robert Moskowitz <rgm at htt-consult.com> a ?crit :
> 
> Should digitalSignature be included in keyusage in CA certs?

It depends on what you plan to do with the corresponding private key.
If you want this private key to sign messages other than certificates and CRLs (such as OCSP responses), then yes.

> 
> https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html
> 
> Includes it.
> 
> https://stackoverflow.com/questions/21297139/how-do-you-sign-certificate-signing-request-with-your-certification-authority/21340898#21340898
> 
> Does not include it.
> 
> It seems to make a root or intermediate CA be able to have more purposes than it should?  e.g.
> 
> SSL client : Yes
> SSL server : Yes
> S/MIME signing : Yes

This is the result of an analysis of the keyUsage *and* the extendedKeyUsage extensions (and maybe obsolete Netscape proprietary ones).

> So which is the right for a CA's key usage?

That really depends on what you want it to be valid for.

keyUsage=keyCertSign is fine for certificate signing
keyUsage=cRLSign is fine for CRL signing
keyUsage=digitalSignature is fine for OCSP signing

The other bits are not that common for a CA.

You can achieve the capabilities with different certificates.

For example, a keyCertSign-only CA cert can self-issue a cRLSign certificate in order to produce CRLs and a digitalSignature certificate to sign OCSP responses, or an issuing CA can issue different certificates for the same CA (they all have the same Subject, which is different from the issuing?s Subject) but for different purposes (and thus different keyUsage bits).

Cordialement,
Erwann Abalea


From rgm at htt-consult.com  Thu Aug 17 13:58:21 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 17 Aug 2017 09:58:21 -0400
Subject: [openssl-users] keyusage digitalSignature in CA certs
In-Reply-To: <D83A2816-5269-4686-B3EC-F51A56F98DE9@docusign.com>
References: <4efb5c1a-ad92-d335-6504-a308005ed8d8@htt-consult.com>
 <D83A2816-5269-4686-B3EC-F51A56F98DE9@docusign.com>
Message-ID: <c0729ecc-c4e1-b612-e2ce-27c32d9ce635@htt-consult.com>

Thank you for your response.

I am basically skipping 20 years of PKI development and trying to get to 
current best practices...

On 08/17/2017 09:50 AM, Erwann Abalea via openssl-users wrote:
> Bonjour,
>
>> Le 17 ao?t 2017 ? 15:20, Robert Moskowitz <rgm at htt-consult.com> a ?crit :
>>
>> Should digitalSignature be included in keyusage in CA certs?
> It depends on what you plan to do with the corresponding private key.
> If you want this private key to sign messages other than certificates and CRLs (such as OCSP responses), then yes.

Got it and your follow-on points.

Again, thank you.

>
>> https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html
>>
>> Includes it.
>>
>> https://stackoverflow.com/questions/21297139/how-do-you-sign-certificate-signing-request-with-your-certification-authority/21340898#21340898
>>
>> Does not include it.
>>
>> It seems to make a root or intermediate CA be able to have more purposes than it should?  e.g.
>>
>> SSL client : Yes
>> SSL server : Yes
>> S/MIME signing : Yes
> This is the result of an analysis of the keyUsage *and* the extendedKeyUsage extensions (and maybe obsolete Netscape proprietary ones).
>
>> So which is the right for a CA's key usage?
> That really depends on what you want it to be valid for.
>
> keyUsage=keyCertSign is fine for certificate signing
> keyUsage=cRLSign is fine for CRL signing
> keyUsage=digitalSignature is fine for OCSP signing
>
> The other bits are not that common for a CA.
>
> You can achieve the capabilities with different certificates.
>
> For example, a keyCertSign-only CA cert can self-issue a cRLSign certificate in order to produce CRLs and a digitalSignature certificate to sign OCSP responses, or an issuing CA can issue different certificates for the same CA (they all have the same Subject, which is different from the issuing?s Subject) but for different purposes (and thus different keyUsage bits).
>
> Cordialement,
> Erwann Abalea
>


From rgm at htt-consult.com  Thu Aug 17 14:40:47 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 17 Aug 2017 10:40:47 -0400
Subject: [openssl-users] More on cert serialnumbers
Message-ID: <0e3970f1-8b7d-0d72-9adf-fa6bad16bdf7@htt-consult.com>

I have been researching serial number in cert based on Jakob's comment:

"- Serial numbers are *exactly* 20 bytes (153 to 159 bits) both as 
standalone
  numbers and as DER-encoded numbers.  Note that this is not the default in
  the openssl ca program.

- Serial numbers contain cryptographically strong random bits, currently at
  least 64 random bits, though it is best if the entire serial number looks
  random from the outside.  This is not implemented by the openssl ca 
program."

And this is supposedly from the CA/B BF?

Though Erwann responded:

"There?s no such requirement. It MUST be at most 20 octets long"

I see how for all certs other than the root (get to that later), I can 
control this with:

openssl rand -hex 20 > serial

then use 'openssl ca ...'

But from Kyle's comment, the first bit must be ZERO.

"I tend not to re-use keys, so I've found that putting 20 bytes (while 
clearing the high bit) of a digest of the SubjectPublicKeyInfo as the 
serial number works in that circumstance.  [if you leave the high bit 
set, then DER mandates that it be encoded with a leading 0x00 byte, 
which makes it 21 bytes... which can cause problems with things built 
for PKIX.]"

Will that be the case with the above 'openssl rand', or is there some 
other step needed to zero out the first bit.

And is the openssl rand function 'safe' to use?  Is it cryptographically 
strong?

As for the root cert created with 'openssl req ... -new -x509', it seems 
that a random 8 octet serial number is provided.  Is there a way to 
boost that to 20 octects?  Does it matter per Erwann's comment above?

Actually, I am trying to keep certs small, and the CAs I picture are not 
for millions of certs  Smaller serial number size would be the preferred 
situation...

thanks

Bob


From rsalz at akamai.com  Thu Aug 17 14:45:15 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 17 Aug 2017 14:45:15 +0000
Subject: [openssl-users] More on cert serialnumbers
In-Reply-To: <0e3970f1-8b7d-0d72-9adf-fa6bad16bdf7@htt-consult.com>
References: <0e3970f1-8b7d-0d72-9adf-fa6bad16bdf7@htt-consult.com>
Message-ID: <31CE1282-7267-4FF5-9B7B-C1A3407757E5@akamai.com>

https://cabforum.org/2016/07/08/ballot-164/



From rsalz at akamai.com  Thu Aug 17 14:50:17 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 17 Aug 2017 14:50:17 +0000
Subject: [openssl-users] More on cert serialnumbers
In-Reply-To: <31CE1282-7267-4FF5-9B7B-C1A3407757E5@akamai.com>
References: <0e3970f1-8b7d-0d72-9adf-fa6bad16bdf7@htt-consult.com>
 <31CE1282-7267-4FF5-9B7B-C1A3407757E5@akamai.com>
Message-ID: <EB6DA4E4-8EB4-4C16-B059-BA9C8D515A6D@akamai.com>

And RFC 5280, which is still the standard, says serial# must be <= 20 bytes.  Which means, you want to make sure the high bit is off, else the DER encoding will make it 21 bytes.

So the new ?rand_serial flag I am adding to the CA command will make call RAND_bytes to get 18 bytes.


On 8/17/17, 10:45 AM, "Salz, Rich via openssl-users" <openssl-users at openssl.org> wrote:

    https://cabforum.org/2016/07/08/ballot-164/
    
    
    -- 
    openssl-users mailing list
    To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
    


From karl at denninger.net  Thu Aug 17 14:49:12 2017
From: karl at denninger.net (Karl Denninger)
Date: Thu, 17 Aug 2017 09:49:12 -0500
Subject: [openssl-users] More on cert serialnumbers
In-Reply-To: <0e3970f1-8b7d-0d72-9adf-fa6bad16bdf7@htt-consult.com>
References: <0e3970f1-8b7d-0d72-9adf-fa6bad16bdf7@htt-consult.com>
Message-ID: <17f462f7-0066-9b88-a7fb-30d933ea7dfb@denninger.net>



On 8/17/2017 09:40, Robert Moskowitz wrote:
> I have been researching serial number in cert based on Jakob's comment:
>
> "- Serial numbers are *exactly* 20 bytes (153 to 159 bits) both as
> standalone
>  numbers and as DER-encoded numbers.  Note that this is not the
> default in
>  the openssl ca program.
>
> - Serial numbers contain cryptographically strong random bits,
> currently at
>  least 64 random bits, though it is best if the entire serial number
> looks
>  random from the outside.  This is not implemented by the openssl ca
> program."
>
> And this is supposedly from the CA/B BF?
>
> Though Erwann responded:
>
> "There?s no such requirement. It MUST be at most 20 octets long"
>
> I see how for all certs other than the root (get to that later), I can
> control this with:
>
> openssl rand -hex 20 > serial
>
> then use 'openssl ca ...'
>
> But from Kyle's comment, the first bit must be ZERO.
So since the 20 octets is a maximum and not a requirement use -hex 19
instead, and if this results in DER placing a leading 0x00 byte you're
still ok.  This also complies with the ballot that Rich mentioned since
you have more entropy than required.

At least I think that meets the requirements....

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170817/6eca37a5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2993 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170817/6eca37a5/attachment-0001.bin>

From rgm at htt-consult.com  Thu Aug 17 15:10:00 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 17 Aug 2017 11:10:00 -0400
Subject: [openssl-users] More on cert serialnumbers
In-Reply-To: <EB6DA4E4-8EB4-4C16-B059-BA9C8D515A6D@akamai.com>
References: <0e3970f1-8b7d-0d72-9adf-fa6bad16bdf7@htt-consult.com>
 <31CE1282-7267-4FF5-9B7B-C1A3407757E5@akamai.com>
 <EB6DA4E4-8EB4-4C16-B059-BA9C8D515A6D@akamai.com>
Message-ID: <d6b6b9fa-7791-b9c6-8a67-b5143b78ff84@htt-consult.com>



On 08/17/2017 10:50 AM, Salz, Rich via openssl-users wrote:
> And RFC 5280, which is still the standard, says serial# must be <= 20 bytes.  Which means, you want to make sure the high bit is off, else the DER encoding will make it 21 bytes.
>
> So the new ?rand_serial flag I am adding to the CA command will make call RAND_bytes to get 18 bytes.
>
>
> On 8/17/17, 10:45 AM, "Salz, Rich via openssl-users" <openssl-users at openssl.org> wrote:
>
>      https://cabforum.org/2016/07/08/ballot-164/

?Effective September 30, 2016, CAs SHALL generate Certificate serial 
numbers greater than zero (0) containing at least 64 bits of output from 
a CSPRNG.?

What does "64 bits of output from a CSPRNG" mean here?  A 4 octet serial 
number is OK?  Or 2^64 bit serial number represented in HEX (how long is 
that?)

For now I will use:

openssl rand -hex 18 > serial

My reading on 'openssl rand' SEEMS to indicate it is cryptographically 
strong (provided you have entropy.  See:  cat 
/proc/sys/kernel/random/entropy_avail

For constrained IoT, I would like to use the smallest possible. Thus the 
clarifying the 64bit question above.

thanks

Bob


From openssl-users at dukhovni.org  Thu Aug 17 15:15:20 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 17 Aug 2017 15:15:20 +0000
Subject: [openssl-users] Implementing deprecation of commonname and
 emailaddress
In-Reply-To: <CAH8yC8=mmfrokh7TxqQ1X7YVWEBUTh4Ma0uGwQJJvfAtjfU-_w@mail.gmail.com>
References: <c3f8cc53-7ffc-bc61-92bb-76963ab2ca9a@htt-consult.com>
 <CAH8yC8=mmfrokh7TxqQ1X7YVWEBUTh4Ma0uGwQJJvfAtjfU-_w@mail.gmail.com>
Message-ID: <20170817151520.GC8146@mournblade.imrryr.org>

On Thu, Aug 17, 2017 at 12:56:20AM -0400, Jeffrey Walton wrote:

> > Remove commonName and emailAddress completely from the cnf file. They no
> > longer belong in any cert, root or intermediate CA certs, server or user
> > certs.
> 
> CommonName is supplied for viewing by tools like certificate viewers.
> It should probably be a friendly name, like "Example Web Services".

RFC 5280 suggests an empty subject DN with all the desired names
in the the subject alt name extension.

> When you see a name like "example.com" in the CN, its usually a CA
> including a domain name and not a hostname.

That's nonsense.

> > For servers include something like in the cnf file:
> >
> > subjectAltName = DNS:www.example.com, DNS:example.com, DNS=localhost,
> > EMAIL:postmaster at example.com
> 
> Don't include an email address.

That is, don't incude unless the certificate is intended for S/MIME.

> X.509 and PKIX certificates don't really have a proper field for email
> addresses. That's why they get mashed into CommonName.

They sure do, that what's rfc822Name is for in the subject alt name
extenstion.  It supports S/MIME certificates.  There's even recent
work (soon to be an RFC) to internationalize this with SmtpUTF8Name...

> > Um, I can specify 'localhost' in this manner if I am on the server and
> > connecting in the browser with https://localhost ??
> 
> Yes.

You can, but it is not a good idea.  Since that "localhost" will
then work on every host that trusts the issuing CA.  The only way
to make this reasonably secure is to have a per-host issuing CA
that's only trusted on *that* host, and *that* CA can then issue
the "localhost" certificate.  All the hosts can additionally
trust other shared CAs.

> > I am looking at how to build the above line using ENV variables. It is more
> > a matter of how I do it than can I do it...

The tricky bit is creating a variable number of SAN elements, I don't
know how to do that with just environment variables.  Sometimes building
a config file on the fly is the way to go.

-- 
	Viktor.

From rgm at htt-consult.com  Thu Aug 17 15:15:54 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 17 Aug 2017 11:15:54 -0400
Subject: [openssl-users] More on cert serialnumbers
In-Reply-To: <17f462f7-0066-9b88-a7fb-30d933ea7dfb@denninger.net>
References: <0e3970f1-8b7d-0d72-9adf-fa6bad16bdf7@htt-consult.com>
 <17f462f7-0066-9b88-a7fb-30d933ea7dfb@denninger.net>
Message-ID: <8c14d2c2-c462-9a21-695b-6d1f5ad7de66@htt-consult.com>



On 08/17/2017 10:49 AM, Karl Denninger wrote:
>
>
> On 8/17/2017 09:40, Robert Moskowitz wrote:
>> I have been researching serial number in cert based on Jakob's comment:
>>
>> "- Serial numbers are *exactly* 20 bytes (153 to 159 bits) both as 
>> standalone
>>  numbers and as DER-encoded numbers.  Note that this is not the 
>> default in
>>  the openssl ca program.
>>
>> - Serial numbers contain cryptographically strong random bits, 
>> currently at
>>  least 64 random bits, though it is best if the entire serial number 
>> looks
>>  random from the outside.  This is not implemented by the openssl ca 
>> program."
>>
>> And this is supposedly from the CA/B BF?
>>
>> Though Erwann responded:
>>
>> "There?s no such requirement. It MUST be at most 20 octets long"
>>
>> I see how for all certs other than the root (get to that later), I 
>> can control this with:
>>
>> openssl rand -hex 20 > serial
>>
>> then use 'openssl ca ...'
>>
>> But from Kyle's comment, the first bit must be ZERO.
> So since the 20 octets is a maximum and not a requirement use -hex 19 
> instead, and if this results in DER placing a leading 0x00 byte you're 
> still ok.  This also complies with the ballot that Rich mentioned 
> since you have more entropy than required.
>
> At least I think that meets the requirements....

And 19 is more than 18!  And the first time I tried this I got:

a2b7499f19b3b7b4a54ccd2036d59a4a906756

And the 2nd time I tried with 20:

f7f01d018605411c8788a82e465d7991d574b08f

So that first bit can really be a problem.  Probably about 1/2 the time!  :)

Bob


From noloader at gmail.com  Thu Aug 17 15:26:33 2017
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 17 Aug 2017 11:26:33 -0400
Subject: [openssl-users] Implementing deprecation of commonname and
	emailaddress
In-Reply-To: <20170817151520.GC8146@mournblade.imrryr.org>
References: <c3f8cc53-7ffc-bc61-92bb-76963ab2ca9a@htt-consult.com>
 <CAH8yC8=mmfrokh7TxqQ1X7YVWEBUTh4Ma0uGwQJJvfAtjfU-_w@mail.gmail.com>
 <20170817151520.GC8146@mournblade.imrryr.org>
Message-ID: <CAH8yC8ndFsOXKVneM8FjRyWw7q05Z2vTZfqDu01uHhYg8xfR2w@mail.gmail.com>

>> When you see a name like "example.com" in the CN, its usually a CA
>> including a domain name and not a hostname.
>
> That's nonsense.

If a certificate is issued under CA/B policies, and CN=example.com but
it _lacks_ SAN=example.com, then its a not a hostname and it should
not be matched.

I'm aware of OpenSSL's behavior in the matter. But OpenSSL does not
understand issuing policies so its easy to confuse.

Forgive me if OpenSSL is now imbued with knowledge of issuing policies
and how matching should occur outside of the RFCs.

Jeff

From rgm at htt-consult.com  Thu Aug 17 15:28:33 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 17 Aug 2017 11:28:33 -0400
Subject: [openssl-users] Implementing deprecation of commonname and
 emailaddress
In-Reply-To: <20170817151520.GC8146@mournblade.imrryr.org>
References: <c3f8cc53-7ffc-bc61-92bb-76963ab2ca9a@htt-consult.com>
 <CAH8yC8=mmfrokh7TxqQ1X7YVWEBUTh4Ma0uGwQJJvfAtjfU-_w@mail.gmail.com>
 <20170817151520.GC8146@mournblade.imrryr.org>
Message-ID: <2a1a8e6a-f259-cb64-62f6-25c37e65844e@htt-consult.com>

Viktor,

thanks for the reply.

On 08/17/2017 11:15 AM, Viktor Dukhovni wrote:
> On Thu, Aug 17, 2017 at 12:56:20AM -0400, Jeffrey Walton wrote:
>
>>> Remove commonName and emailAddress completely from the cnf file. They no
>>> longer belong in any cert, root or intermediate CA certs, server or user
>>> certs.
>> CommonName is supplied for viewing by tools like certificate viewers.
>> It should probably be a friendly name, like "Example Web Services".
> RFC 5280 suggests an empty subject DN with all the desired names
> in the the subject alt name extension.
>
>> When you see a name like "example.com" in the CN, its usually a CA
>> including a domain name and not a hostname.
> That's nonsense.
>
>>> For servers include something like in the cnf file:
>>>
>>> subjectAltName = DNS:www.example.com, DNS:example.com, DNS=localhost,
>>> EMAIL:postmaster at example.com
>> Don't include an email address.
> That is, don't incude unless the certificate is intended for S/MIME.

Or to provide an easy way to contact the server admin if there is a 
problem/question with the cert?  Even without S/MIME?

>
>> X.509 and PKIX certificates don't really have a proper field for email
>> addresses. That's why they get mashed into CommonName.
> They sure do, that what's rfc822Name is for in the subject alt name
> extenstion.  It supports S/MIME certificates.  There's even recent
> work (soon to be an RFC) to internationalize this with SmtpUTF8Name...

That is what I thought, too.  Just not the full email format like:

Viktor Dukhovni <openssl-users at dukhovni.org>

>
>>> Um, I can specify 'localhost' in this manner if I am on the server and
>>> connecting in the browser with https://localhost ??
>> Yes.
> You can, but it is not a good idea.  Since that "localhost" will
> then work on every host that trusts the issuing CA.  The only way
> to make this reasonably secure is to have a per-host issuing CA
> that's only trusted on *that* host, and *that* CA can then issue
> the "localhost" certificate.  All the hosts can additionally
> trust other shared CAs.

So better to provide a self-signed cert if a server is going to be 
accessed from a browser on the server via https://localhost

>
>>> I am looking at how to build the above line using ENV variables. It is more
>>> a matter of how I do it than can I do it...
> The tricky bit is creating a variable number of SAN elements, I don't
> know how to do that with just environment variables.  Sometimes building
> a config file on the fly is the way to go.
>
The simplest that I have come up with is:

export SAN = "DNS:example.com, DNS:www.example.com, 
EMAIL:postmaster at example.com"

and in the cnf

subjectAltName = $SAN

I think.   I am not yet up to testing this....

Bob


From Erwann.Abalea at docusign.com  Thu Aug 17 15:29:56 2017
From: Erwann.Abalea at docusign.com (Erwann Abalea)
Date: Thu, 17 Aug 2017 15:29:56 +0000
Subject: [openssl-users] More on cert serialnumbers
In-Reply-To: <d6b6b9fa-7791-b9c6-8a67-b5143b78ff84@htt-consult.com>
References: <0e3970f1-8b7d-0d72-9adf-fa6bad16bdf7@htt-consult.com>
 <31CE1282-7267-4FF5-9B7B-C1A3407757E5@akamai.com>
 <EB6DA4E4-8EB4-4C16-B059-BA9C8D515A6D@akamai.com>
 <d6b6b9fa-7791-b9c6-8a67-b5143b78ff84@htt-consult.com>
Message-ID: <4916C3E6-9105-47C9-903B-F96698C7692B@docusign.com>

Bonjour,

> Le 17 ao?t 2017 ? 17:10, Robert Moskowitz <rgm at htt-consult.com> a ?crit :
> 
> 
> 
> On 08/17/2017 10:50 AM, Salz, Rich via openssl-users wrote:
>> And RFC 5280, which is still the standard, says serial# must be <= 20 bytes.  Which means, you want to make sure the high bit is off, else the DER encoding will make it 21 bytes.
>> 
>> So the new ?rand_serial flag I am adding to the CA command will make call RAND_bytes to get 18 bytes.
>> 
>> 
>> On 8/17/17, 10:45 AM, "Salz, Rich via openssl-users" <openssl-users at openssl.org> wrote:
>> 
>>     https://cabforum.org/2016/07/08/ballot-164/
> 
> ?Effective September 30, 2016, CAs SHALL generate Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG.?
> 
> What does "64 bits of output from a CSPRNG" mean here?  A 4 octet serial number is OK?  Or 2^64 bit serial number represented in HEX (how long is that?)

That means that the serial number SHALL be at least 64 bits (8 octets) long, and at least 64 of the bits of the serial number come from a cryptographically strong pseudo random number generator.

The BR are for public CAs, not private CAs; even if some of those requirements are considered ? good practice ? (the 64 bits out of a CSPRNG is such a req), they cannot be forced on private CAs.
And unless some or all of the browsers also apply these requirements to private CAs, you?re not forced to follow them all.

The 20 octets max comes from RFC5280, keep it.
MD4/MD5/SHA1 forbidden, lets abandon obsolete crypto (non-collision resistant anymore).
The 64 bits from a CSPRNG is a tradeoff allowing the use of a non-collision-resistant hash function for slightly longer for transition periods, it?s nice if you can easily follow it, but browsers probably won?t enforce it.
The 2048bits minimum RSA key is really a good practice and shouldn?t be left over. Switch to ECDSA if your target permits it.
The CN deprecation and use of SAN:dNSName instead is a target of some browsers for private CAs; it may require more work for you, but there?s a benefit. CN has been populated with too much garbage (FQDN, domain, service name, IP address, person name, ?), the SAN extension has nice baskets to put your eggs in (dNSName and iPAddress), and it works beautifully with NameConstraints.

Cordialement,
Erwann Abalea


From Erwann.Abalea at docusign.com  Thu Aug 17 15:34:29 2017
From: Erwann.Abalea at docusign.com (Erwann Abalea)
Date: Thu, 17 Aug 2017 15:34:29 +0000
Subject: [openssl-users] Implementing deprecation of commonname
	and	emailaddress
In-Reply-To: <CAH8yC8ndFsOXKVneM8FjRyWw7q05Z2vTZfqDu01uHhYg8xfR2w@mail.gmail.com>
References: <c3f8cc53-7ffc-bc61-92bb-76963ab2ca9a@htt-consult.com>
 <CAH8yC8=mmfrokh7TxqQ1X7YVWEBUTh4Ma0uGwQJJvfAtjfU-_w@mail.gmail.com>
 <20170817151520.GC8146@mournblade.imrryr.org>
 <CAH8yC8ndFsOXKVneM8FjRyWw7q05Z2vTZfqDu01uHhYg8xfR2w@mail.gmail.com>
Message-ID: <4B75F50D-F8D9-4CDC-8DBB-7B49463CC94C@docusign.com>


> Le 17 ao?t 2017 ? 17:26, Jeffrey Walton <noloader at gmail.com> a ?crit :
> 
>>> When you see a name like "example.com" in the CN, its usually a CA
>>> including a domain name and not a hostname.
>> 
>> That's nonsense.
> 
> If a certificate is issued under CA/B policies, and CN=example.com but
> it _lacks_ SAN=example.com, then its a not a hostname and it should
> not be matched.

Such a certificate would be mis-issued and be revoked immediately. CN MUST be an FQDN (or a wild carded FQDN, or an IP address), and a copy of the value in CN MUST be present in the SAN extension.

Cordialement,
Erwann Abalea


From noloader at gmail.com  Thu Aug 17 15:36:01 2017
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 17 Aug 2017 11:36:01 -0400
Subject: [openssl-users] Implementing deprecation of commonname and
	emailaddress
In-Reply-To: <4B75F50D-F8D9-4CDC-8DBB-7B49463CC94C@docusign.com>
References: <c3f8cc53-7ffc-bc61-92bb-76963ab2ca9a@htt-consult.com>
 <CAH8yC8=mmfrokh7TxqQ1X7YVWEBUTh4Ma0uGwQJJvfAtjfU-_w@mail.gmail.com>
 <20170817151520.GC8146@mournblade.imrryr.org>
 <CAH8yC8ndFsOXKVneM8FjRyWw7q05Z2vTZfqDu01uHhYg8xfR2w@mail.gmail.com>
 <4B75F50D-F8D9-4CDC-8DBB-7B49463CC94C@docusign.com>
Message-ID: <CAH8yC8m9zmZQi8k-xe+SpzLdGSD9DKzh-+RXkaXdBdrCJP1irg@mail.gmail.com>

On Thu, Aug 17, 2017 at 11:34 AM, Erwann Abalea
<Erwann.Abalea at docusign.com> wrote:
>
>> Le 17 ao?t 2017 ? 17:26, Jeffrey Walton <noloader at gmail.com> a ?crit :
>>
>>>> When you see a name like "example.com" in the CN, its usually a CA
>>>> including a domain name and not a hostname.
>>>
>>> That's nonsense.
>>
>> If a certificate is issued under CA/B policies, and CN=example.com but
>> it _lacks_ SAN=example.com, then its a not a hostname and it should
>> not be matched.
>
> Such a certificate would be mis-issued and be revoked immediately. CN MUST be an FQDN (or a wild carded FQDN, or an IP address), and a copy of the value in CN MUST be present in the SAN extension.

Oh, you would have some fun watching how various user agents handle
that scenario. For your first stop, check out how OpenSSL handles it.

Jeff

From rgm at htt-consult.com  Thu Aug 17 15:41:07 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 17 Aug 2017 11:41:07 -0400
Subject: [openssl-users] More on cert serialnumbers
In-Reply-To: <4916C3E6-9105-47C9-903B-F96698C7692B@docusign.com>
References: <0e3970f1-8b7d-0d72-9adf-fa6bad16bdf7@htt-consult.com>
 <31CE1282-7267-4FF5-9B7B-C1A3407757E5@akamai.com>
 <EB6DA4E4-8EB4-4C16-B059-BA9C8D515A6D@akamai.com>
 <d6b6b9fa-7791-b9c6-8a67-b5143b78ff84@htt-consult.com>
 <4916C3E6-9105-47C9-903B-F96698C7692B@docusign.com>
Message-ID: <8d74634a-552d-0f44-eeee-8e8ca53a50cb@htt-consult.com>

Erwann,

thank you for your response.

On 08/17/2017 11:29 AM, Erwann Abalea via openssl-users wrote:
> Bonjour,
>
>> Le 17 ao?t 2017 ? 17:10, Robert Moskowitz <rgm at htt-consult.com> a ?crit :
>>
>>
>>
>> On 08/17/2017 10:50 AM, Salz, Rich via openssl-users wrote:
>>> And RFC 5280, which is still the standard, says serial# must be <= 20 bytes.  Which means, you want to make sure the high bit is off, else the DER encoding will make it 21 bytes.
>>>
>>> So the new ?rand_serial flag I am adding to the CA command will make call RAND_bytes to get 18 bytes.
>>>
>>>
>>> On 8/17/17, 10:45 AM, "Salz, Rich via openssl-users" <openssl-users at openssl.org> wrote:
>>>
>>>      https://cabforum.org/2016/07/08/ballot-164/
>> ?Effective September 30, 2016, CAs SHALL generate Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG.?
>>
>> What does "64 bits of output from a CSPRNG" mean here?  A 4 octet serial number is OK?  Or 2^64 bit serial number represented in HEX (how long is that?)
> That means that the serial number SHALL be at least 64 bits (8 octets) long, and at least 64 of the bits of the serial number come from a cryptographically strong pseudo random number generator.

ARGH!  Octets, not Hex!  :)


> The BR are for public CAs, not private CAs; even if some of those requirements are considered ? good practice ? (the 64 bits out of a CSPRNG is such a req), they cannot be forced on private CAs.
> And unless some or all of the browsers also apply these requirements to private CAs, you?re not forced to follow them all.

This may get interesting for some IoT situations.  The client certs 
would be used in protocols like CoAP (DTLS), but the server would be 
used by both the IoT clients and standard browsers.  If this were for a 
'smartcity' situation, the CA is probably public...

> The 20 octets max comes from RFC5280, keep it.

Think we got that.

> MD4/MD5/SHA1 forbidden, lets abandon obsolete crypto (non-collision resistant anymore).
> The 64 bits from a CSPRNG is a tradeoff allowing the use of a non-collision-resistant hash function for slightly longer for transition periods, it?s nice if you can easily follow it, but browsers probably won?t enforce it.
> The 2048bits minimum RSA key is really a good practice and shouldn?t be left over. Switch to ECDSA if your target permits it.

All my work on this project is ECDSA P-256 and I am chomping at the bit, 
so to speak, for Ed25519...

> The CN deprecation and use of SAN:dNSName instead is a target of some browsers for private CAs; it may require more work for you, but there?s a benefit. CN has been populated with too much garbage (FQDN, domain, service name, IP address, person name, ?), the SAN extension has nice baskets to put your eggs in (dNSName and iPAddress), and it works beautifully with NameConstraints.

I think I got this pretty much worked out now.

> Cordialement,
> Erwann Abalea

And thank you

Bob


From Erwann.Abalea at docusign.com  Thu Aug 17 16:45:03 2017
From: Erwann.Abalea at docusign.com (Erwann Abalea)
Date: Thu, 17 Aug 2017 16:45:03 +0000
Subject: [openssl-users] Implementing deprecation of commonname and
 emailaddress
In-Reply-To: <CAH8yC8m9zmZQi8k-xe+SpzLdGSD9DKzh-+RXkaXdBdrCJP1irg@mail.gmail.com>
References: <c3f8cc53-7ffc-bc61-92bb-76963ab2ca9a@htt-consult.com>
 <CAH8yC8=mmfrokh7TxqQ1X7YVWEBUTh4Ma0uGwQJJvfAtjfU-_w@mail.gmail.com>
 <20170817151520.GC8146@mournblade.imrryr.org>
 <CAH8yC8ndFsOXKVneM8FjRyWw7q05Z2vTZfqDu01uHhYg8xfR2w@mail.gmail.com>
 <4B75F50D-F8D9-4CDC-8DBB-7B49463CC94C@docusign.com>
 <CAH8yC8m9zmZQi8k-xe+SpzLdGSD9DKzh-+RXkaXdBdrCJP1irg@mail.gmail.com>
Message-ID: <7AB84806-2340-4689-86AD-54523B483AAB@docusign.com>


> Le 17 ao?t 2017 ? 17:36, Jeffrey Walton <noloader at gmail.com> a ?crit :
> 
> On Thu, Aug 17, 2017 at 11:34 AM, Erwann Abalea
> <Erwann.Abalea at docusign.com> wrote:
>> 
>>> Le 17 ao?t 2017 ? 17:26, Jeffrey Walton <noloader at gmail.com> a ?crit :
>>> 
>>>>> When you see a name like "example.com" in the CN, its usually a CA
>>>>> including a domain name and not a hostname.
>>>> 
>>>> That's nonsense.
>>> 
>>> If a certificate is issued under CA/B policies, and CN=example.com but
>>> it _lacks_ SAN=example.com, then its a not a hostname and it should
>>> not be matched.
>> 
>> Such a certificate would be mis-issued and be revoked immediately. CN MUST be an FQDN (or a wild carded FQDN, or an IP address), and a copy of the value in CN MUST be present in the SAN extension.
> 
> Oh, you would have some fun watching how various user agents handle
> that scenario. For your first stop, check out how OpenSSL handles it.

I?m sure some user agents can have strange behaviors on such certificates. My remark took into consideration the CA/B policies. If such a certificate falls down under the CA/B policies (issued by a public CA, and a TLS server certificate), then it?s invalid.
Some browsers (maybe all?) ignore the CN if the SAN extension is present, even for private CAs.

Cordialement,
Erwann Abalea


From rgm at htt-consult.com  Thu Aug 17 19:23:42 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 17 Aug 2017 15:23:42 -0400
Subject: [openssl-users] Cant seem to get prompt no to work
Message-ID: <b975e16e-9b42-ceb3-6166-40ea48ab5bde@htt-consult.com>

In the [ ca ] section I have:

prompt   = no

If I leave the = out I get an error, so I am assuming I got the format 
of this right.

Then I have

[ req ]
distinguished_name  = req_distinguished_name

[ req_distinguished_name ]
countryName                     = $ENV::countryName
stateOrProvinceName             = $ENV::stateOrProvinceName

In a terminal window I run:

export countryName=US
export stateOrProvinceName=MI

then

openssl req -config openssl-root.cnf -key private/ca.key.pem \
       -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
certs/ca.cert.pem


And I am still getting prompted for the DN fields:

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
US []:

What did I miss?

thanks

Bob


From rsalz at akamai.com  Thu Aug 17 19:39:12 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 17 Aug 2017 19:39:12 +0000
Subject: [openssl-users] Cant seem to get prompt no to work
In-Reply-To: <b975e16e-9b42-ceb3-6166-40ea48ab5bde@htt-consult.com>
References: <b975e16e-9b42-ceb3-6166-40ea48ab5bde@htt-consult.com>
Message-ID: <6DC670A4-11A8-495E-85E1-435C04958115@akamai.com>

In the CA section, you have to specify which fields you need/want in the DN.  This is the ?policy? identifier which points to a section that names the RDN?s you want/need.


From rgm at htt-consult.com  Thu Aug 17 19:45:19 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 17 Aug 2017 15:45:19 -0400
Subject: [openssl-users] Cant seem to get prompt no to work
In-Reply-To: <6DC670A4-11A8-495E-85E1-435C04958115@akamai.com>
References: <b975e16e-9b42-ceb3-6166-40ea48ab5bde@htt-consult.com>
 <6DC670A4-11A8-495E-85E1-435C04958115@akamai.com>
Message-ID: <c377669d-be6d-4713-851c-c6e30a3f0720@htt-consult.com>



On 08/17/2017 03:39 PM, Salz, Rich via openssl-users wrote:
> In the CA section, you have to specify which fields you need/want in the DN.  This is the ?policy? identifier which points to a section that names the RDN?s you want/need.
>
I have that:

[ ca ]
# `man ca`
default_ca = CA_default

[ CA_default ]
# Directory and file locations.
#     dir               = /root/ca
certs             = $ENV::dir/certs
crl_dir           = $ENV::dir/crl
new_certs_dir     = $ENV::dir/newcerts
database          = $ENV::dir/index.txt
serial            = $ENV::dir/serial
RANDFILE          = $ENV::dir/private/.rand

# The root key and root certificate.
private_key       = $ENV::dir/private/ca.key.pem
certificate       = $ENV::dir/certs/ca.cert.pem

# For certificate revocation lists.
crlnumber         = $ENV::dir/crlnumber
crl               = $ENV::dir/crl/ca.crl.pem
crl_extensions    = crl_ext
default_crl_days  = 30

# SHA-1 is deprecated, so use SHA-2 instead.
default_md        = sha256

name_opt          = ca_default
cert_opt          = ca_default
default_days      = 375
preserve          = no
policy            = policy_strict
prompt            = no

[ policy_strict ]
# The root CA should only sign intermediate certificates that match.
# See the POLICY FORMAT section of `man ca`.
countryName             = match
stateOrProvinceName     = match
organizationName        = match
organizationalUnitName  = optional
commonName              = optional

[ policy_loose ]
# Allow the intermediate CA to sign a more diverse range of certificates.
# See the POLICY FORMAT section of the `ca` man page.
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = optional

[ req ]
# Options for the `req` tool (`man req`).
default_bits        = 2048
distinguished_name  = req_distinguished_name
string_mask         = utf8only
req_extensions      = req_ext

# SHA-1 is deprecated, so use SHA-2 instead.
default_md          = sha256

# Extension to add when the -x509 option is used.
x509_extensions     = v3_ca

[ req_distinguished_name ]
# See <https://en.wikipedia.org/wiki/Certificate_signing_request>.
countryName                     = $ENV::countryName
stateOrProvinceName             = $ENV::stateOrProvinceName
localityName                    = $ENV::localityName
0.organizationName              = $ENV::organizationName
organizationalUnitName          = $ENV::organizationalUnitName
commonName                      = $ENV::commonName

[ req_ext ]
subjectAltName = email:$ENV::adminemail



From rsalz at akamai.com  Thu Aug 17 20:09:22 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 17 Aug 2017 20:09:22 +0000
Subject: [openssl-users] Cant seem to get prompt no to work
In-Reply-To: <c377669d-be6d-4713-851c-c6e30a3f0720@htt-consult.com>
References: <b975e16e-9b42-ceb3-6166-40ea48ab5bde@htt-consult.com>
 <6DC670A4-11A8-495E-85E1-435C04958115@akamai.com>
 <c377669d-be6d-4713-851c-c6e30a3f0720@htt-consult.com>
Message-ID: <13E6CBCC-7C48-42A7-AF76-F8F9995E9272@akamai.com>

Use the ?batch flag to avoid all prompting


From rgm at htt-consult.com  Thu Aug 17 20:17:55 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 17 Aug 2017 16:17:55 -0400
Subject: [openssl-users] Cant seem to get prompt no to work
In-Reply-To: <13E6CBCC-7C48-42A7-AF76-F8F9995E9272@akamai.com>
References: <b975e16e-9b42-ceb3-6166-40ea48ab5bde@htt-consult.com>
 <6DC670A4-11A8-495E-85E1-435C04958115@akamai.com>
 <c377669d-be6d-4713-851c-c6e30a3f0720@htt-consult.com>
 <13E6CBCC-7C48-42A7-AF76-F8F9995E9272@akamai.com>
Message-ID: <45b3324f-3274-d0db-ca68-81b9aa7b7346@htt-consult.com>



On 08/17/2017 04:09 PM, Salz, Rich wrote:
> Use the ?batch flag to avoid all prompting
>
I commented out the prompt line and tried again:

openssl req -config openssl-root.cnf -key private/ca.key.pem \
 >       -new -x509 -days 7300 -sha256 -batch -extensions v3_ca -out 
certs/ca.cert.pem
Enter pass phrase for private/ca.key.pem:
error, no objects specified in config file
problems making Certificate Request

Is it not liking the use of ENV for the DN objects?  It worked for 
$ENV::dir...

export

...

declare -x adminemail="postmaster at htt-consult.com"
declare -x commonName="Root CA"
declare -x countryName="US"
declare -x dir="/root/ca"
declare -x localityName="Oak Park"
declare -x organizationName="HTT Consulting"
declare -x organizationalUnitName=""
declare -x stateOrProvinceName="MI"


[ req_distinguished_name ]
# See <https://en.wikipedia.org/wiki/Certificate_signing_request>.
countryName                     = $ENV::countryName
stateOrProvinceName             = $ENV::stateOrProvinceName
localityName                    = $ENV::localityName
0.organizationName              = $ENV::organizationName
organizationalUnitName          = $ENV::organizationalUnitName
commonName                      = $ENV::commonName



From rgm at htt-consult.com  Thu Aug 17 20:40:04 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 17 Aug 2017 16:40:04 -0400
Subject: [openssl-users] Cant seem to get prompt no to work
In-Reply-To: <45b3324f-3274-d0db-ca68-81b9aa7b7346@htt-consult.com>
References: <b975e16e-9b42-ceb3-6166-40ea48ab5bde@htt-consult.com>
 <6DC670A4-11A8-495E-85E1-435C04958115@akamai.com>
 <c377669d-be6d-4713-851c-c6e30a3f0720@htt-consult.com>
 <13E6CBCC-7C48-42A7-AF76-F8F9995E9272@akamai.com>
 <45b3324f-3274-d0db-ca68-81b9aa7b7346@htt-consult.com>
Message-ID: <035c3ec8-332b-5302-46f4-19b7b101faba@htt-consult.com>



On 08/17/2017 04:17 PM, Robert Moskowitz wrote:
>
>
> On 08/17/2017 04:09 PM, Salz, Rich wrote:
>> Use the ?batch flag to avoid all prompting
>>
> I commented out the prompt line and tried again:
>
> openssl req -config openssl-root.cnf -key private/ca.key.pem \
> >       -new -x509 -days 7300 -sha256 -batch -extensions v3_ca -out 
> certs/ca.cert.pem
> Enter pass phrase for private/ca.key.pem:
> error, no objects specified in config file
> problems making Certificate Request
>
> Is it not liking the use of ENV for the DN objects?  It worked for 
> $ENV::dir...
>
> export
>
> ...
>
> declare -x adminemail="postmaster at htt-consult.com"
> declare -x commonName="Root CA"
> declare -x countryName="US"
> declare -x dir="/root/ca"
> declare -x localityName="Oak Park"
> declare -x organizationName="HTT Consulting"
> declare -x organizationalUnitName=""
> declare -x stateOrProvinceName="MI"
>
>
> [ req_distinguished_name ]
> # See <https://en.wikipedia.org/wiki/Certificate_signing_request>.
> countryName                     = $ENV::countryName
> stateOrProvinceName             = $ENV::stateOrProvinceName
> localityName                    = $ENV::localityName
> 0.organizationName              = $ENV::organizationName
> organizationalUnitName          = $ENV::organizationalUnitName
> commonName                      = $ENV::commonName
>
>
I don't think it is the use of $ENV, as the following in cnf got the 
same failure:

countryName                     = US
stateOrProvinceName             = MI
localityName                    = "Oak Park"
0.organizationName              = "HTT Consulting"
organizationalUnitName          =
commonName                      = "Root CA"

I have removed the _default entries....



From rgm at htt-consult.com  Thu Aug 17 21:17:19 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 17 Aug 2017 17:17:19 -0400
Subject: [openssl-users] Cant seem to get prompt no to work
In-Reply-To: <45b3324f-3274-d0db-ca68-81b9aa7b7346@htt-consult.com>
References: <b975e16e-9b42-ceb3-6166-40ea48ab5bde@htt-consult.com>
 <6DC670A4-11A8-495E-85E1-435C04958115@akamai.com>
 <c377669d-be6d-4713-851c-c6e30a3f0720@htt-consult.com>
 <13E6CBCC-7C48-42A7-AF76-F8F9995E9272@akamai.com>
 <45b3324f-3274-d0db-ca68-81b9aa7b7346@htt-consult.com>
Message-ID: <f16da661-1dbe-1319-d77c-2cf51bc9ad4e@htt-consult.com>



On 08/17/2017 04:17 PM, Robert Moskowitz wrote:
>
>
> On 08/17/2017 04:09 PM, Salz, Rich wrote:
>> Use the ?batch flag to avoid all prompting
>>
> I commented out the prompt line and tried again:
>
> openssl req -config openssl-root.cnf -key private/ca.key.pem \
> >       -new -x509 -days 7300 -sha256 -batch -extensions v3_ca -out 
> certs/ca.cert.pem
> Enter pass phrase for private/ca.key.pem:
> error, no objects specified in config file
> problems making Certificate Request
>
> Is it not liking the use of ENV for the DN objects?  It worked for 
> $ENV::dir...
>
> export
>
> ...
>
> declare -x adminemail="postmaster at htt-consult.com"
> declare -x commonName="Root CA"
> declare -x countryName="US"
> declare -x dir="/root/ca"
> declare -x localityName="Oak Park"
> declare -x organizationName="HTT Consulting"
> declare -x organizationalUnitName=""
> declare -x stateOrProvinceName="MI"
>
>
> [ req_distinguished_name ]
> # See <https://en.wikipedia.org/wiki/Certificate_signing_request>.
> countryName                     = $ENV::countryName
> stateOrProvinceName             = $ENV::stateOrProvinceName
> localityName                    = $ENV::localityName
> 0.organizationName              = $ENV::organizationName
> organizationalUnitName          = $ENV::organizationalUnitName
> commonName                      = $ENV::commonName
>
>
When I put the prompt = no in the beginning of the [req] section ( saw 
that on one site), I get:

problems making Certificate Request
140134179792760:error:0D07A098:asn1 encoding 
routines:ASN1_mbstring_ncopy:string too short:a_mbstr.c:151:minsize=1

Is ENV not working in [req_distinguished_name]?



From rsalz at akamai.com  Thu Aug 17 21:38:01 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 17 Aug 2017 21:38:01 +0000
Subject: [openssl-users] Cant seem to get prompt no to work
In-Reply-To: <f16da661-1dbe-1319-d77c-2cf51bc9ad4e@htt-consult.com>
References: <b975e16e-9b42-ceb3-6166-40ea48ab5bde@htt-consult.com>
 <6DC670A4-11A8-495E-85E1-435C04958115@akamai.com>
 <c377669d-be6d-4713-851c-c6e30a3f0720@htt-consult.com>
 <13E6CBCC-7C48-42A7-AF76-F8F9995E9272@akamai.com>
 <45b3324f-3274-d0db-ca68-81b9aa7b7346@htt-consult.com>
 <f16da661-1dbe-1319-d77c-2cf51bc9ad4e@htt-consult.com>
Message-ID: <4C5F0A7F-E0D8-4884-8B55-153C931472AE@akamai.com>

> declare -x organizationalUnitName=""
> routines:ASN1_mbstring_ncopy:string too short:a_mbstr.c:151:minsize=1
   
You are setting an empty OU.  You should not set it and see if that works 
    


From rgm at htt-consult.com  Thu Aug 17 22:02:31 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 17 Aug 2017 18:02:31 -0400
Subject: [openssl-users] Cant seem to get prompt no to work
In-Reply-To: <4C5F0A7F-E0D8-4884-8B55-153C931472AE@akamai.com>
References: <b975e16e-9b42-ceb3-6166-40ea48ab5bde@htt-consult.com>
 <6DC670A4-11A8-495E-85E1-435C04958115@akamai.com>
 <c377669d-be6d-4713-851c-c6e30a3f0720@htt-consult.com>
 <13E6CBCC-7C48-42A7-AF76-F8F9995E9272@akamai.com>
 <45b3324f-3274-d0db-ca68-81b9aa7b7346@htt-consult.com>
 <f16da661-1dbe-1319-d77c-2cf51bc9ad4e@htt-consult.com>
 <4C5F0A7F-E0D8-4884-8B55-153C931472AE@akamai.com>
Message-ID: <c5c3f83f-6fc3-6146-9c5a-d4a3976687d3@htt-consult.com>

ARGH!!!

On 08/17/2017 05:38 PM, Salz, Rich wrote:
>> declare -x organizationalUnitName=""
>> routines:ASN1_mbstring_ncopy:string too short:a_mbstr.c:151:minsize=1
>     
> You are setting an empty OU.  You should not set it and see if that works

So now I have to figure out how to handle an empty variable.  Need to 
see what will happen if the variable has a value of "." that the 
prompting takes for dropping that object...

The resultant cert does not have the SAN.  That is another thing I need 
to figure out.



From rgm at htt-consult.com  Thu Aug 17 22:09:53 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 17 Aug 2017 18:09:53 -0400
Subject: [openssl-users] Cant seem to get prompt no to work
In-Reply-To: <4C5F0A7F-E0D8-4884-8B55-153C931472AE@akamai.com>
References: <b975e16e-9b42-ceb3-6166-40ea48ab5bde@htt-consult.com>
 <6DC670A4-11A8-495E-85E1-435C04958115@akamai.com>
 <c377669d-be6d-4713-851c-c6e30a3f0720@htt-consult.com>
 <13E6CBCC-7C48-42A7-AF76-F8F9995E9272@akamai.com>
 <45b3324f-3274-d0db-ca68-81b9aa7b7346@htt-consult.com>
 <f16da661-1dbe-1319-d77c-2cf51bc9ad4e@htt-consult.com>
 <4C5F0A7F-E0D8-4884-8B55-153C931472AE@akamai.com>
Message-ID: <0104d366-cc26-af0d-6073-72168b23fcb9@htt-consult.com>



On 08/17/2017 05:38 PM, Salz, Rich wrote:
>> declare -x organizationalUnitName=""
>> routines:ASN1_mbstring_ncopy:string too short:a_mbstr.c:151:minsize=1
>     
> You are setting an empty OU.  You should not set it and see if that works
>      
>
organizationalUnitName = "."  puts a . in it.  So I have to figure out a 
way to drop that line from the config.

like if a field is not needed:

sed -i -e "s/^organizationalUnitName/#organizationalUnitName/w 
/dev/stdout" openssl-root.cnf


But this is not quite right.  I have to find the one that has ENV in 
it.  I DO have an example of one such to use...



From rgm at htt-consult.com  Thu Aug 17 22:30:11 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 17 Aug 2017 18:30:11 -0400
Subject: [openssl-users] Cant get the subjectALtName inot the root cert
Message-ID: <8d348150-511f-3034-c754-4d00930a08d6@htt-consult.com>

I guess I am making progress.  I am not getting SAN into the root cert.  
my cnf has in it:

[ req ]
# Options for the `req` tool (`man req`).
default_bits        = 2048
prompt              = no
distinguished_name  = req_distinguished_name
string_mask         = utf8only
req_extensions      = req_ext

[ req_ext ]
#subjectAltName = email:$ENV::adminemail
#subjectAltName = email:admin at htt-consult.com
subjectAltName = IP:192.168.24.1

I tried all three above alternatives for SAN.  No SAN in the root cert 
created with:

openssl req -config openssl-root.cnf -key private/ca.key.pem \
       -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
certs/ca.cert.pem

Thanks for any insight.

This type of cnf worked for creating a CSR and with the copy option the 
SAN made it into the cert.

thanks

Bob


From noloader at gmail.com  Thu Aug 17 22:38:02 2017
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 17 Aug 2017 18:38:02 -0400
Subject: [openssl-users] Cant get the subjectALtName inot the root cert
In-Reply-To: <8d348150-511f-3034-c754-4d00930a08d6@htt-consult.com>
References: <8d348150-511f-3034-c754-4d00930a08d6@htt-consult.com>
Message-ID: <CAH8yC8mkoc2s78gRCt14FVxPH5Dt9yP0ih+T5t5TEPbKz-5HZg@mail.gmail.com>

On Thu, Aug 17, 2017 at 6:30 PM, Robert Moskowitz <rgm at htt-consult.com> wrote:
> I guess I am making progress.  I am not getting SAN into the root cert.  my
> cnf has in it:
>
> [ req ]
> # Options for the `req` tool (`man req`).
> default_bits        = 2048
> prompt              = no
> distinguished_name  = req_distinguished_name
> string_mask         = utf8only
> req_extensions      = req_ext
>
> [ req_ext ]
> #subjectAltName = email:$ENV::adminemail
> #subjectAltName = email:admin at htt-consult.com
> subjectAltName = IP:192.168.24.1
>
> I tried all three above alternatives for SAN.  No SAN in the root cert
> created with:
>
> openssl req -config openssl-root.cnf -key private/ca.key.pem \
>       -new -x509 -days 7300 -sha256 -extensions v3_ca -out certs/ca.cert.pem
>
> Thanks for any insight.
>
> This type of cnf worked for creating a CSR and with the copy option the SAN
> made it into the cert.

It looks a bit unusual for a Root CA.

As far as signing the CSR, you need

    copy_extensions = copy

Jeff

From jb-openssl at wisemo.com  Thu Aug 17 23:01:45 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 18 Aug 2017 01:01:45 +0200
Subject: [openssl-users] Cant seem to get prompt no to work
In-Reply-To: <0104d366-cc26-af0d-6073-72168b23fcb9@htt-consult.com>
References: <b975e16e-9b42-ceb3-6166-40ea48ab5bde@htt-consult.com>
 <6DC670A4-11A8-495E-85E1-435C04958115@akamai.com>
 <c377669d-be6d-4713-851c-c6e30a3f0720@htt-consult.com>
 <13E6CBCC-7C48-42A7-AF76-F8F9995E9272@akamai.com>
 <45b3324f-3274-d0db-ca68-81b9aa7b7346@htt-consult.com>
 <f16da661-1dbe-1319-d77c-2cf51bc9ad4e@htt-consult.com>
 <4C5F0A7F-E0D8-4884-8B55-153C931472AE@akamai.com>
 <0104d366-cc26-af0d-6073-72168b23fcb9@htt-consult.com>
Message-ID: <f9bc254d-e938-08fa-b9e4-c567bda0b5a8@wisemo.com>

On 18/08/2017 00:09, Robert Moskowitz wrote:
>
>
> On 08/17/2017 05:38 PM, Salz, Rich wrote:
>>> declare -x organizationalUnitName=""
>>> routines:ASN1_mbstring_ncopy:string too short:a_mbstr.c:151:minsize=1
>>     You are setting an empty OU.  You should not set it and see if 
>> that works
>>
> organizationalUnitName = "."  puts a . in it.  So I have to figure out 
> a way to drop that line from the config.
>
> like if a field is not needed:
>
> sed -i -e "s/^organizationalUnitName/#organizationalUnitName/w 
> /dev/stdout" openssl-root.cnf
>
>
> But this is not quite right.  I have to find the one that has ENV in 
> it.  I DO have an example of one such to use...
>
>
Given all these problems with the Distinguished Name prompting
mechanism, just add the -subject option to the req command line
(using appropriate environment variables in the shell script).


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 rgm at htt-consult.com  Thu Aug 17 23:50:08 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 17 Aug 2017 19:50:08 -0400
Subject: [openssl-users] Cant get the subjectALtName inot the root cert
In-Reply-To: <CAH8yC8mkoc2s78gRCt14FVxPH5Dt9yP0ih+T5t5TEPbKz-5HZg@mail.gmail.com>
References: <8d348150-511f-3034-c754-4d00930a08d6@htt-consult.com>
 <CAH8yC8mkoc2s78gRCt14FVxPH5Dt9yP0ih+T5t5TEPbKz-5HZg@mail.gmail.com>
Message-ID: <f25d83dd-4d2a-b7f6-2604-8e8e1dfedafe@htt-consult.com>



On 08/17/2017 06:38 PM, Jeffrey Walton wrote:
> On Thu, Aug 17, 2017 at 6:30 PM, Robert Moskowitz <rgm at htt-consult.com> wrote:
>> I guess I am making progress.  I am not getting SAN into the root cert.  my
>> cnf has in it:
>>
>> [ req ]
>> # Options for the `req` tool (`man req`).
>> default_bits        = 2048
>> prompt              = no
>> distinguished_name  = req_distinguished_name
>> string_mask         = utf8only
>> req_extensions      = req_ext
>>
>> [ req_ext ]
>> #subjectAltName = email:$ENV::adminemail
>> #subjectAltName = email:admin at htt-consult.com
>> subjectAltName = IP:192.168.24.1
>>
>> I tried all three above alternatives for SAN.  No SAN in the root cert
>> created with:
>>
>> openssl req -config openssl-root.cnf -key private/ca.key.pem \
>>        -new -x509 -days 7300 -sha256 -extensions v3_ca -out certs/ca.cert.pem
>>
>> Thanks for any insight.
>>
>> This type of cnf worked for creating a CSR and with the copy option the SAN
>> made it into the cert.
> It looks a bit unusual for a Root CA.
>
> As far as signing the CSR, you need
>
>      copy_extensions = copy

I have that in the [ ca ] section and it did put SAN into the 
intermediate CA cert.

But I can't seem to get it into the root CA cert.

Bob


From rgm at htt-consult.com  Thu Aug 17 23:54:09 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 17 Aug 2017 19:54:09 -0400
Subject: [openssl-users] Cant seem to get prompt no to work
In-Reply-To: <f9bc254d-e938-08fa-b9e4-c567bda0b5a8@wisemo.com>
References: <b975e16e-9b42-ceb3-6166-40ea48ab5bde@htt-consult.com>
 <6DC670A4-11A8-495E-85E1-435C04958115@akamai.com>
 <c377669d-be6d-4713-851c-c6e30a3f0720@htt-consult.com>
 <13E6CBCC-7C48-42A7-AF76-F8F9995E9272@akamai.com>
 <45b3324f-3274-d0db-ca68-81b9aa7b7346@htt-consult.com>
 <f16da661-1dbe-1319-d77c-2cf51bc9ad4e@htt-consult.com>
 <4C5F0A7F-E0D8-4884-8B55-153C931472AE@akamai.com>
 <0104d366-cc26-af0d-6073-72168b23fcb9@htt-consult.com>
 <f9bc254d-e938-08fa-b9e4-c567bda0b5a8@wisemo.com>
Message-ID: <570be455-a852-0a8e-e6da-4191692a1e27@htt-consult.com>



On 08/17/2017 07:01 PM, Jakob Bohm wrote:
> On 18/08/2017 00:09, Robert Moskowitz wrote:
>>
>>
>> On 08/17/2017 05:38 PM, Salz, Rich wrote:
>>>> declare -x organizationalUnitName=""
>>>> routines:ASN1_mbstring_ncopy:string too short:a_mbstr.c:151:minsize=1
>>>     You are setting an empty OU.  You should not set it and see if 
>>> that works
>>>
>> organizationalUnitName = "."  puts a . in it.  So I have to figure 
>> out a way to drop that line from the config.
>>
>> like if a field is not needed:
>>
>> sed -i -e "s/^organizationalUnitName/#organizationalUnitName/w 
>> /dev/stdout" openssl-root.cnf
>>
>>
>> But this is not quite right.  I have to find the one that has ENV in 
>> it.  I DO have an example of one such to use...
>>
>>
> Given all these problems with the Distinguished Name prompting
> mechanism, just add the -subject option to the req command line
> (using appropriate environment variables in the shell script).

Always an option, Jakob.  I have done this in the past for my 
self-signed certs.  I am trying the config approach now.  But I may step 
back...

I AM making my CA certs.  With a SAN caviat in the root cert.

Slow progress.

Bob


From rgm at htt-consult.com  Fri Aug 18 00:44:48 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 17 Aug 2017 20:44:48 -0400
Subject: [openssl-users] Solved - Re: Cant get the subjectALtName inot the
 root cert
In-Reply-To: <CAH8yC8mkoc2s78gRCt14FVxPH5Dt9yP0ih+T5t5TEPbKz-5HZg@mail.gmail.com>
References: <8d348150-511f-3034-c754-4d00930a08d6@htt-consult.com>
 <CAH8yC8mkoc2s78gRCt14FVxPH5Dt9yP0ih+T5t5TEPbKz-5HZg@mail.gmail.com>
Message-ID: <5452971d-a3c8-dc1a-3eaa-886ca0ad06a2@htt-consult.com>

Kind of...

Does not put SAN in CA cert:

openssl req -config openssl-root.cnf -key private/ca.key.pem \
       -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
certs/ca.cert.pem

Does put SAN in CA cert:

openssl req -config openssl-root.cnf -key private/ca.key.pem \
       -new -sha256 -extensions v3_ca -out csr/ca.csr.pem

openssl ca -config openssl-root.cnf -extensions v3_ca -days 7300 -notext 
-md sha256 \
       -in csr/ca.csr.pem -out certs/ca.cert.pem

Interesting that the single step does not work, but the 2 step doesn.

Do I need -extensions v3_ca in both commands?  Plus sha256 in both? 
Could benefit from some refinement.  Or getting the 1 step working.

Good enough for now!

Bob


On 08/17/2017 06:38 PM, Jeffrey Walton wrote:
> On Thu, Aug 17, 2017 at 6:30 PM, Robert Moskowitz <rgm at htt-consult.com> wrote:
>> I guess I am making progress.  I am not getting SAN into the root cert.  my
>> cnf has in it:
>>
>> [ req ]
>> # Options for the `req` tool (`man req`).
>> default_bits        = 2048
>> prompt              = no
>> distinguished_name  = req_distinguished_name
>> string_mask         = utf8only
>> req_extensions      = req_ext
>>
>> [ req_ext ]
>> #subjectAltName = email:$ENV::adminemail
>> #subjectAltName = email:admin at htt-consult.com
>> subjectAltName = IP:192.168.24.1
>>
>> I tried all three above alternatives for SAN.  No SAN in the root cert
>> created with:
>>
>> openssl req -config openssl-root.cnf -key private/ca.key.pem \
>>        -new -x509 -days 7300 -sha256 -extensions v3_ca -out certs/ca.cert.pem
>>
>> Thanks for any insight.
>>
>> This type of cnf worked for creating a CSR and with the copy option the SAN
>> made it into the cert.
> It looks a bit unusual for a Root CA.
>
> As far as signing the CSR, you need
>
>      copy_extensions = copy
>
> Jeff


From rgm at htt-consult.com  Fri Aug 18 01:23:52 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 17 Aug 2017 21:23:52 -0400
Subject: [openssl-users] Solved - Re: Cant get the subjectALtName inot
 the root cert
In-Reply-To: <5452971d-a3c8-dc1a-3eaa-886ca0ad06a2@htt-consult.com>
References: <8d348150-511f-3034-c754-4d00930a08d6@htt-consult.com>
 <CAH8yC8mkoc2s78gRCt14FVxPH5Dt9yP0ih+T5t5TEPbKz-5HZg@mail.gmail.com>
 <5452971d-a3c8-dc1a-3eaa-886ca0ad06a2@htt-consult.com>
Message-ID: <007c95c1-01c2-9dd0-636b-57c56fdf8eec@htt-consult.com>

NO does not work.  It worked because I had the old root CA cert there.  
Without it it fails.

I tried adding -selfsign and that did something, but did not create a 
trusted cert...


On 08/17/2017 08:44 PM, Robert Moskowitz wrote:
> Kind of...
>
> Does not put SAN in CA cert:
>
> openssl req -config openssl-root.cnf -key private/ca.key.pem \
>       -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
> certs/ca.cert.pem
>
> Does put SAN in CA cert:
>
> openssl req -config openssl-root.cnf -key private/ca.key.pem \
>       -new -sha256 -extensions v3_ca -out csr/ca.csr.pem
>
> openssl ca -config openssl-root.cnf -extensions v3_ca -days 7300 
> -notext -md sha256 \
>       -in csr/ca.csr.pem -out certs/ca.cert.pem
>
> Interesting that the single step does not work, but the 2 step doesn.
>
> Do I need -extensions v3_ca in both commands?  Plus sha256 in both? 
> Could benefit from some refinement.  Or getting the 1 step working.
>
> Good enough for now!
>
> Bob
>
>
> On 08/17/2017 06:38 PM, Jeffrey Walton wrote:
>> On Thu, Aug 17, 2017 at 6:30 PM, Robert Moskowitz 
>> <rgm at htt-consult.com> wrote:
>>> I guess I am making progress.  I am not getting SAN into the root 
>>> cert.  my
>>> cnf has in it:
>>>
>>> [ req ]
>>> # Options for the `req` tool (`man req`).
>>> default_bits        = 2048
>>> prompt              = no
>>> distinguished_name  = req_distinguished_name
>>> string_mask         = utf8only
>>> req_extensions      = req_ext
>>>
>>> [ req_ext ]
>>> #subjectAltName = email:$ENV::adminemail
>>> #subjectAltName = email:admin at htt-consult.com
>>> subjectAltName = IP:192.168.24.1
>>>
>>> I tried all three above alternatives for SAN.  No SAN in the root cert
>>> created with:
>>>
>>> openssl req -config openssl-root.cnf -key private/ca.key.pem \
>>>        -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
>>> certs/ca.cert.pem
>>>
>>> Thanks for any insight.
>>>
>>> This type of cnf worked for creating a CSR and with the copy option 
>>> the SAN
>>> made it into the cert.
>> It looks a bit unusual for a Root CA.
>>
>> As far as signing the CSR, you need
>>
>>      copy_extensions = copy
>>
>> Jeff
>


From rgm at htt-consult.com  Fri Aug 18 01:52:27 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 17 Aug 2017 21:52:27 -0400
Subject: [openssl-users] Solved - Re: Cant get the subjectALtName inot
 the root cert
In-Reply-To: <007c95c1-01c2-9dd0-636b-57c56fdf8eec@htt-consult.com>
References: <8d348150-511f-3034-c754-4d00930a08d6@htt-consult.com>
 <CAH8yC8mkoc2s78gRCt14FVxPH5Dt9yP0ih+T5t5TEPbKz-5HZg@mail.gmail.com>
 <5452971d-a3c8-dc1a-3eaa-886ca0ad06a2@htt-consult.com>
 <007c95c1-01c2-9dd0-636b-57c56fdf8eec@htt-consult.com>
Message-ID: <8e469ce5-9e66-8484-e181-44e18653fd17@htt-consult.com>

It IS working with -selfsign.  So this step is done.

openssl ca -config openssl-root.cnf -extensions v3_ca -days 7300 -notext 
-md sha256 \
       -selfsign -in csr/ca.csr.pem -out certs/ca.cert.pem

openssl x509 -in certs/ca.cert.pem -text -noout
Certificate:
     Data:
         Version: 3 (0x2)
         Serial Number:
             87:b5:1d:03:12:a9:f3:fa
     Signature Algorithm: ecdsa-with-SHA256
         Issuer: C=US, ST=MI, O=HTT Consulting, CN=Root CA
         Validity
             Not Before: Aug 18 01:50:19 2017 GMT
             Not After : Aug 13 01:50:19 2037 GMT
         Subject: C=US, ST=MI, O=HTT Consulting, CN=Root CA
         Subject Public Key Info:
             Public Key Algorithm: id-ecPublicKey
                 Public-Key: (256 bit)
                 pub:
                     04:03:ee:4a:51:17:df:50:2b:bc:69:63:b5:03:90:
                     b5:ed:cf:d5:67:16:94:46:9c:ca:5b:1c:87:d0:81:
                     18:04:bf:5a:c0:00:4e:90:4b:fb:2e:17:1c:aa:42:
                     1e:9e:bd:be:ba:d7:f8:6c:55:24:b2:91:da:61:9c:
                     66:b4:03:a5:93
                 ASN1 OID: prime256v1
                 NIST CURVE: P-256
         X509v3 extensions:
             X509v3 Subject Key Identifier:
D5:09:1A:48:F2:D8:F8:30:46:26:38:78:C8:C2:C5:CD:01:A7:1D:57
             X509v3 Authority Key Identifier:
keyid:D5:09:1A:48:F2:D8:F8:30:46:26:38:78:C8:C2:C5:CD:01:A7:1D:57

             X509v3 Basic Constraints: critical
                 CA:TRUE
             X509v3 Key Usage: critical
                 Certificate Sign, CRL Sign
             X509v3 Subject Alternative Name:
                 email:postmaster at htt-consult.com
     Signature Algorithm: ecdsa-with-SHA256
          30:46:02:21:00:ed:b6:ea:93:b5:df:b2:30:fe:17:fc:a6:fa:
          0e:c1:08:82:9a:84:59:a9:a6:5c:50:23:66:72:c0:da:7a:18:
          5b:02:21:00:8b:f1:52:ea:dd:44:88:a6:ee:43:cd:29:52:e4:
          27:57:ee:52:a2:47:86:6f:9e:11:9d:7d:72:a5:08:82:8f:14



On 08/17/2017 09:23 PM, Robert Moskowitz wrote:
> NO does not work.  It worked because I had the old root CA cert 
> there.  Without it it fails.
>
> I tried adding -selfsign and that did something, but did not create a 
> trusted cert...
>
>
> On 08/17/2017 08:44 PM, Robert Moskowitz wrote:
>> Kind of...
>>
>> Does not put SAN in CA cert:
>>
>> openssl req -config openssl-root.cnf -key private/ca.key.pem \
>>       -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
>> certs/ca.cert.pem
>>
>> Does put SAN in CA cert:
>>
>> openssl req -config openssl-root.cnf -key private/ca.key.pem \
>>       -new -sha256 -extensions v3_ca -out csr/ca.csr.pem
>>
>> openssl ca -config openssl-root.cnf -extensions v3_ca -days 7300 
>> -notext -md sha256 \
>>       -in csr/ca.csr.pem -out certs/ca.cert.pem
>>
>> Interesting that the single step does not work, but the 2 step doesn.
>>
>> Do I need -extensions v3_ca in both commands?  Plus sha256 in both? 
>> Could benefit from some refinement.  Or getting the 1 step working.
>>
>> Good enough for now!
>>
>> Bob
>>
>>
>> On 08/17/2017 06:38 PM, Jeffrey Walton wrote:
>>> On Thu, Aug 17, 2017 at 6:30 PM, Robert Moskowitz 
>>> <rgm at htt-consult.com> wrote:
>>>> I guess I am making progress.  I am not getting SAN into the root 
>>>> cert.  my
>>>> cnf has in it:
>>>>
>>>> [ req ]
>>>> # Options for the `req` tool (`man req`).
>>>> default_bits        = 2048
>>>> prompt              = no
>>>> distinguished_name  = req_distinguished_name
>>>> string_mask         = utf8only
>>>> req_extensions      = req_ext
>>>>
>>>> [ req_ext ]
>>>> #subjectAltName = email:$ENV::adminemail
>>>> #subjectAltName = email:admin at htt-consult.com
>>>> subjectAltName = IP:192.168.24.1
>>>>
>>>> I tried all three above alternatives for SAN.  No SAN in the root cert
>>>> created with:
>>>>
>>>> openssl req -config openssl-root.cnf -key private/ca.key.pem \
>>>>        -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
>>>> certs/ca.cert.pem
>>>>
>>>> Thanks for any insight.
>>>>
>>>> This type of cnf worked for creating a CSR and with the copy option 
>>>> the SAN
>>>> made it into the cert.
>>> It looks a bit unusual for a Root CA.
>>>
>>> As far as signing the CSR, you need
>>>
>>>      copy_extensions = copy
>>>
>>> Jeff
>>
>


From rgm at htt-consult.com  Fri Aug 18 02:54:29 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Thu, 17 Aug 2017 22:54:29 -0400
Subject: [openssl-users] FINAL simpler solution - Re: Solved - Re: Cant get
 the subjectALtName inot the root cert
In-Reply-To: <8e469ce5-9e66-8484-e181-44e18653fd17@htt-consult.com>
References: <8d348150-511f-3034-c754-4d00930a08d6@htt-consult.com>
 <CAH8yC8mkoc2s78gRCt14FVxPH5Dt9yP0ih+T5t5TEPbKz-5HZg@mail.gmail.com>
 <5452971d-a3c8-dc1a-3eaa-886ca0ad06a2@htt-consult.com>
 <007c95c1-01c2-9dd0-636b-57c56fdf8eec@htt-consult.com>
 <8e469ce5-9e66-8484-e181-44e18653fd17@htt-consult.com>
Message-ID: <0ad6e1ac-a478-e938-e1aa-3ff40937ef04@htt-consult.com>

I just had to ask Dr. Google the right question:

openssl subjectaltname in a selfsigned certificate

Afterall, a root cert is a selfsigned cert.

And I learned to put SAN in the [ v3_ca ] section, rather than the [ req 
] section then all it takes is what I already had:

openssl req -config openssl-root.cnf -key private/ca.key.pem \
       -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
certs/ca.cert.pem


On 08/17/2017 09:52 PM, Robert Moskowitz wrote:
> It IS working with -selfsign.  So this step is done.
>
> openssl ca -config openssl-root.cnf -extensions v3_ca -days 7300 
> -notext -md sha256 \
>       -selfsign -in csr/ca.csr.pem -out certs/ca.cert.pem
>
> openssl x509 -in certs/ca.cert.pem -text -noout
> Certificate:
>     Data:
>         Version: 3 (0x2)
>         Serial Number:
>             87:b5:1d:03:12:a9:f3:fa
>     Signature Algorithm: ecdsa-with-SHA256
>         Issuer: C=US, ST=MI, O=HTT Consulting, CN=Root CA
>         Validity
>             Not Before: Aug 18 01:50:19 2017 GMT
>             Not After : Aug 13 01:50:19 2037 GMT
>         Subject: C=US, ST=MI, O=HTT Consulting, CN=Root CA
>         Subject Public Key Info:
>             Public Key Algorithm: id-ecPublicKey
>                 Public-Key: (256 bit)
>                 pub:
>                     04:03:ee:4a:51:17:df:50:2b:bc:69:63:b5:03:90:
>                     b5:ed:cf:d5:67:16:94:46:9c:ca:5b:1c:87:d0:81:
>                     18:04:bf:5a:c0:00:4e:90:4b:fb:2e:17:1c:aa:42:
>                     1e:9e:bd:be:ba:d7:f8:6c:55:24:b2:91:da:61:9c:
>                     66:b4:03:a5:93
>                 ASN1 OID: prime256v1
>                 NIST CURVE: P-256
>         X509v3 extensions:
>             X509v3 Subject Key Identifier:
> D5:09:1A:48:F2:D8:F8:30:46:26:38:78:C8:C2:C5:CD:01:A7:1D:57
>             X509v3 Authority Key Identifier:
> keyid:D5:09:1A:48:F2:D8:F8:30:46:26:38:78:C8:C2:C5:CD:01:A7:1D:57
>
>             X509v3 Basic Constraints: critical
>                 CA:TRUE
>             X509v3 Key Usage: critical
>                 Certificate Sign, CRL Sign
>             X509v3 Subject Alternative Name:
>                 email:postmaster at htt-consult.com
>     Signature Algorithm: ecdsa-with-SHA256
>          30:46:02:21:00:ed:b6:ea:93:b5:df:b2:30:fe:17:fc:a6:fa:
>          0e:c1:08:82:9a:84:59:a9:a6:5c:50:23:66:72:c0:da:7a:18:
>          5b:02:21:00:8b:f1:52:ea:dd:44:88:a6:ee:43:cd:29:52:e4:
>          27:57:ee:52:a2:47:86:6f:9e:11:9d:7d:72:a5:08:82:8f:14
>
>
>
> On 08/17/2017 09:23 PM, Robert Moskowitz wrote:
>> NO does not work.  It worked because I had the old root CA cert 
>> there.  Without it it fails.
>>
>> I tried adding -selfsign and that did something, but did not create a 
>> trusted cert...
>>
>>
>> On 08/17/2017 08:44 PM, Robert Moskowitz wrote:
>>> Kind of...
>>>
>>> Does not put SAN in CA cert:
>>>
>>> openssl req -config openssl-root.cnf -key private/ca.key.pem \
>>>       -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
>>> certs/ca.cert.pem
>>>
>>> Does put SAN in CA cert:
>>>
>>> openssl req -config openssl-root.cnf -key private/ca.key.pem \
>>>       -new -sha256 -extensions v3_ca -out csr/ca.csr.pem
>>>
>>> openssl ca -config openssl-root.cnf -extensions v3_ca -days 7300 
>>> -notext -md sha256 \
>>>       -in csr/ca.csr.pem -out certs/ca.cert.pem
>>>
>>> Interesting that the single step does not work, but the 2 step doesn.
>>>
>>> Do I need -extensions v3_ca in both commands?  Plus sha256 in both? 
>>> Could benefit from some refinement.  Or getting the 1 step working.
>>>
>>> Good enough for now!
>>>
>>> Bob
>>>
>>>
>>> On 08/17/2017 06:38 PM, Jeffrey Walton wrote:
>>>> On Thu, Aug 17, 2017 at 6:30 PM, Robert Moskowitz 
>>>> <rgm at htt-consult.com> wrote:
>>>>> I guess I am making progress.  I am not getting SAN into the root 
>>>>> cert.  my
>>>>> cnf has in it:
>>>>>
>>>>> [ req ]
>>>>> # Options for the `req` tool (`man req`).
>>>>> default_bits        = 2048
>>>>> prompt              = no
>>>>> distinguished_name  = req_distinguished_name
>>>>> string_mask         = utf8only
>>>>> req_extensions      = req_ext
>>>>>
>>>>> [ req_ext ]
>>>>> #subjectAltName = email:$ENV::adminemail
>>>>> #subjectAltName = email:admin at htt-consult.com
>>>>> subjectAltName = IP:192.168.24.1
>>>>>
>>>>> I tried all three above alternatives for SAN.  No SAN in the root 
>>>>> cert
>>>>> created with:
>>>>>
>>>>> openssl req -config openssl-root.cnf -key private/ca.key.pem \
>>>>>        -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
>>>>> certs/ca.cert.pem
>>>>>
>>>>> Thanks for any insight.
>>>>>
>>>>> This type of cnf worked for creating a CSR and with the copy 
>>>>> option the SAN
>>>>> made it into the cert.
>>>> It looks a bit unusual for a Root CA.
>>>>
>>>> As far as signing the CSR, you need
>>>>
>>>>      copy_extensions = copy
>>>>
>>>> Jeff
>>>
>>
>


From rgm at htt-consult.com  Fri Aug 18 12:26:12 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Fri, 18 Aug 2017 08:26:12 -0400
Subject: [openssl-users] Throwing in the towel on ENV for DN
Message-ID: <d6ecb4ac-ca90-b2c3-7503-dd794365237e@htt-consult.com>

Jakob had it right....


On 08/17/2017 07:01 PM, Jakob Bohm wrote:
> Given all these problems with the Distinguished Name prompting
> mechanism, just add the -subject option to the req command line
> (using appropriate environment variables in the shell script).
>
>
> Enjoy
>
> Jakob

It is coming down that I would need a unique cnf for each cert type, 
rather than one per signing CA.  Things just don't work well without 
prompting or very consistent DN content.  So I am going to pull most of 
my. ENV.  I am leaving it in for dir and SAN.

I feel it is a bug that if in 'prompt = no' or -batch, if a DN object is 
empty (size 0), it should just be dropped.  This is not an error condition.

I nice feature would be if a default is set, not to prompt for that 
object.  Something like

prompt = if no default

Then I would use ENV to set the default values and let prompting go for 
objects like CN and UID.

Also SAN is poorly handled and it has come out that this is a basic RFC 
requirement since '00!

Next steps:

complete basic setup for ecdsa pki and 802.1AR leaf.  Publish on my website.
Write up 'lessons learned' and post it here.
Add CRL and OCSP support.
Publish an IETF ID at least as an individual submission; offer this work 
to the IETF hackathon and workgroups like NETCONF, I2NSF, DOTS, ANIMA, 
and CORE.

Bob


From rsalz at akamai.com  Fri Aug 18 12:46:11 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 18 Aug 2017 12:46:11 +0000
Subject: [openssl-users] Throwing in the towel on ENV for DN
In-Reply-To: <d6ecb4ac-ca90-b2c3-7503-dd794365237e@htt-consult.com>
References: <d6ecb4ac-ca90-b2c3-7503-dd794365237e@htt-consult.com>
Message-ID: <94939056-D2A4-4207-9861-E207B2E29B42@akamai.com>

This has been a long email thread.  Can you open a github issue and summarize the improvements you think we should make?

Thanks.

And thanks for your patience!


From noloader at gmail.com  Fri Aug 18 12:48:07 2017
From: noloader at gmail.com (Jeffrey Walton)
Date: Fri, 18 Aug 2017 08:48:07 -0400
Subject: [openssl-users] Throwing in the towel on ENV for DN
In-Reply-To: <d6ecb4ac-ca90-b2c3-7503-dd794365237e@htt-consult.com>
References: <d6ecb4ac-ca90-b2c3-7503-dd794365237e@htt-consult.com>
Message-ID: <CAH8yC8=gZYSP-Kmg7zfFAX_ScSnAFnNJgvf5-YhTdKMtx+rOiw@mail.gmail.com>

> It is coming down that I would need a unique cnf for each cert type, rather
> than one per signing CA.  Things just don't work well without prompting or
> very consistent DN content.  So I am going to pull most of my. ENV.  I am
> leaving it in for dir and SAN.
>
> I feel it is a bug that if in 'prompt = no' or -batch, if a DN object is
> empty (size 0), it should just be dropped.  This is not an error condition.

If this is a private PKI, then you can do things like that.

But I believe you need a distinguished name if you are following the
RFCs. Maybe you can modify your script to stuff the principal name
from the SAN in the DN somewhere.

> Next steps:
>
> complete basic setup for ecdsa pki and 802.1AR leaf.  Publish on my website.
> Write up 'lessons learned' and post it here.

I think there's a separate RFC or draft for 802.1AR, but I have not read it.

Maybe part of the pain point is, OpenSSL is not aware of it. Its just
using RFC 5280 (and to some extent, 6125).

Maybe you should stop using the command line tools and code something
up in C. Once you hit your stride using the C APIs, its easy to crank
out certificates the way you want them.

Jeff

From openssl-users at dukhovni.org  Fri Aug 18 13:17:18 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 18 Aug 2017 13:17:18 +0000
Subject: [openssl-users] Throwing in the towel on ENV for DN
In-Reply-To: <CAH8yC8=gZYSP-Kmg7zfFAX_ScSnAFnNJgvf5-YhTdKMtx+rOiw@mail.gmail.com>
References: <d6ecb4ac-ca90-b2c3-7503-dd794365237e@htt-consult.com>
 <CAH8yC8=gZYSP-Kmg7zfFAX_ScSnAFnNJgvf5-YhTdKMtx+rOiw@mail.gmail.com>
Message-ID: <20170818131718.GF8146@mournblade.imrryr.org>

On Fri, Aug 18, 2017 at 08:48:07AM -0400, Jeffrey Walton wrote:

> If this is a private PKI, then you can do things like that.
> 
> But I believe you need a distinguished name if you are following the
> RFCs. Maybe you can modify your script to stuff the principal name
> from the SAN in the DN somewhere.

The subject DN is allowed (and indeed recommended in RFC 5280) to
be an empty RDN sequence (with the subject alt name extension
marked critical, and holding the relevant names, in practice
not marking critical works just as well).

The issuer DN is the CA's subject name and is fixed, so not
the OP's problem.

-- 
	Viktor.

From mwood at iupui.edu  Fri Aug 18 13:18:55 2017
From: mwood at iupui.edu (Mark H. Wood)
Date: Fri, 18 Aug 2017 09:18:55 -0400
Subject: [openssl-users] More on cert serialnumbers
In-Reply-To: <4916C3E6-9105-47C9-903B-F96698C7692B@docusign.com>
References: <0e3970f1-8b7d-0d72-9adf-fa6bad16bdf7@htt-consult.com>
 <31CE1282-7267-4FF5-9B7B-C1A3407757E5@akamai.com>
 <EB6DA4E4-8EB4-4C16-B059-BA9C8D515A6D@akamai.com>
 <d6b6b9fa-7791-b9c6-8a67-b5143b78ff84@htt-consult.com>
 <4916C3E6-9105-47C9-903B-F96698C7692B@docusign.com>
Message-ID: <20170818131855.GC27731@IUPUI.Edu>

On Thu, Aug 17, 2017 at 03:29:56PM +0000, Erwann Abalea via openssl-users wrote:
> The BR are for public CAs, not private CAs; even if some of those requirements are considered ? good practice ? (the 64 bits out of a CSPRNG is such a req), they cannot be forced on private CAs.
> And unless some or all of the browsers also apply these requirements to private CAs, you?re not forced to follow them all.

How does one mechanically distinguish public vs. private CAs?

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170818/fdef7b54/attachment.sig>

From Erwann.Abalea at docusign.com  Fri Aug 18 13:56:55 2017
From: Erwann.Abalea at docusign.com (Erwann Abalea)
Date: Fri, 18 Aug 2017 13:56:55 +0000
Subject: [openssl-users] More on cert serialnumbers
In-Reply-To: <20170818131855.GC27731@IUPUI.Edu>
References: <0e3970f1-8b7d-0d72-9adf-fa6bad16bdf7@htt-consult.com>
 <31CE1282-7267-4FF5-9B7B-C1A3407757E5@akamai.com>
 <EB6DA4E4-8EB4-4C16-B059-BA9C8D515A6D@akamai.com>
 <d6b6b9fa-7791-b9c6-8a67-b5143b78ff84@htt-consult.com>
 <4916C3E6-9105-47C9-903B-F96698C7692B@docusign.com>
 <20170818131855.GC27731@IUPUI.Edu>
Message-ID: <64663858-011F-4A13-87ED-106EF75B4A7A@docusign.com>


> Le 18 ao?t 2017 ? 15:18, Mark H. Wood <mwood at IUPUI.Edu> a ?crit :
> 
> On Thu, Aug 17, 2017 at 03:29:56PM +0000, Erwann Abalea via openssl-users wrote:
>> The BR are for public CAs, not private CAs; even if some of those requirements are considered ? good practice ? (the 64 bits out of a CSPRNG is such a req), they cannot be forced on private CAs.
>> And unless some or all of the browsers also apply these requirements to private CAs, you?re not forced to follow them all.
> 
> How does one mechanically distinguish public vs. private CAs?

OS/Browser-granted or user-granted. Each browser does it differently.


From rgm at htt-consult.com  Fri Aug 18 14:50:13 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Fri, 18 Aug 2017 10:50:13 -0400
Subject: [openssl-users] Throwing in the towel on ENV for DN
In-Reply-To: <94939056-D2A4-4207-9861-E207B2E29B42@akamai.com>
References: <d6ecb4ac-ca90-b2c3-7503-dd794365237e@htt-consult.com>
 <94939056-D2A4-4207-9861-E207B2E29B42@akamai.com>
Message-ID: <8fea3d8f-1b5b-6963-fd9b-9e83074af784@htt-consult.com>



On 08/18/2017 08:46 AM, Salz, Rich via openssl-users wrote:
> This has been a long email thread.  Can you open a github issue and summarize the improvements you think we should make?
>
> Thanks.
>
> And thanks for your patience!
>
When I get through the "lessons learned" step, I will ask you how to 
open an issue.

I just spent 2 hours fighting with variables and how to build the 
command line, until I realized that I have left "prompt = no" and made 
other changes and that where my error was...

-subj on the command line does not seem to work if "prompt = no", or it 
is processed after taking what is in cnf.

Bob

From rgm at htt-consult.com  Fri Aug 18 14:54:29 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Fri, 18 Aug 2017 10:54:29 -0400
Subject: [openssl-users] Throwing in the towel on ENV for DN
In-Reply-To: <CAH8yC8=gZYSP-Kmg7zfFAX_ScSnAFnNJgvf5-YhTdKMtx+rOiw@mail.gmail.com>
References: <d6ecb4ac-ca90-b2c3-7503-dd794365237e@htt-consult.com>
 <CAH8yC8=gZYSP-Kmg7zfFAX_ScSnAFnNJgvf5-YhTdKMtx+rOiw@mail.gmail.com>
Message-ID: <b6a42ba7-e891-77fa-9985-aea96aac02c5@htt-consult.com>



On 08/18/2017 08:48 AM, Jeffrey Walton wrote:
>> It is coming down that I would need a unique cnf for each cert type, rather
>> than one per signing CA.  Things just don't work well without prompting or
>> very consistent DN content.  So I am going to pull most of my. ENV.  I am
>> leaving it in for dir and SAN.
>>
>> I feel it is a bug that if in 'prompt = no' or -batch, if a DN object is
>> empty (size 0), it should just be dropped.  This is not an error condition.
> If this is a private PKI, then you can do things like that.
I as not clear.   meant one of the DN's objects like OU.

If you have prompt = no and

organizationalUnitName  =

It takes OU's size as zero and fails.  This should not be an error 
condition, OU should be skipped just like if you had in the command 
(which I *KNOW* works):

-subj "/CN=US/ST=MI/O= HTT Consulting/OU=/CN=Root CA"

So I call it a bug.

> But I believe you need a distinguished name if you are following the
> RFCs. Maybe you can modify your script to stuff the principal name
> from the SAN in the DN somewhere.
>
>> Next steps:
>>
>> complete basic setup for ecdsa pki and 802.1AR leaf.  Publish on my website.
>> Write up 'lessons learned' and post it here.
> I think there's a separate RFC or draft for 802.1AR, but I have not read it.
>
> Maybe part of the pain point is, OpenSSL is not aware of it. Its just
> using RFC 5280 (and to some extent, 6125).
>
> Maybe you should stop using the command line tools and code something
> up in C. Once you hit your stride using the C APIs, its easy to crank
> out certificates the way you want them.
>
> Jeff


From steve at openssl.org  Fri Aug 18 17:16:32 2017
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 18 Aug 2017 17:16:32 +0000
Subject: [openssl-users] Cant seem to get prompt no to work
In-Reply-To: <b975e16e-9b42-ceb3-6166-40ea48ab5bde@htt-consult.com>
References: <b975e16e-9b42-ceb3-6166-40ea48ab5bde@htt-consult.com>
Message-ID: <20170818171632.GA4788@openssl.org>

On Thu, Aug 17, 2017, Robert Moskowitz wrote:

> In the [ ca ] section I have:
> 
> prompt   = no
> 
> If I leave the = out I get an error, so I am assuming I got the
> format of this right.
> 
> Then I have
> 
> [ req ]
> distinguished_name  = req_distinguished_name
> 
> [ req_distinguished_name ]
> countryName                     = $ENV::countryName
> stateOrProvinceName             = $ENV::stateOrProvinceName
> 
> In a terminal window I run:
> 
> export countryName=US
> export stateOrProvinceName=MI
> 
> then
> 
> openssl req -config openssl-root.cnf -key private/ca.key.pem \
>       -new -x509 -days 7300 -sha256 -extensions v3_ca -out
> certs/ca.cert.pem
> 
> 
> And I am still getting prompted for the DN fields:
> 
> You are about to be asked to enter information that will be incorporated
> into your certificate request.
> What you are about to enter is what is called a Distinguished Name or a DN.
> There are quite a few fields but you can leave some blank
> For some fields there will be a default value,
> If you enter '.', the field will be left blank.
> -----
> US []:
> 
> What did I miss?
> 

Since this is the req command try "prompt = no" in the req section.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From rgm at htt-consult.com  Fri Aug 18 17:30:06 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Fri, 18 Aug 2017 13:30:06 -0400
Subject: [openssl-users] Cant seem to get prompt no to work
In-Reply-To: <20170818171632.GA4788@openssl.org>
References: <b975e16e-9b42-ceb3-6166-40ea48ab5bde@htt-consult.com>
 <20170818171632.GA4788@openssl.org>
Message-ID: <e3f17c30-38e8-5f14-8209-3987b37c78f0@htt-consult.com>



On 08/18/2017 01:16 PM, Dr. Stephen Henson wrote:
> On Thu, Aug 17, 2017, Robert Moskowitz wrote:
>
>> In the [ ca ] section I have:
>>
>> prompt   = no
>>
>> If I leave the = out I get an error, so I am assuming I got the
>> format of this right.
>>
>> Then I have
>>
>> [ req ]
>> distinguished_name  = req_distinguished_name
>>
>> [ req_distinguished_name ]
>> countryName                     = $ENV::countryName
>> stateOrProvinceName             = $ENV::stateOrProvinceName
>>
>> In a terminal window I run:
>>
>> export countryName=US
>> export stateOrProvinceName=MI
>>
>> then
>>
>> openssl req -config openssl-root.cnf -key private/ca.key.pem \
>>        -new -x509 -days 7300 -sha256 -extensions v3_ca -out
>> certs/ca.cert.pem
>>
>>
>> And I am still getting prompted for the DN fields:
>>
>> You are about to be asked to enter information that will be incorporated
>> into your certificate request.
>> What you are about to enter is what is called a Distinguished Name or a DN.
>> There are quite a few fields but you can leave some blank
>> For some fields there will be a default value,
>> If you enter '.', the field will be left blank.
>> -----
>> US []:
>>
>> What did I miss?
>>
> Since this is the req command try "prompt = no" in the req section.

Thank you, but I did get past this point.  I got prompt no working and 
the way it worked, just did not work well enough.

I threw the towel in on ENV and did get -subj $DN working...

thanks

Bob


From rgm at htt-consult.com  Fri Aug 18 19:22:43 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Fri, 18 Aug 2017 15:22:43 -0400
Subject: [openssl-users] Pilgrims progress
Message-ID: <51957b87-11aa-c898-fdff-0608b60d535c@htt-consult.com>

I have made it through the basics.  Thanks for all the help.  The fruits 
of my labor can be found at:

http://www.htt-consult.com/pki

under roll your own CA and 802.1AR

There is a link there for my current 'lessons learned'.  I will be 
adding more to this:

http://www.htt-consult.com/pki/openSSL-lessons-learned.txt

Next week I hope to find time to work on CRL and OCSP support.

Thanks and have a good weekend!

Bob


From peter.sylvester at gmail.com  Sat Aug 19 08:00:14 2017
From: peter.sylvester at gmail.com (Peter Sylvester)
Date: Sat, 19 Aug 2017 10:00:14 +0200
Subject: [openssl-users] Cant seem to get prompt no to work
In-Reply-To: <20170818171632.GA4788@openssl.org>
References: <b975e16e-9b42-ceb3-6166-40ea48ab5bde@htt-consult.com>
 <20170818171632.GA4788@openssl.org>
Message-ID: <90bfd124-f36b-4cde-081c-025c7ea5bdda@gmail.com>

On 08/18/2017 07:16 PM, Dr. Stephen Henson wrote:
> On Thu, Aug 17, 2017, Robert Moskowitz wrote:
>
>> In the [ ca ] section I have:
>>
>> prompt   = no
>>
>> If I leave the = out I get an error, so I am assuming I got the
>> format of this right.
>>
>> Then I have
>>
>> [ req ]
>> distinguished_name  = req_distinguished_name
>>
>> [ req_distinguished_name ]
>> countryName                     = $ENV::countryName
>> stateOrProvinceName             = $ENV::stateOrProvinceName
>>
>> In a terminal window I run:
>>
>> export countryName=US
>> export stateOrProvinceName=MI
What about:

[ req_distinguished_name ]
countryName                     = "Country Nmae (e.g. FR)"
countryName_value                     = $ENV::countryName
stateOrProvinceName             = "State or Province"
stateOrProvinceName_value             = $ENV::stateOrProvinceName

 


From rgm at htt-consult.com  Sun Aug 20 02:56:09 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Sat, 19 Aug 2017 22:56:09 -0400
Subject: [openssl-users] Cant seem to get prompt no to work
In-Reply-To: <90bfd124-f36b-4cde-081c-025c7ea5bdda@gmail.com>
References: <b975e16e-9b42-ceb3-6166-40ea48ab5bde@htt-consult.com>
 <20170818171632.GA4788@openssl.org>
 <90bfd124-f36b-4cde-081c-025c7ea5bdda@gmail.com>
Message-ID: <ad72c23a-b8ff-dd0a-6cb9-5f1b991dd4a6@htt-consult.com>



On 08/19/2017 04:00 AM, Peter Sylvester wrote:
> On 08/18/2017 07:16 PM, Dr. Stephen Henson wrote:
>> On Thu, Aug 17, 2017, Robert Moskowitz wrote:
>>
>>> In the [ ca ] section I have:
>>>
>>> prompt   = no
>>>
>>> If I leave the = out I get an error, so I am assuming I got the
>>> format of this right.
>>>
>>> Then I have
>>>
>>> [ req ]
>>> distinguished_name  = req_distinguished_name
>>>
>>> [ req_distinguished_name ]
>>> countryName                     = $ENV::countryName
>>> stateOrProvinceName             = $ENV::stateOrProvinceName
>>>
>>> In a terminal window I run:
>>>
>>> export countryName=US
>>> export stateOrProvinceName=MI
> What about:
>
> [ req_distinguished_name ]
> countryName                     = "Country Nmae (e.g. FR)"
> countryName_value                     = $ENV::countryName
> stateOrProvinceName             = "State or Province"
> stateOrProvinceName_value             = $ENV::stateOrProvinceName
>
>   
>
And what happens when you have

stateOrProvinceName=

the length of stateOrProvinceName_value is zero.

When stateOrProvinceName was length zero, I got the error.

Bob


From rgm at htt-consult.com  Sun Aug 20 12:35:43 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Sun, 20 Aug 2017 08:35:43 -0400
Subject: [openssl-users] Clearing up some of my mistakes on serial number
Message-ID: <c874107d-257c-9f35-d1b8-a8d1d170df84@htt-consult.com>

It is 64 - 160 BITS

Which is 8 - 20 OCTETS

or 4 - 10 BYTES

And

openssl rand -hex n

Generates n BYTES

Thus what openssl does by default for a self-signed cert, e.g. a root CA 
cert of a serial of 8 BYTES is indeed Best Practice, given that if the 
first bit were ONE, the serial would then be 8 BYTES.

I had to slow down, take a step away, to see that I was tripping my self 
up on the OCTET/BYTE bit.

So I am correcting my guide to use

openssl rand -hex 8

And the probability of a collision is just not worth talking  about.

in a population of 2^64, 1 million random selections has a 2.7E-6 % 
collision probability.

You go up to 1 billion and the probability does drop to 2.7%.

In a population of 2^159, you have to select 10^18 to get a collision 
probability of 6.8E11 %; just not worth dealing with.

So randomly selecting serial numbers will unlikely result in collisions 
if you are doing this for you IoT run of 10 million per year, using an 8 
BYTE serial number.

And since we are using SHA256 with ECDSA, the known attacks are just not 
real.  Yet.

So in my highly biased opinion....

If you have the memory and bandwidth, go ahead with 8 bytes for serial.

In constrained IoT, 4 bytes works.

Also going to next look at BER over DER for IoT usage.

BTW the above calculations are based on:

p = 1 - e^{-k^2/(2n)}

Where n = total population and k is selected subset.


Bob


From openssl-users at dukhovni.org  Sun Aug 20 13:32:05 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 20 Aug 2017 09:32:05 -0400
Subject: [openssl-users] Clearing up some of my mistakes on serial number
In-Reply-To: <c874107d-257c-9f35-d1b8-a8d1d170df84@htt-consult.com>
References: <c874107d-257c-9f35-d1b8-a8d1d170df84@htt-consult.com>
Message-ID: <27D05167-D37E-49BF-A52C-261E7961EC86@dukhovni.org>


> On Aug 20, 2017, at 8:35 AM, Robert Moskowitz <rgm at htt-consult.com> wrote:
> 
> It is 64 - 160 BITS

Correct, with the word "cryptographically random" somewhere in
there, for at least 64 of the bits.

> Which is 8 - 20 OCTETS

Correct, since an "octet" is 8 bits.

> or 4 - 10 BYTES

No, a "byte" nowdays is the same as an "octet", though there have been
variant definitions of byte, while "octets" have always been 8 bits.

-- 
	Viktor.


From rsalz at akamai.com  Sun Aug 20 13:50:33 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 20 Aug 2017 13:50:33 +0000
Subject: [openssl-users] Clearing up some of my mistakes on serial number
In-Reply-To: <c874107d-257c-9f35-d1b8-a8d1d170df84@htt-consult.com>
References: <c874107d-257c-9f35-d1b8-a8d1d170df84@htt-consult.com>
Message-ID: <AA687956-EB60-4F8B-89DE-F293E44EF5FC@akamai.com>

If you generate 19 bytes or RAND output, it will never exceed 20 bytes encoded.

OpenSSL will be generating 159 bits of RAND output, so that it will never exceed 20 bytes encoded. The command-line RAND program is bytes, the C API is bits.
 


From rgm at htt-consult.com  Sun Aug 20 14:15:27 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Sun, 20 Aug 2017 10:15:27 -0400
Subject: [openssl-users] Clearing up some of my mistakes on serial number
In-Reply-To: <27D05167-D37E-49BF-A52C-261E7961EC86@dukhovni.org>
References: <c874107d-257c-9f35-d1b8-a8d1d170df84@htt-consult.com>
 <27D05167-D37E-49BF-A52C-261E7961EC86@dukhovni.org>
Message-ID: <24fb7277-6d11-9ee5-b2aa-26699856677a@htt-consult.com>



On 08/20/2017 09:32 AM, Viktor Dukhovni wrote:
>> On Aug 20, 2017, at 8:35 AM, Robert Moskowitz <rgm at htt-consult.com> wrote:
>>
>> It is 64 - 160 BITS
> Correct, with the word "cryptographically random" somewhere in
> there, for at least 64 of the bits.
>
>> Which is 8 - 20 OCTETS
> Correct, since an "octet" is 8 bits.
>
>> or 4 - 10 BYTES
> No, a "byte" nowdays is the same as an "octet", though there have been
> variant definitions of byte, while "octets" have always been 8 bits.
>
ARGH!!!

I am going back to bed....  :)

:)

Thanks Viktor.

But my bit collision analysis still holds true.  Collisions are not a 
concern if openssl rand is a good prf.



From rgm at htt-consult.com  Sun Aug 20 14:30:30 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Sun, 20 Aug 2017 10:30:30 -0400
Subject: [openssl-users] Clearing up some of my mistakes on serial number
In-Reply-To: <AA687956-EB60-4F8B-89DE-F293E44EF5FC@akamai.com>
References: <c874107d-257c-9f35-d1b8-a8d1d170df84@htt-consult.com>
 <AA687956-EB60-4F8B-89DE-F293E44EF5FC@akamai.com>
Message-ID: <9083af88-88ca-2b06-2972-e49a22e86855@htt-consult.com>



On 08/20/2017 09:50 AM, Salz, Rich via openssl-users wrote:
> If you generate 19 bytes or RAND output, it will never exceed 20 bytes encoded.
>
> OpenSSL will be generating 159 bits of RAND output, so that it will never exceed 20 bytes encoded. The command-line RAND program is bytes, the C API is bits.
>   
>
So Viktor reminded me about bits, bytes and octets.

Too much on the brain.  No real excuse.

Back to the drawing broad.

A bit.

8 bits is a byte.  8 bits is a byte.  8 bits is a byte.  8 bits is a byte.

Two hex positions is a byte.  One hex position is a nibble.

:)

I'll get it straight yet.

Bob


From ted at convey.de  Mon Aug 21 10:58:36 2017
From: ted at convey.de (=?UTF-8?Q?Bernhard_Fr=c3=b6hlich?=)
Date: Mon, 21 Aug 2017 12:58:36 +0200
Subject: [openssl-users] Question about X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN
 for a cert chain including the root cert
Message-ID: <c583ca64-6257-5434-8bb8-3754e79c3510@convey.de>

Hi there,

I have a question about certificate chain checkin when the chain 
includes a root certificate.

The server I want to connect to with openssl s_client (Version 0.9.8zc) 
sends this certificate chain:

0 s:Server's cert
  i:Intermediate cert
1 s:Intermediate cert
  i:Root 1 cert
2 s:Root 1 cert
  i: Root 2 cert
3 s:Root 2 cert
  i:Root 2 cert

If my CA file includes the self signed Root 1 cert, but not the "Root 2 
cert" I get "Verify return code: 19 (self signed certificate in 
certificate chain)"
If I add the Root 2 cert to the CA file everything is fine.
If I try openssl verify on the Server's cert with a CA file including 
Intermediate cert and self-signed Root 1 cert, but not Root 2 cert, 
verify reports OK.

My view was that the Root 1 cert in the CA file should verify the chain. 
Obviously it does not, but why?
Are two certificates with the same subject but different issuer 
considered different? Or is this an issue with my ancient openssl version?

Kind regards
Ted

-- 
PGP Public Key Information
Key ID = 7AFB8D26
Key fingerprint = 31B0 E029 BCF9 6605 DAC1  B2E1 0CC8 70F4 7AFB 8D26



From rgm at htt-consult.com  Mon Aug 21 13:06:43 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Mon, 21 Aug 2017 09:06:43 -0400
Subject: [openssl-users] Using set_serial to control serial number size
	directly
Message-ID: <7c82709e-e4d0-5efd-c329-7c7549a1be35@htt-consult.com>

I have worked out that:

openssl req -config openssl-root.cnf -set_serial 0x$(openssl rand -hex 
19) -key private/ca.key.pem\
       -subj "$DN"\
       -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
certs/ca.cert.pem


allows you to override the serial number select process and thus control 
what size serial number you use.

This also works for openssl ca for signing a csr, so you don't have to 
deal with the serial file.

You can further parameterize this with:

-set_serial 0x$(openssl rand -hex $sn)

when sn=some number 8 to 19.

But in doing this, I can't figure out if there is a risk on serial 
number size for a root CA cert as there is for any other cert.  The 
nature of the attack, just to me, does not seem to apply to a root CA 
cert.  So that a serial number size of 8 octets is just fine for the 
root cert.

Please correct me if I don't have the risk properly understood.

thanks

Bob


From rsalz at akamai.com  Mon Aug 21 13:20:57 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 21 Aug 2017 13:20:57 +0000
Subject: [openssl-users] Using set_serial to control serial number size
 directly
In-Reply-To: <7c82709e-e4d0-5efd-c329-7c7549a1be35@htt-consult.com>
References: <7c82709e-e4d0-5efd-c329-7c7549a1be35@htt-consult.com>
Message-ID: <BBCFC482-4943-4C4E-8200-7E92FFCA402D@akamai.com>


    But in doing this, I can't figure out if there is a risk on serial 
    number size for a root CA cert as there is for any other cert.

I don?t understand what attack you are concerned about, but the size of the serial number should not matter for *any* certificate.


From rgm at htt-consult.com  Mon Aug 21 13:32:36 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Mon, 21 Aug 2017 09:32:36 -0400
Subject: [openssl-users] Using set_serial to control serial number size
 directly
In-Reply-To: <BBCFC482-4943-4C4E-8200-7E92FFCA402D@akamai.com>
References: <7c82709e-e4d0-5efd-c329-7c7549a1be35@htt-consult.com>
 <BBCFC482-4943-4C4E-8200-7E92FFCA402D@akamai.com>
Message-ID: <f672c109-6e46-e11f-b969-90af53f847bf@htt-consult.com>



On 08/21/2017 09:20 AM, Salz, Rich via openssl-users wrote:
>      But in doing this, I can't figure out if there is a risk on serial
>      number size for a root CA cert as there is for any other cert.
>
> I don?t understand what attack you are concerned about, but the size of the serial number should not matter for *any* certificate.
>
This whole subject is tied into the substitution attack found with using 
an MD5 hash where you could change some things in the cert and still 
have a valid cert.  The solution, besides dropping MD5, was to include a 
crypto random number in the beginning of the cert, and the serial was 
chosen for this sacrifice.  Thus how large does this random number have 
to be to defend against this attack?  is 8 octets enough or is 20 needed?

This is to make another valid cert with a different keypair.  OK, I get 
this for a cert signed by an issuer.  But the root issuer?  I don't see 
the attack.  Thus no need to push the root cert's serial to 20 octets.

I know I am a little cavalier in describing the attack, but that was the 
basic point of why to move away from sequential serials to random and 
what size (though there are other things about CAs that can be 
discovered by analyzing the sequential serial numbers they used).

Meanwhile, I was wrong that -set_serial works with 'openssl ca'. The man 
page was talking about in conjunction with the -CA option. With 'openssl 
ca' use of the serial file is mandatory according to the man page.  
There are no command line options for it.

Bob


From rsalz at akamai.com  Mon Aug 21 13:36:40 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 21 Aug 2017 13:36:40 +0000
Subject: [openssl-users] Using set_serial to control serial number size
 directly
In-Reply-To: <f672c109-6e46-e11f-b969-90af53f847bf@htt-consult.com>
References: <7c82709e-e4d0-5efd-c329-7c7549a1be35@htt-consult.com>
 <BBCFC482-4943-4C4E-8200-7E92FFCA402D@akamai.com>
 <f672c109-6e46-e11f-b969-90af53f847bf@htt-consult.com>
Message-ID: <3D3718DE-EC45-4271-B22F-064A1195F659@akamai.com>

? Thus how large does this random number have 

It?s also to protect against predicting serial numbers and being able to leverage that.  It?s not just (nor really mainly) the MD5 digest attacks.  According to CABForum, you need 8 octets.  No reason not to use more if you can.


? page was talking about in conjunction with the -CA option. With 'openssl 
    ca' use of the serial file is mandatory according to the man page.  
    There are no command line options for it.

Fixed in master and will be part of the next releases; the ?rand_serial flag.    


From rgm at htt-consult.com  Mon Aug 21 13:44:36 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Mon, 21 Aug 2017 09:44:36 -0400
Subject: [openssl-users] Using set_serial to control serial number size
 directly
In-Reply-To: <3D3718DE-EC45-4271-B22F-064A1195F659@akamai.com>
References: <7c82709e-e4d0-5efd-c329-7c7549a1be35@htt-consult.com>
 <BBCFC482-4943-4C4E-8200-7E92FFCA402D@akamai.com>
 <f672c109-6e46-e11f-b969-90af53f847bf@htt-consult.com>
 <3D3718DE-EC45-4271-B22F-064A1195F659@akamai.com>
Message-ID: <1f63ae4c-08d2-0d8f-8e9a-ba61084d5316@htt-consult.com>



On 08/21/2017 09:36 AM, Salz, Rich wrote:
> ? Thus how large does this random number have
>
> It?s also to protect against predicting serial numbers and being able to leverage that.  It?s not just (nor really mainly) the MD5 digest attacks.  According to CABForum, you need 8 octets.  No reason not to use more if you can.

Sure there is.  On constrained systems with constrained communication 
links.  Every byte counts.  My real thrust on this is for IoT.  To get 
IoT developers to build around certs and know their products work with 
them instead of, well we will get to it eventually.

When I work with 802.15.4 communications with a 128 byte MTU, there is 
considerable debate over every byte sent.  When you tell an IoT chip 
maker that they have to go from 32KB memory to 100MB, they walk out of 
the room.

Oh, I want DOTS and I2NSF developers to be working with certs from the 
get go, instead waiting for deployments and getting 'production' certs 
and THEN discovering what works and what does not.  But IoT is in many 
ways more of a challenge.

So yes, size matters.

>
>
> ? page was talking about in conjunction with the -CA option. With 'openssl
>      ca' use of the serial file is mandatory according to the man page.
>      There are no command line options for it.
>
> Fixed in master and will be part of the next releases; the ?rand_serial flag.
>


From rsalz at akamai.com  Mon Aug 21 14:03:55 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 21 Aug 2017 14:03:55 +0000
Subject: [openssl-users] Using set_serial to control serial number size
 directly
In-Reply-To: <1f63ae4c-08d2-0d8f-8e9a-ba61084d5316@htt-consult.com>
References: <7c82709e-e4d0-5efd-c329-7c7549a1be35@htt-consult.com>
 <BBCFC482-4943-4C4E-8200-7E92FFCA402D@akamai.com>
 <f672c109-6e46-e11f-b969-90af53f847bf@htt-consult.com>
 <3D3718DE-EC45-4271-B22F-064A1195F659@akamai.com>
 <1f63ae4c-08d2-0d8f-8e9a-ba61084d5316@htt-consult.com>
Message-ID: <533B92D1-D2A1-45E0-8089-078A40BD12C4@akamai.com>

If the root is going to be trusted, make its serial number be one. ?
Otherwise use eight bytes of random as the serial number, if you follow CABF guidelines.
 


From rgm at htt-consult.com  Mon Aug 21 14:22:05 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Mon, 21 Aug 2017 10:22:05 -0400
Subject: [openssl-users] Using set_serial to control serial number size
 directly
In-Reply-To: <533B92D1-D2A1-45E0-8089-078A40BD12C4@akamai.com>
References: <7c82709e-e4d0-5efd-c329-7c7549a1be35@htt-consult.com>
 <BBCFC482-4943-4C4E-8200-7E92FFCA402D@akamai.com>
 <f672c109-6e46-e11f-b969-90af53f847bf@htt-consult.com>
 <3D3718DE-EC45-4271-B22F-064A1195F659@akamai.com>
 <1f63ae4c-08d2-0d8f-8e9a-ba61084d5316@htt-consult.com>
 <533B92D1-D2A1-45E0-8089-078A40BD12C4@akamai.com>
Message-ID: <df050d70-9043-6c9c-cbfa-9e4f3f5c6910@htt-consult.com>



On 08/21/2017 10:03 AM, Salz, Rich wrote:
> If the root is going to be trusted, make its serial number be one. ?
> Otherwise use eight bytes of random as the serial number, if you follow CABF guidelines.

Kind of where my thinking is going.  But once I make it '1', it might as 
well be 1 byte rand!  :)

Well 1 - 127 random...

But no need to make it 20 octets.  Just leave it at 8.  And yes, I can 
see some jump on the 'save' 7 bytes bandwagon.  Also why I have to work 
out BER to compare that sizing to DER.  Trying to do that today.

Bob


From rgm at htt-consult.com  Mon Aug 21 15:40:06 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Mon, 21 Aug 2017 11:40:06 -0400
Subject: [openssl-users] problem with -aes256 and -outform der in cmmand
Message-ID: <7a5e6660-5577-3236-5697-44a41537e996@htt-consult.com>

If I use format=pem in the following:

openssl genpkey -outform $format -aes256 -algorithm ec -pkeyopt 
ec_paramgen_curve:prime256v1 \
     -pkeyopt ec_param_enc:named_curve -out private/ca.key.$format

the private key is password protected.

But if I use format=der

I do not get prompted for the password.

The pem file is 379 bytes and the der is 121, but that is not a valid 
comparison as der is not encrypted...

Is this a bug?  Or a feature?

Bob


From rsalz at akamai.com  Mon Aug 21 15:43:05 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 21 Aug 2017 15:43:05 +0000
Subject: [openssl-users] problem with -aes256 and -outform der in cmmand
In-Reply-To: <7a5e6660-5577-3236-5697-44a41537e996@htt-consult.com>
References: <7a5e6660-5577-3236-5697-44a41537e996@htt-consult.com>
Message-ID: <45674182-CEDE-41B5-B6C0-DE79D277FF58@akamai.com>

? But if I use format=der I do not get prompted for the password.
   
DER does not support encryption.  The bug is that the command does not tell you this.


From rgm at htt-consult.com  Mon Aug 21 15:49:45 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Mon, 21 Aug 2017 11:49:45 -0400
Subject: [openssl-users] problem with -aes256 and -outform der in cmmand
In-Reply-To: <45674182-CEDE-41B5-B6C0-DE79D277FF58@akamai.com>
References: <7a5e6660-5577-3236-5697-44a41537e996@htt-consult.com>
 <45674182-CEDE-41B5-B6C0-DE79D277FF58@akamai.com>
Message-ID: <74b231a8-6ce9-2878-6e3b-c41867976d9f@htt-consult.com>



On 08/21/2017 11:43 AM, Salz, Rich via openssl-users wrote:
> ? But if I use format=der I do not get prompted for the password.
>     
> DER does not support encryption.  The bug is that the command does not tell you this.
>
OK.  And why does DER not support encryption?  Actually, I can see 
working around this.  The CA certs private keys can be in PEM and 
everything else in DER.  Provided I can get all the inform and outforms 
right.

But for now I will 'live' with unencrypted DER CA private keys.

Bob

From rsalz at akamai.com  Mon Aug 21 15:52:38 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 21 Aug 2017 15:52:38 +0000
Subject: [openssl-users] problem with -aes256 and -outform der in cmmand
In-Reply-To: <74b231a8-6ce9-2878-6e3b-c41867976d9f@htt-consult.com>
References: <7a5e6660-5577-3236-5697-44a41537e996@htt-consult.com>
 <45674182-CEDE-41B5-B6C0-DE79D277FF58@akamai.com>
 <74b231a8-6ce9-2878-6e3b-c41867976d9f@htt-consult.com>
Message-ID: <EBB51E43-80F7-4D79-89ED-2564AE0CBBB7@akamai.com>

? OK.  And why does DER not support encryption

Because it is not defined.  If you want to encrypt keys, you need to use PKCS12 which might be too much for your application.


From vieuxtech at gmail.com  Mon Aug 21 15:58:19 2017
From: vieuxtech at gmail.com (Sam Roberts)
Date: Mon, 21 Aug 2017 08:58:19 -0700
Subject: [openssl-users] problem with -aes256 and -outform der in cmmand
In-Reply-To: <EBB51E43-80F7-4D79-89ED-2564AE0CBBB7@akamai.com>
References: <7a5e6660-5577-3236-5697-44a41537e996@htt-consult.com>
 <45674182-CEDE-41B5-B6C0-DE79D277FF58@akamai.com>
 <74b231a8-6ce9-2878-6e3b-c41867976d9f@htt-consult.com>
 <EBB51E43-80F7-4D79-89ED-2564AE0CBBB7@akamai.com>
Message-ID: <CA+Sj9T=pr_C+Rv-hQ-Y3UExLz-t4+fL=-DZuJFMfRs1g81LckQ@mail.gmail.com>

Probably I misunderstand the context, since PKCS#8 can be used to
encrypt EC private key info, some more info at
https://tools.ietf.org/html/rfc5915. Which doesn't help the OP if the
openssl CLI doesn't support it.


On Mon, Aug 21, 2017 at 8:52 AM, Salz, Rich via openssl-users
<openssl-users at openssl.org> wrote:
> ? OK.  And why does DER not support encryption
>
> Because it is not defined.  If you want to encrypt keys, you need to use PKCS12 which might be too much for your application.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From rgm at htt-consult.com  Mon Aug 21 16:04:06 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Mon, 21 Aug 2017 12:04:06 -0400
Subject: [openssl-users] problem with -aes256 and -outform der in cmmand
In-Reply-To: <EBB51E43-80F7-4D79-89ED-2564AE0CBBB7@akamai.com>
References: <7a5e6660-5577-3236-5697-44a41537e996@htt-consult.com>
 <45674182-CEDE-41B5-B6C0-DE79D277FF58@akamai.com>
 <74b231a8-6ce9-2878-6e3b-c41867976d9f@htt-consult.com>
 <EBB51E43-80F7-4D79-89ED-2564AE0CBBB7@akamai.com>
Message-ID: <3b06fbdc-341c-9acf-88c8-ddd734823d5c@htt-consult.com>



On 08/21/2017 11:52 AM, Salz, Rich wrote:
> ? OK.  And why does DER not support encryption
>
> Because it is not defined.  If you want to encrypt keys, you need to use PKCS12 which might be too much for your application.
>
If a device has secure storage, it does not need to encrypt its private 
key.  It all depends on the architecture.

Or they can implement whatever works in their device to protect the keys.

The root CA is not a problem as it is offline except to make new 
intermediate CAs.  In fact for Singapore, I hope to have the root CA be 
a mSD card with Fedora26 for a Cubieboard2.  Pop the card in, and there 
is your root CA.  And a different mSD card for the signing CA!  I can do 
this all offline.  Just put the CSR on a USB drive and insert it in one 
of the Cubie's USB ports and sign away!

I just need to document this all.  That is all.  :)

Bob


From Erwann.Abalea at docusign.com  Mon Aug 21 16:26:02 2017
From: Erwann.Abalea at docusign.com (Erwann Abalea)
Date: Mon, 21 Aug 2017 16:26:02 +0000
Subject: [openssl-users] Using set_serial to control serial number size
 directly
In-Reply-To: <1f63ae4c-08d2-0d8f-8e9a-ba61084d5316@htt-consult.com>
References: <7c82709e-e4d0-5efd-c329-7c7549a1be35@htt-consult.com>
 <BBCFC482-4943-4C4E-8200-7E92FFCA402D@akamai.com>
 <f672c109-6e46-e11f-b969-90af53f847bf@htt-consult.com>
 <3D3718DE-EC45-4271-B22F-064A1195F659@akamai.com>
 <1f63ae4c-08d2-0d8f-8e9a-ba61084d5316@htt-consult.com>
Message-ID: <15993487-6605-4AA9-85D1-276083B2ED7A@docusign.com>

My proposal.

Keep k bits (k/8 octets) long serial numbers for all your certificates, chose a block cipher operating on blocks of k bits, and operate this block cipher in CTR mode, with a proper secret key and secret starting counter. That way, no collision detection is necessary, you?ll be able to generate 2^(k/2) unique k bits longs serial numbers (in fact, you can generate 2^k unique serial numbers, but after 2^(k/2) you lose some security guarantees).

With 3DES, k=64, and with AES, k=128.
Since you need to make a tradeoff between security and size, you can play with lightweight block ciphers such as Simon, Speck, or find some tweakable lightweight block cipher, maybe from the ECRYPT portfolio (it?s down at this moment).

Again, the 64bits coming from a CSPRNG is for public CAs only, and the uniqueness of a serial number is a dirty hack to be able to use a non collision-resistant hash function a little longer. If you?re confident the hash function used for signature is collision resistant (for example a member of the SHA2 or SHA3 family), and you have a purely private CA, don?t bother will all this, the only hard requirement is the unicity of the tuple {CA name, serial number}.

Cordialement,
Erwann Abalea

> Le 21 ao?t 2017 ? 15:44, Robert Moskowitz <rgm at htt-consult.com> a ?crit :
> 
> 
> 
> On 08/21/2017 09:36 AM, Salz, Rich wrote:
>> ? Thus how large does this random number have
>> 
>> It?s also to protect against predicting serial numbers and being able to leverage that.  It?s not just (nor really mainly) the MD5 digest attacks.  According to CABForum, you need 8 octets.  No reason not to use more if you can.
> 
> Sure there is.  On constrained systems with constrained communication links.  Every byte counts.  My real thrust on this is for IoT.  To get IoT developers to build around certs and know their products work with them instead of, well we will get to it eventually.
> 
> When I work with 802.15.4 communications with a 128 byte MTU, there is considerable debate over every byte sent.  When you tell an IoT chip maker that they have to go from 32KB memory to 100MB, they walk out of the room.
> 
> Oh, I want DOTS and I2NSF developers to be working with certs from the get go, instead waiting for deployments and getting 'production' certs and THEN discovering what works and what does not.  But IoT is in many ways more of a challenge.
> 
> So yes, size matters.
> 
>> 
>> 
>> ? page was talking about in conjunction with the -CA option. With 'openssl
>>     ca' use of the serial file is mandatory according to the man page.
>>     There are no command line options for it.
>> 
>> Fixed in master and will be part of the next releases; the ?rand_serial flag.
>> 


From openssl-users at dukhovni.org  Mon Aug 21 16:59:40 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 21 Aug 2017 16:59:40 +0000
Subject: [openssl-users] problem with -aes256 and -outform der in cmmand
In-Reply-To: <45674182-CEDE-41B5-B6C0-DE79D277FF58@akamai.com>
References: <7a5e6660-5577-3236-5697-44a41537e996@htt-consult.com>
 <45674182-CEDE-41B5-B6C0-DE79D277FF58@akamai.com>
Message-ID: <20170821165940.GK8146@mournblade.imrryr.org>

On Mon, Aug 21, 2017 at 03:43:05PM +0000, Salz, Rich via openssl-users wrote:

> ? But if I use format=der I do not get prompted for the password.
>    
> DER does not support encryption.  The bug is that the command does not tell you this.

There is at least one standard encryption-capable ASN.1 private
key format, namely PKCS#8, and therefore a DER encoding thereof.
However, the (gen)pkey command does not support direct input or
output of encrypted PKCS8 in DER form.  This is a reflection of
the underlying API.

    ---------------- Note, takes no password argument:
    d2i_PrivateKey(3)               OpenSSL                  d2i_PrivateKey(3)

    NAME
       d2i_Private_key, d2i_AutoPrivateKey, i2d_PrivateKey - decode and encode
       functions for reading and saving EVP_PKEY structures.

    SYNOPSIS
        #include <openssl/evp.h>

        EVP_PKEY *d2i_PrivateKey(int type, EVP_PKEY **a, const unsigned char **pp,
                                 long length);
        EVP_PKEY *d2i_AutoPrivateKey(EVP_PKEY **a, const unsigned char **pp,
                                     long length);

    ...

    NOTES
       All these functions use DER format and unencrypted keys. Applications
       wishing to encrypt or decrypt private keys should use other functions
       such as d2i_PKC8PrivateKey() instead.

    ---------------------- Note, takes a password argument:
    d2i_PKCS8PrivateKey(3)              OpenSSL             d2i_PKCS8PrivateKey(3)

    NAME
       d2i_PKCS8PrivateKey_bio, d2i_PKCS8PrivateKey_fp,
       i2d_PKCS8PrivateKey_bio, i2d_PKCS8PrivateKey_fp,
       i2d_PKCS8PrivateKey_nid_bio, i2d_PKCS8PrivateKey_nid_fp - PKCS#8 format
       private key functions

    SYNOPSIS
        #include <openssl/evp.h>

        EVP_PKEY *d2i_PKCS8PrivateKey_bio(BIO *bp, EVP_PKEY **x, pem_password_cb *cb, void *u);
        EVP_PKEY *d2i_PKCS8PrivateKey_fp(FILE *fp, EVP_PKEY **x, pem_password_cb *cb, void *u);

So, while you can indirectly generate encrypted DER private keys:

    $ openssl genpkey -algorithm rsa -pkeyopt rsa_keygen_bits:2048 |
        openssl pkcs8 -topk8 -v2 aes-128-cbc -outform DER -out key.der
    .......................................+++
    ............+++
    Enter Encryption Password:
    Verifying - Enter Encryption Password:

    $ openssl asn1parse -in key.der -inform DER
	openssl asn1parse -inform DER
	0:d=0  hl=4 l=1311 cons: SEQUENCE
	4:d=1  hl=2 l=  73 cons: SEQUENCE
	6:d=2  hl=2 l=   9 prim: OBJECT            :PBES2
       17:d=2  hl=2 l=  60 cons: SEQUENCE
       19:d=3  hl=2 l=  27 cons: SEQUENCE
       21:d=4  hl=2 l=   9 prim: OBJECT            :PBKDF2
       32:d=4  hl=2 l=  14 cons: SEQUENCE
       34:d=5  hl=2 l=   8 prim: OCTET STRING      [HEX DUMP]:9C914F36B0FDC2D0
       44:d=5  hl=2 l=   2 prim: INTEGER           :0800
       48:d=3  hl=2 l=  29 cons: SEQUENCE
       50:d=4  hl=2 l=   9 prim: OBJECT            :aes-128-cbc
       61:d=4  hl=2 l=  16 prim: OCTET STRING      [HEX DUMP]:...iv...
       79:d=1  hl=4 l=1232 prim: OCTET STRING      [HEX DUMP]:...ciphertext...

they can't directly be used with any of the OpenSSL "-inkey" or
similar options, as those don't assume PKCS8 and typically use:

    EVP_PKEY *PEM_read_bio_PrivateKey(BIO *bp, EVP_PKEY **x,
				      pem_password_cb *cb, void *u);

    EVP_PKEY *PEM_read_PrivateKey(FILE *fp, EVP_PKEY **x,
				  pem_password_cb *cb, void *u);

the DER counterparts lack the password argument and can't read
encrypted keys.  So encrypted PKCS#8 is fine for moving keys
between organizations, systems or people, but for data at rest,
if you want encrypted keys, you'll need PEM.

Use a strong passphrase, as the PBKDF for PEM encryption is
weak.

-- 
	Viktor.

From rgm at htt-consult.com  Mon Aug 21 17:26:59 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Mon, 21 Aug 2017 13:26:59 -0400
Subject: [openssl-users] Problem with DER private key file into openssl ca
Message-ID: <0f6c8d5e-2711-0c47-67f2-3d02edd57b5b@htt-consult.com>

format=der

openssl pkey -inform $format -in private/ca.key.$format -text -noout

Private-Key: (256 bit)
priv:
     48:b3:4e:c5:0a:0c:af:78:b9:a2:d4:b8:7e:18:78:
     f2:39:9c:77:51:a3:1c:6f:df:31:20:e3:e4:9a:52:
     3d:06
pub:
     04:ce:ff:5d:d4:c7:b6:9c:c2:31:d9:38:fe:2b:9c:
     70:3a:fd:22:6d:97:d0:10:23:b3:57:6b:a9:51:e8:
     ce:db:16:0e:6e:8f:31:ca:6c:fe:09:69:25:be:2e:
     bf:fd:cc:ab:22:91:c8:db:f2:68:13:5a:57:03:5f:
     b2:ab:f6:ec:9d
ASN1 OID: prime256v1
NIST CURVE: P-256

openssl req -outform $format -config $cadir/openssl-root.cnf -set_serial 
0x$(openssl rand -hex $sn)\
       -inform $format -key private/ca.key.$format -subj "$DN"\
       -new -x509 -days 7300 -sha256 -extensions v3_ca -out 
certs/ca.cert.$format

unable to load Private Key
140492430772088:error:0906D06C:PEM routines:PEM_read_bio:no start 
line:pem_lib.c:707:Expecting: ANY PRIVATE KEY

How do I tell it that the private key is DER?

Bob



From noloader at gmail.com  Mon Aug 21 17:41:30 2017
From: noloader at gmail.com (Jeffrey Walton)
Date: Mon, 21 Aug 2017 13:41:30 -0400
Subject: [openssl-users] Problem with DER private key file into openssl
	ca
In-Reply-To: <0f6c8d5e-2711-0c47-67f2-3d02edd57b5b@htt-consult.com>
References: <0f6c8d5e-2711-0c47-67f2-3d02edd57b5b@htt-consult.com>
Message-ID: <CAH8yC8ntwP6wEq+XFYnY8JAAL425W7TWCPbdQO7bcjaGFunxSA@mail.gmail.com>

> openssl req -outform $format -config $cadir/openssl-root.cnf -set_serial
> 0x$(openssl rand -hex $sn)\
>       -inform $format -key private/ca.key.$format -subj "$DN"\
>       -new -x509 -days 7300 -sha256 -extensions v3_ca -out
> certs/ca.cert.$format
>
> unable to load Private Key
> 140492430772088:error:0906D06C:PEM routines:PEM_read_bio:no start
> line:pem_lib.c:707:Expecting: ANY PRIVATE KEY
>
> How do I tell it that the private key is DER?

-inform is used to specify the encoding. You can find the man pages at
https://www.openssl.org/docs/man1.0.2/apps/. You want the req.html.

Jeff

From rgm at htt-consult.com  Mon Aug 21 19:50:55 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Mon, 21 Aug 2017 15:50:55 -0400
Subject: [openssl-users] Problem with DER private key file into openssl
	ca
In-Reply-To: <CAH8yC8ntwP6wEq+XFYnY8JAAL425W7TWCPbdQO7bcjaGFunxSA@mail.gmail.com>
References: <0f6c8d5e-2711-0c47-67f2-3d02edd57b5b@htt-consult.com>
 <CAH8yC8ntwP6wEq+XFYnY8JAAL425W7TWCPbdQO7bcjaGFunxSA@mail.gmail.com>
Message-ID: <95493c7a-a6db-9a31-c15b-ce8136ef696a@htt-consult.com>



On 08/21/2017 01:41 PM, Jeffrey Walton wrote:
>> openssl req -outform $format -config $cadir/openssl-root.cnf -set_serial
>> 0x$(openssl rand -hex $sn)\
>>        -inform $format -key private/ca.key.$format -subj "$DN"\
>>        -new -x509 -days 7300 -sha256 -extensions v3_ca -out
>> certs/ca.cert.$format
>>
>> unable to load Private Key
>> 140492430772088:error:0906D06C:PEM routines:PEM_read_bio:no start
>> line:pem_lib.c:707:Expecting: ANY PRIVATE KEY
>>
>> How do I tell it that the private key is DER?
> -inform is used to specify the encoding. You can find the man pages at
> https://www.openssl.org/docs/man1.0.2/apps/. You want the req.html.

And the proper argument is:

-keyform

Thanks

This is sooooo much fun.  Sigh.

Bob


From rgm at htt-consult.com  Mon Aug 21 20:37:07 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Mon, 21 Aug 2017 16:37:07 -0400
Subject: [openssl-users] openssl ca can only create PEM certs
Message-ID: <bcd76483-fc8c-389d-3ba1-e19922318f9a@htt-consult.com>

-outform in the following is invalid:

openssl ca -outform $format -config $cadir/openssl-root.cnf -extensions 
v3_intermediate_ca\
       -keyform $format -days 3650 -notext -md sha256 \
       -in $dir/csr/intermediate.csr.$format -out 
$dir/certs/intermediate.cert.$format

where format=der

Looks like can can convert the pem to der with:

openssl x509 -outform der -in certificate.pem -out certificate.der

But, I am going to have to figure out how to do the same sort of process 
using 'openssl x509'.

I think one of the args is -CA, and  then I can use -set_serial and not 
need the serial file...

Bob


From rgm at htt-consult.com  Tue Aug 22 01:02:33 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Mon, 21 Aug 2017 21:02:33 -0400
Subject: [openssl-users] Cant get openssl x509 to work as documented
Message-ID: <a0744d60-28cc-28a4-6866-2b09776bf65a@htt-consult.com>

I had a frustrating day.  I looked at the documentation at:

https://www.openssl.org/docs/man1.0.2/apps/x509.html

My Fedora24 reports that I am at version 1.0.2k

I made the following comand:

openssl x509 -req -days 3650 -extensions v3_intermediate_ca -inform $format\
  -in $dir/csr/intermediate.csr.$format -outform $format -out 
$dir/certs/intermediate.cert.$format\
-CAkeyform $format -CAkey $cadir/private/ca.key.$format -CAform $format\
  -CA $cadir/certs/ca.cert.$format

Where format=der and got that der is an invalid option.  Plus the 'help' 
reported:

Note that -CAkeyform is invalid and that -CAkey can only be PEM.

Even when I used my pem CA key, I still got errors.  -config is not an 
option, where does this command get the config file from? -extensions 
says it looks to the config file for that label!

SHA256 is not listed as a valid hash.

usage: x509 args
  -inform arg     - input format - default PEM (one of DER, NET or PEM)
  -outform arg    - output format - default PEM (one of DER, NET or PEM)
  -keyform arg    - private key format - default PEM
  -CAform arg     - CA format - default PEM
  -CAkeyform arg  - CA key format - default PEM
  -in arg         - input file - default stdin
  -out arg        - output file - default stdout
  -passin arg     - private key password source
  -serial         - print serial number value
  -subject_hash   - print subject hash value
  -subject_hash_old   - print old-style (MD5) subject hash value
  -issuer_hash    - print issuer hash value
  -issuer_hash_old    - print old-style (MD5) issuer hash value
  -hash           - synonym for -subject_hash
  -subject        - print subject DN
  -issuer         - print issuer DN
  -email          - print email address(es)
  -startdate      - notBefore field
  -enddate        - notAfter field
  -purpose        - print out certificate purposes
  -dates          - both Before and After dates
  -modulus        - print the RSA key modulus
  -pubkey         - output the public key
  -fingerprint    - print the certificate fingerprint
  -alias          - output certificate alias
  -noout          - no certificate output
  -ocspid         - print OCSP hash values for the subject name and 
public key
  -ocsp_uri       - print OCSP Responder URL(s)
  -trustout       - output a "trusted" certificate
  -clrtrust       - clear all trusted purposes
  -clrreject      - clear all rejected purposes
  -addtrust arg   - trust certificate for a given purpose
  -addreject arg  - reject certificate for a given purpose
  -setalias arg   - set certificate alias
  -days arg       - How long till expiry of a signed certificate - def 
30 days
  -checkend arg   - check whether the cert expires in the next arg seconds
                    exit 1 if so, 0 if not
  -signkey arg    - self sign cert with arg
  -x509toreq      - output a certification request object
  -req            - input is a certificate request, sign and output.
  -CA arg         - set the CA certificate, must be PEM format.
  -CAkey arg      - set the CA key, must be PEM format
                    missing, it is assumed to be in the CA file.
  -CAcreateserial - create serial number file if it does not exist
  -CAserial arg   - serial file
  -set_serial     - serial number to use
  -text           - print the certificate in text form
  -C              - print out C code forms
  -<dgst>         - digest to use, see openssl dgst -h output for list
  -extfile        - configuration file with X509V3 extensions to add
  -extensions     - section from config file with X509V3 extensions to add
  -clrext         - delete extensions before signing and input certificate
  -nameopt arg    - various certificate name options
  -engine e       - use engine e, possibly a hardware device.
  -certopt arg    - various certificate text options
  -checkhost host - check certificate matches "host"
  -checkemail email - check certificate matches "email"
  -checkip ipaddr - check certificate matches "ipaddr"


So it looks like for now, I cannot make a guide that easily supports DER 
or PEM.  DER really seems to be an issue how to make.

My searching has come up pretty empty.  No instructions out there.

From jb-openssl at wisemo.com  Tue Aug 22 01:54:55 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 22 Aug 2017 03:54:55 +0200
Subject: [openssl-users] Using set_serial to control serial number size
 directly
In-Reply-To: <df050d70-9043-6c9c-cbfa-9e4f3f5c6910@htt-consult.com>
References: <7c82709e-e4d0-5efd-c329-7c7549a1be35@htt-consult.com>
 <BBCFC482-4943-4C4E-8200-7E92FFCA402D@akamai.com>
 <f672c109-6e46-e11f-b969-90af53f847bf@htt-consult.com>
 <3D3718DE-EC45-4271-B22F-064A1195F659@akamai.com>
 <1f63ae4c-08d2-0d8f-8e9a-ba61084d5316@htt-consult.com>
 <533B92D1-D2A1-45E0-8089-078A40BD12C4@akamai.com>
 <df050d70-9043-6c9c-cbfa-9e4f3f5c6910@htt-consult.com>
Message-ID: <34092764-1809-eb5e-b20a-8cb19f243202@wisemo.com>

On 21/08/2017 16:22, Robert Moskowitz wrote:
>
>
> On 08/21/2017 10:03 AM, Salz, Rich wrote:
>> If the root is going to be trusted, make its serial number be one. ?
>> Otherwise use eight bytes of random as the serial number, if you 
>> follow CABF guidelines.
>
> Kind of where my thinking is going.? But once I make it '1', it might 
> as well be 1 byte rand!? :)
>
> Well 1 - 127 random...
>
> But no need to make it 20 octets.? Just leave it at 8. And yes, I can 
> see some jump on the 'save' 7 bytes bandwagon.
Note that while the random bits in the serial number are technically
there to defend against attacks on the issuing CA if that CA uses an
old/outdated algorithm, the real issue is retaining compatibility
with Browsers that blindly assume that certificates are created
according to the contractual requirements applied to public CAs such
as DigiCert.

One of those is 20 bytes max (after DER encoding, thus 159 bits max).

Another is at least 64 fresh random bits in each serial number
generated by the CA.

Another may or may not be 20 bytes min (before DER encoding, thus
153 bits min).

> Also why I have to work out BER to compare that sizing to DER. Trying 
> to do that today. 
BER is never shorter than DER.

However for internal processing in memory-restricted devices, it may be
possible/easy to save space by using a simplified encoding internally,
and then convert to DER on the fly when talking to standard software
(such as Web Browsers) externally.? This will ultimately be a trade off
between code size (to do the conversion) and data size (to store the
certificate).


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 carloscaraccia at gmail.com  Tue Aug 22 11:44:07 2017
From: carloscaraccia at gmail.com (Carlos Caraccia)
Date: Tue, 22 Aug 2017 08:44:07 -0300
Subject: [openssl-users] Can't replicate subcommand openssl smime -sign
	using pkcs7 functions
Message-ID: <9234242A-B2D5-40D6-B074-17DAB810771D@gmail.com>

Hi! I?m a hobbiest developer. I?m trying to execute this command using C functions in objective C. The output using this subcommand and its functions are very different. I?d been reading the open source smime.c file but I don?t understand where is my mistake. Nevertheless I don?t know where I can get a detailed documentation of the flags. Below I paste my code and a stack overflow question I had asked. Thanks for your time.

openssl smime -sign -signer *certificate.cer* -inkey *myKey* -outoutFile.xml.cms -in *infile.xml -outform PEM -nodetach


I do try to do this in Objective-C, but the length of the string which I end up is very different.

SSL_library_init();

OPENSSL_add_all_algorithms_noconf();

OpenSSL_add_all_digests();
//Load the private key
NSString *privateKeyPath = [[NSBundle mainBundle]pathForResource:@"nameOfPrivateKeyFile" ofType:@"?];

BIO* bio = BIO_new_file([privateKeyPath cStringUsingEncoding:NSUTF8StringEncoding], "rb");
if (!bio) {
	NSLog(@"Error %s (%d)",strerror(errno), errno);
}

EVP_PKEY* pkey = NULL;

PEM_read_bio_PrivateKey(bio, &pkey, NULL, NULL);

if (!pkey) {    
	NSLog(@"problem");
}

BIO_free_all(bio);

// Load the certificate

X509* certificate = NULL;
NSString *certificatePath = [[NSBundle mainBundle]pathForResource:@"certificateFilePath" ofType:@"cer"];

bio = BIO_new_file([certificatePath cStringUsingEncoding:NSUTF8StringEncoding], "rb");

certificate = PEM_read_bio_X509_AUX(bio, NULL, NULL, NULL);

BIO_free_all(bio);

//Sign the binary..

PKCS7* pkcs7 = PKCS7_sign(NULL, NULL, NULL, NULL, PKCS7_PARTIAL);

PKCS7_sign_add_signer(pkcs7, certificate, pkey, NULL, PKCS7_PARTIAL);

PKCS7_final(pkcs7, NULL, PKCS7_PARTIAL);

if (!pkcs7) {    
	NSLog(@?Problem in PKCS7");
}

BIO_free_all(bio);

//Load file to sign..
NSString *fileToWritePath = [[NSBundle mainBundle]pathForResource:@"fileToEncrypt" ofType:@"xml"];

bio = BIO_new_file([fileToWritePath cStringUsingEncoding:NSUTF8StringEncoding], "rb");
NSString *fileToSignPath = [[NSBundle mainBundle]pathForResource:@"fileToSign" ofType:@"xml"];

BIO* bioIn = BIO_new_file([secondTicketPath cStringUsingEncoding:NSUTF8StringEncoding], "rb");
if (!bioIn) {
    NSLog(@"Error %s (%d)",strerror(errno), errno);
}

int rv = PEM_write_bio_PKCS7_stream(bio, pkcs7, bioIn, PKCS7_F_PKCS7_FINAL);

if (rv == 0){    
	NSLog(@"Error writting file ");
}

NSString *result = [NSString stringWithContentsOfFile:dalaiPath encoding:NSUTF8StringEncoding error:NULL];


The expected result is this file in printed in text format

-----BEGIN PKCS7-----

MIIG7QYJKoZIhvcNAQcCoIIG3jCCBtoCAQExCzAJBgUrDgMCGgUAMIIBWAYJKoZI
??.
qz5dxSDJ4rYBoio1ZncTIwUnpHAWwe2OTWt9wSEu3d5elPFXQ
mw
==
-----END PKCS7??


but I obtain, the length of the string is completely different (short) I cannot get the -----END PKCS7------ part of the message. Now the first part of the message seems right. But not the last.


-----BEGIN PKCS7-----

MIIF3QYJKoZIhvcNAQcCoIIFzjCCBcoCAQExDzANBglghkgBZQMEAgEFADAPBgkq
??.
aPdcT7Wg5StNrGYsmmRzxaY=


Can anyone please give a clue of what I may be doing wrong?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170822/dda5f7fb/attachment.html>

From carloscaraccia at gmail.com  Tue Aug 22 11:48:11 2017
From: carloscaraccia at gmail.com (Carlos Caraccia)
Date: Tue, 22 Aug 2017 08:48:11 -0300
Subject: [openssl-users] Can't replicate subcommand openssl smime -sign
	using pkcs7 functions
Message-ID: <370742F7-1757-4C52-815F-E40E7D020BE2@gmail.com>

Hi! I?m a hobbiest developer. I?m trying to execute this command using C functions in objective C. The output using this subcommand and its functions are very different. I?d been reading the open source smime.c file but I don?t understand where is my mistake. Nevertheless I don?t know where I can get a detailed documentation of the flags. Below I paste my code and a stack overflow question I had asked. Thanks for your time.

openssl smime -sign -signer *certificate.cer* -inkey *myKey* -outoutFile.xml.cms -in *infile.xml -outform PEM -nodetach


I do try to do this in Objective-C, but the length of the string which I end up is very different.

SSL_library_init();

OPENSSL_add_all_algorithms_noconf();

OpenSSL_add_all_digests();
//Load the private key
NSString *privateKeyPath = [[NSBundle mainBundle]pathForResource:@"nameOfPrivateKeyFile" ofType:@"?];

BIO* bio = BIO_new_file([privateKeyPath cStringUsingEncoding:NSUTF8StringEncoding], "rb");
if (!bio) {
	NSLog(@"Error %s (%d)",strerror(errno), errno);
}

EVP_PKEY* pkey = NULL;

PEM_read_bio_PrivateKey(bio, &pkey, NULL, NULL);

if (!pkey) {    
	NSLog(@"problem");
}

BIO_free_all(bio);

// Load the certificate

X509* certificate = NULL;
NSString *certificatePath = [[NSBundle mainBundle]pathForResource:@"certificateFilePath" ofType:@"cer"];

bio = BIO_new_file([certificatePath cStringUsingEncoding:NSUTF8StringEncoding], "rb");

certificate = PEM_read_bio_X509_AUX(bio, NULL, NULL, NULL);

BIO_free_all(bio);

//Sign the binary..

PKCS7* pkcs7 = PKCS7_sign(NULL, NULL, NULL, NULL, PKCS7_PARTIAL);

PKCS7_sign_add_signer(pkcs7, certificate, pkey, NULL, PKCS7_PARTIAL);

PKCS7_final(pkcs7, NULL, PKCS7_PARTIAL);

if (!pkcs7) {    
	NSLog(@?Problem in PKCS7");
}

BIO_free_all(bio);

//Load file to sign..
NSString *fileToWritePath = [[NSBundle mainBundle]pathForResource:@"fileToEncrypt" ofType:@"xml"];

bio = BIO_new_file([fileToWritePath cStringUsingEncoding:NSUTF8StringEncoding], "rb");
NSString *fileToSignPath = [[NSBundle mainBundle]pathForResource:@"fileToSign" ofType:@"xml"];

BIO* bioIn = BIO_new_file([secondTicketPath cStringUsingEncoding:NSUTF8StringEncoding], "rb");
if (!bioIn) {
    NSLog(@"Error %s (%d)",strerror(errno), errno);
}

int rv = PEM_write_bio_PKCS7_stream(bio, pkcs7, bioIn, PKCS7_F_PKCS7_FINAL);

if (rv == 0){    
	NSLog(@"Error writting file ");
}

NSString *result = [NSString stringWithContentsOfFile:dalaiPath encoding:NSUTF8StringEncoding error:NULL];


The expected result is this file in printed in text format

-----BEGIN PKCS7-----

MIIG7QYJKoZIhvcNAQcCoIIG3jCCBtoCAQExCzAJBgUrDgMCGgUAMIIBWAYJKoZI
??.
qz5dxSDJ4rYBoio1ZncTIwUnpHAWwe2OTWt9wSEu3d5elPFXQ
mw
==
-----END PKCS7??


but I obtain, the length of the string is completely different (short) I cannot get the -----END PKCS7------ part of the message. Now the first part of the message seems right. But not the last.


-----BEGIN PKCS7-----

MIIF3QYJKoZIhvcNAQcCoIIFzjCCBcoCAQExDzANBglghkgBZQMEAgEFADAPBgkq
??.
aPdcT7Wg5StNrGYsmmRzxaY=


Can anyone please give a clue of what I may be doing wrong?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170822/5c2b0f6d/attachment-0001.html>

From openssl-users at dukhovni.org  Tue Aug 22 14:19:07 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 22 Aug 2017 10:19:07 -0400
Subject: [openssl-users] Cant get openssl x509 to work as documented
In-Reply-To: <a0744d60-28cc-28a4-6866-2b09776bf65a@htt-consult.com>
References: <a0744d60-28cc-28a4-6866-2b09776bf65a@htt-consult.com>
Message-ID: <AD4F396D-957C-4A0F-92E3-E89A0AD9CB11@dukhovni.org>


> On Aug 21, 2017, at 9:02 PM, Robert Moskowitz <rgm at htt-consult.com> wrote:
> 
> openssl x509 -req -days 3650 -extensions v3_intermediate_ca -inform $format\
> -in $dir/csr/intermediate.csr.$format -outform $format -out $dir/certs/intermediate.cert.$format\
> -CAkeyform $format -CAkey $cadir/private/ca.key.$format -CAform $format\
> -CA $cadir/certs/ca.cert.$format
> 
> Where format=der and got that der is an invalid option.  Plus the 'help' reported:

It is trivial to convert a PEM certificate to DER, just pipe the output through
"openssl x509 -outform DER".  Mind you this is often the wrong thing to do, because
the DER form of an X.509 certificate holds *exactly* one certificate, while users
often need a certificate *chain*, that also includes the requisite intermediate
certificates.  With PEM, the certificate file can just all the certificates back
to back.  With DER only the EE certificate appears in the file.

While PKCS#7 can hold a bunch of certificates in DER form, it is not typically
used a certificate chain file by any applications, and IIRC there's no indication
of which of the certificates is the end-entity certificate in a PKCS#7 file.

The only widely used DER form for chains is PKCS#12 which holds the private
key as well as the certificate chain, and has a mandatory passphrase.  I use
PKCS#12 (instead of JKS) for Java TLS server applications, set the file
access mode to 0600, and since there's no point in prompting batch applications
for a passphrase, set the passphrase to "umask 077", since that's the only
effective protection for the private key.

It is not clear that PKCS#12 is compellingly more compact than PEM, the only
reason I use it is that Java supports JKS and PKCS#12, but not PEM.

> Note that -CAkeyform is invalid and that -CAkey can only be PEM.

As explained before, the API for DER PrivateKey objects does not
support passwords, and the CLI does not have a way to indicate
the use PKCS8PrivateKey instead.  The PrivateKey interface can
read only unencrypted PKCS#8 in PEM form.

> Even when I used my pem CA key, I still got errors.  -config is
> not an option, where does this command get the config file from?
> -extensions says it looks to the config file for that label!

The config file for "x509 -req" is specified with "-extfile ...".

> 
> SHA256 is not listed as a valid hash.

Many more X.509 digest algorithms are supported in this context
than (sadly) are listed in the manpage.  Perhaps there should
be a command that lists all supported x.509 hash algorithms,
and the documentation for commands that take any of the
supported algorithms can just refer the reader to the output
of that command.

-- 
	Viktor.


From rsalz at akamai.com  Tue Aug 22 14:53:55 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 22 Aug 2017 14:53:55 +0000
Subject: [openssl-users] Cant get openssl x509 to work as documented
In-Reply-To: <AD4F396D-957C-4A0F-92E3-E89A0AD9CB11@dukhovni.org>
References: <a0744d60-28cc-28a4-6866-2b09776bf65a@htt-consult.com>
 <AD4F396D-957C-4A0F-92E3-E89A0AD9CB11@dukhovni.org>
Message-ID: <3CEBF752-8E58-45B8-82ED-4FD713AC99B8@akamai.com>


>  > SHA256 is not listed as a valid hash.
    
>    Many more X.509 digest algorithms are supported in this context
>    than (sadly) are listed in the manpage.  Perhaps there should
>   be a command that lists all supported x.509 hash algorithms,
>    and the documentation for commands that take any of the
 >   supported algorithms can just refer the reader to the output
 >   of that command.
    
Fixed in 1.1.0 and later; ?list?digest-algorithms? command.  And the manpages should say things like ?any supported digest? and such.


From openssl-users at dukhovni.org  Tue Aug 22 15:54:46 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 22 Aug 2017 11:54:46 -0400
Subject: [openssl-users] Cant get openssl x509 to work as documented
In-Reply-To: <3CEBF752-8E58-45B8-82ED-4FD713AC99B8@akamai.com>
References: <a0744d60-28cc-28a4-6866-2b09776bf65a@htt-consult.com>
 <AD4F396D-957C-4A0F-92E3-E89A0AD9CB11@dukhovni.org>
 <3CEBF752-8E58-45B8-82ED-4FD713AC99B8@akamai.com>
Message-ID: <E6E05C82-AE58-472B-B946-900BEE94948E@dukhovni.org>


> On Aug 22, 2017, at 10:53 AM, Salz, Rich via openssl-users <openssl-users at openssl.org> wrote:
> 
> Fixed in 1.1.0 and later; ?list?digest-algorithms? command.

For the record: "openssl list -digest-algorithms", the "ndash" above
is a typo of some sort...

It is not clear to me how to get a list of digest algorithms that have
ASN.1 OIDs for certificate signing.  Are all the digests listed with
this command suitable for such use?

The "NOTES" section of EVP_SignInit(3) says:

   https://www.openssl.org/docs/manmaster/man3/EVP_SignInit.html

       Due to the link between message digests and public key algorithms
       the correct digest algorithm must be used with the correct public
       key type. A list of algorithms and associated public key algorithms
       appears in EVP_DigestInit(3).

while for EVP_DigestSignInit(3) we have:

   https://www.openssl.org/docs/manmaster/man3/EVP_DigestSignInit.html

       In previous versions of OpenSSL there was a link between message
       digest types and public key algorithms. This meant that "clone"
       digests such as EVP_dss1() needed to be used to sign using SHA1
       and DSA. This is no longer necessary and the use of clone digest
       is now discouraged.

and finally in EVP_DigestInit(3):

    https://www.openssl.org/docs/manmaster/man3/EVP_DigestInit.html

       EVP_MD_pkey_type() returns the NID of the public key signing algorithm
       associated with this digest. For example EVP_sha1() is associated with
       RSA so this will return NID_sha1WithRSAEncryption. Since digests and
       signature algorithms are no longer linked this function is only
       retained for compatibility reasons.

       EVP_md2(), EVP_md5(), EVP_sha1(), EVP_sha224(), EVP_sha256(),
       EVP_sha384(), EVP_sha512(), EVP_mdc2(), EVP_ripemd160(),
       EVP_blake2b_512(), and EVP_blake2s_256() return EVP_MD structures for
       the MD2, MD5, SHA1, SHA224, SHA256, SHA384, SHA512, MDC2, RIPEMD160,
       BLAKE2b-512, and BLAKE2s-256 digest algorithms respectively.

So it is not particularly clear which combinations public key and digest
algorithms are supported for signing.

In crypto/ec/ec_pmeth.c we have:

    case EVP_PKEY_CTRL_MD:
        if (EVP_MD_type((const EVP_MD *)p2) != NID_sha1 &&
            EVP_MD_type((const EVP_MD *)p2) != NID_ecdsa_with_SHA1 &&
            EVP_MD_type((const EVP_MD *)p2) != NID_sha224 &&
            EVP_MD_type((const EVP_MD *)p2) != NID_sha256 &&
            EVP_MD_type((const EVP_MD *)p2) != NID_sha384 &&
            EVP_MD_type((const EVP_MD *)p2) != NID_sha512) {
            ECerr(EC_F_PKEY_EC_CTRL, EC_R_INVALID_DIGEST_TYPE);
            return 0;
        }

so with ECDSA we only support SHA1 and the SHA2 family of digests.
Similar code for DSA in crypto/dsa/dsa_pmeth.c

    case EVP_PKEY_CTRL_MD:
        if (EVP_MD_type((const EVP_MD *)p2) != NID_sha1 &&
            EVP_MD_type((const EVP_MD *)p2) != NID_dsa &&
            EVP_MD_type((const EVP_MD *)p2) != NID_dsaWithSHA &&
            EVP_MD_type((const EVP_MD *)p2) != NID_sha224 &&
            EVP_MD_type((const EVP_MD *)p2) != NID_sha256 &&
            EVP_MD_type((const EVP_MD *)p2) != NID_sha384 &&
            EVP_MD_type((const EVP_MD *)p2) != NID_sha512) {
            DSAerr(DSA_F_PKEY_DSA_CTRL, DSA_R_INVALID_DIGEST_TYPE);
            return 0;
        }

In crypto/rsa/rsa_pmeth.c we have:

        /* List of all supported RSA digests */
        case NID_sha1:
        case NID_sha224:
        case NID_sha256:
        case NID_sha384:
        case NID_sha512:
        case NID_md5:
        case NID_md5_sha1:
        case NID_md2:
        case NID_md4:
        case NID_mdc2:
        case NID_ripemd160:
            return 1;

So for RSA we have SHA1/SHA2/MD5/MD2/MD4/MDC2/RIPEMD160 (with
special handling of PSS I'm not going into).

> And the manpages should say things like ?any supported digest? and such.

The picture is a lot more complex I'm sorry to say...

-- 
	Viktor.


From carloscaraccia at gmail.com  Tue Aug 22 15:57:00 2017
From: carloscaraccia at gmail.com (Carlos Caraccia)
Date: Tue, 22 Aug 2017 12:57:00 -0300
Subject: [openssl-users] Not able to replicate smile -sign using functions
Message-ID: <5738B9FE-AF21-4269-86F4-9F6C7F02F17C@gmail.com>

Hi! I?m a hobbiest developer. I?m trying to execute this command using C functions in objective C. The output using this subcommand and its functions are very different. I?d been reading the open source smime.c file but I don?t understand where is my mistake. Nevertheless I don?t know where I can get a detailed documentation of the flags. Below I paste my code and a stack overflow question I had asked. Thanks for your time.

openssl smime -sign -signer *certificate.cer* -inkey *myKey* -outoutFile.xml.cms -in *infile.xml -outform PEM -nodetach


I do try to do this in Objective-C, but the length of the string which I end up is very different.

SSL_library_init();

OPENSSL_add_all_algorithms_noconf();

OpenSSL_add_all_digests();
//Load the private key
NSString *privateKeyPath = [[NSBundle mainBundle]pathForResource:@"nameOfPrivateKeyFile" ofType:@"?];

BIO* bio = BIO_new_file([privateKeyPath cStringUsingEncoding:NSUTF8StringEncoding], "rb");
if (!bio) {
	NSLog(@"Error %s (%d)",strerror(errno), errno);
}

EVP_PKEY* pkey = NULL;

PEM_read_bio_PrivateKey(bio, &pkey, NULL, NULL);

if (!pkey) {    
	NSLog(@"problem");
}

BIO_free_all(bio);

// Load the certificate

X509* certificate = NULL;
NSString *certificatePath = [[NSBundle mainBundle]pathForResource:@"certificateFilePath" ofType:@"cer"];

bio = BIO_new_file([certificatePath cStringUsingEncoding:NSUTF8StringEncoding], "rb");

certificate = PEM_read_bio_X509_AUX(bio, NULL, NULL, NULL);

BIO_free_all(bio);

//Sign the binary..

PKCS7* pkcs7 = PKCS7_sign(NULL, NULL, NULL, NULL, PKCS7_PARTIAL);

PKCS7_sign_add_signer(pkcs7, certificate, pkey, NULL, PKCS7_PARTIAL);

PKCS7_final(pkcs7, NULL, PKCS7_PARTIAL);

if (!pkcs7) {    
	NSLog(@?Problem in PKCS7");
}

BIO_free_all(bio);

//Load file to sign..
NSString *fileToWritePath = [[NSBundle mainBundle]pathForResource:@"fileToEncrypt" ofType:@"xml"];

bio = BIO_new_file([fileToWritePath cStringUsingEncoding:NSUTF8StringEncoding], "rb");
NSString *fileToSignPath = [[NSBundle mainBundle]pathForResource:@"fileToSign" ofType:@"xml"];

BIO* bioIn = BIO_new_file([secondTicketPath cStringUsingEncoding:NSUTF8StringEncoding], "rb");
if (!bioIn) {
    NSLog(@"Error %s (%d)",strerror(errno), errno);
}

int rv = PEM_write_bio_PKCS7_stream(bio, pkcs7, bioIn, PKCS7_F_PKCS7_FINAL);

if (rv == 0){    
	NSLog(@"Error writting file ");
}

NSString *result = [NSString stringWithContentsOfFile:dalaiPath encoding:NSUTF8StringEncoding error:NULL];


The expected result is this file in printed in text format

-----BEGIN PKCS7-----

MIIG7QYJKoZIhvcNAQcCoIIG3jCCBtoCAQExCzAJBgUrDgMCGgUAMIIBWAYJKoZI
??.
qz5dxSDJ4rYBoio1ZncTIwUnpHAWwe2OTWt9wSEu3d5elPFXQ
mw
==
-----END PKCS7??


but I obtain, the length of the string is completely different (short) I cannot get the -----END PKCS7------ part of the message. Now the first part of the message seems right. But not the last.


-----BEGIN PKCS7-----

MIIF3QYJKoZIhvcNAQcCoIIFzjCCBcoCAQExDzANBglghkgBZQMEAgEFADAPBgkq
??.
aPdcT7Wg5StNrGYsmmRzxaY=


Can anyone please give a clue of what I may be doing wrong?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170822/4db36100/attachment-0001.html>

From rgm at htt-consult.com  Tue Aug 22 15:57:41 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Tue, 22 Aug 2017 11:57:41 -0400
Subject: [openssl-users] Cant get openssl x509 to work as documented
In-Reply-To: <3CEBF752-8E58-45B8-82ED-4FD713AC99B8@akamai.com>
References: <a0744d60-28cc-28a4-6866-2b09776bf65a@htt-consult.com>
 <AD4F396D-957C-4A0F-92E3-E89A0AD9CB11@dukhovni.org>
 <3CEBF752-8E58-45B8-82ED-4FD713AC99B8@akamai.com>
Message-ID: <569d341f-080d-7034-674a-d8b8b0b3fba5@htt-consult.com>



On 08/22/2017 10:53 AM, Salz, Rich via openssl-users wrote:
>>   > SHA256 is not listed as a valid hash.
>      
>>     Many more X.509 digest algorithms are supported in this context
>>     than (sadly) are listed in the manpage.  Perhaps there should
>>    be a command that lists all supported x.509 hash algorithms,
>>     and the documentation for commands that take any of the
>   >   supported algorithms can just refer the reader to the output
>   >   of that command.
>      
> Fixed in 1.1.0 and later; ?list?digest-algorithms? command.  And the manpages should say things like ?any supported digest? and such.
>
I was going by:

https://www.openssl.org/docs/man1.0.2/apps/x509.html

Which has a very short list.  And not SHA256.

Bob


From rsalz at akamai.com  Tue Aug 22 15:58:23 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 22 Aug 2017 15:58:23 +0000
Subject: [openssl-users] Cant get openssl x509 to work as documented
In-Reply-To: <E6E05C82-AE58-472B-B946-900BEE94948E@dukhovni.org>
References: <a0744d60-28cc-28a4-6866-2b09776bf65a@htt-consult.com>
 <AD4F396D-957C-4A0F-92E3-E89A0AD9CB11@dukhovni.org>
 <3CEBF752-8E58-45B8-82ED-4FD713AC99B8@akamai.com>
 <E6E05C82-AE58-472B-B946-900BEE94948E@dukhovni.org>
Message-ID: <CD482A59-9E2D-41C3-9621-8772CADF93D0@akamai.com>


    > And the manpages should say things like ?any supported digest? and such.
    
    The picture is a lot more complex I'm sorry to say...

You?re right.  Thanks.


From sudarshan.t.raghavan at gmail.com  Tue Aug 22 17:37:29 2017
From: sudarshan.t.raghavan at gmail.com (Sudarshan Raghavan)
Date: Tue, 22 Aug 2017 10:37:29 -0700
Subject: [openssl-users] Client authentication certificate verification
Message-ID: <CAGxgQ09SmHEKW=GhzYAs0_+tjuEX80dA-tFO7cmCeiP_JDe+CQ@mail.gmail.com>

This is the CA - Leaf hierarchy I am testing with

Root CA > Intermediate CA 1 > Intermediate CA 2 > Leaf

Trusted certificates configured: Root CA and Intermediate CA 2

Client authenticates itself with this chain: Leaf > Intermediate CA 2 >
Intermediate CA 1

I am using openssl 1.1.0f. This client authentication attempt is flagged as
failed by OpenSSL. When I enable the X509_V_FLAG_PARTIAL_CHAIN flag, it
passes. I was trying to understand why the partial chain flag is needed
when the verification chain from Leaf to Root CA can be constructed using
both the chain sent by the client and the certificates configured in
trusted store. I looked at the code in build_chain function inside
crypto/x509/x509_vfy.c. This is what I understand. If the issuer of Leaf
certificate (Intermediate CA 2) is found in trusted store, the code will no
longer look in the untrusted chain sent by the client. The code expects the
chain to Root CA can be constructed from the trusted store itself. Given
Intermediate CA 1 is not in the trusted store, it fails to construct the
verification chain to Root CA and flags a failure. Did I understand this
right? I assume in this scenario, enabling the partial chain flag is the
way to go.

Regards,
Sudarshan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170822/71ddeeac/attachment.html>

From sudarshan.t.raghavan at gmail.com  Tue Aug 22 17:38:57 2017
From: sudarshan.t.raghavan at gmail.com (Sudarshan Raghavan)
Date: Tue, 22 Aug 2017 10:38:57 -0700
Subject: [openssl-users] Client authentication certificate verification
In-Reply-To: <CAGxgQ09SmHEKW=GhzYAs0_+tjuEX80dA-tFO7cmCeiP_JDe+CQ@mail.gmail.com>
References: <CAGxgQ09SmHEKW=GhzYAs0_+tjuEX80dA-tFO7cmCeiP_JDe+CQ@mail.gmail.com>
Message-ID: <CAGxgQ086kUn+EGxfScbA=h3cea=WG1XvYacRiS6S=hWYhSNjbQ@mail.gmail.com>

I understand that the trusted store must include Intermediate CA 1 or
remove Intermediate CA 2 and just have the Root CA in it. I was trying
things out to understand how client authentication works.

Regards,
Sudarshan

On Tue, Aug 22, 2017 at 10:37 AM, Sudarshan Raghavan <
sudarshan.t.raghavan at gmail.com> wrote:

> This is the CA - Leaf hierarchy I am testing with
>
> Root CA > Intermediate CA 1 > Intermediate CA 2 > Leaf
>
> Trusted certificates configured: Root CA and Intermediate CA 2
>
> Client authenticates itself with this chain: Leaf > Intermediate CA 2 >
> Intermediate CA 1
>
> I am using openssl 1.1.0f. This client authentication attempt is flagged
> as failed by OpenSSL. When I enable the X509_V_FLAG_PARTIAL_CHAIN flag, it
> passes. I was trying to understand why the partial chain flag is needed
> when the verification chain from Leaf to Root CA can be constructed using
> both the chain sent by the client and the certificates configured in
> trusted store. I looked at the code in build_chain function inside
> crypto/x509/x509_vfy.c. This is what I understand. If the issuer of Leaf
> certificate (Intermediate CA 2) is found in trusted store, the code will no
> longer look in the untrusted chain sent by the client. The code expects the
> chain to Root CA can be constructed from the trusted store itself. Given
> Intermediate CA 1 is not in the trusted store, it fails to construct the
> verification chain to Root CA and flags a failure. Did I understand this
> right? I assume in this scenario, enabling the partial chain flag is the
> way to go.
>
> Regards,
> Sudarshan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170822/fb14048a/attachment.html>

From rgm at htt-consult.com  Tue Aug 22 20:26:57 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Tue, 22 Aug 2017 16:26:57 -0400
Subject: [openssl-users] Cant get openssl x509 to work as documented
In-Reply-To: <a0744d60-28cc-28a4-6866-2b09776bf65a@htt-consult.com>
References: <a0744d60-28cc-28a4-6866-2b09776bf65a@htt-consult.com>
Message-ID: <b81c814b-73b3-5b38-1d66-44ec150dc931@htt-consult.com>

Want to continue this thread but with new information.  I built a 
Fedora-arm 26 system (on a Cubieboard2) and it has openssl version 1.1.0f

I built my DER root cert (and private key) no problem.

I built my DER Intermediate cert private key and CSR no problem.

For the following command:

sn=8
format=der
dir=/root/ca3
cadir=/root/ca3

openssl x509 -req -days 3650 -extfile $cadir/openssl-root.cnf 
-extensions v3_intermediate_ca\
  -sha256 -set_serial 0x$(openssl rand -hex $sn)\
  -inform $format -in $dir/csr/intermediate.csr.$format\
  -outform $format -out $dir/certs/intermediate.cert.$format\
  -CAkeyform $format -CAkey $cadir/private/ca.key.$format\
  -CAform $format -CA $cadir/certs/ca.cert.$format

I built this reading:

https://www.openssl.org/docs/man1.1.0/apps/x509.html

This generates:

3069592528:error:0906D06C:PEM routines:PEM_read_bio:no start 
line:crypto/pem/pem_lib.c:691:Expecting: CERTIFICATE REQUEST

The man page above has CAkeyform and CAform in the summary, but no 
details below.  I am ASSUMEing DER is now supported.

for -sha256, I finally figured out that -[digest] is how the the man 
presents which hash to use.

Why does this command use -extfile and not -config?  Is it because ALL 
that is taken from config is -extensions?  Confusing to the casual user.

But why the error?

And yes, I know I can convert a PEM cert to DER, but I would also have 
to convert the private key, and maintain duo structures in places.  
Would RATHER have a parallel setup.  Of course there is the challenge of 
the cert chain that Viktor earlier explained.  OCSP? :)

Bob


From rgm at htt-consult.com  Tue Aug 22 21:23:09 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Tue, 22 Aug 2017 17:23:09 -0400
Subject: [openssl-users] Cant get openssl x509 to work as documented
In-Reply-To: <AD4F396D-957C-4A0F-92E3-E89A0AD9CB11@dukhovni.org>
References: <a0744d60-28cc-28a4-6866-2b09776bf65a@htt-consult.com>
 <AD4F396D-957C-4A0F-92E3-E89A0AD9CB11@dukhovni.org>
Message-ID: <d5034454-c6be-9981-9fd5-f2103b073b30@htt-consult.com>

Viktor,

Thank you for this in-depth explanation.

I have talked to a number of large potential customers where certs are 
important but they are highly constrained.  This includes the auto 
sector with ECUs that are really pressed to the wall (like on the engine 
block and already running at 130C!)

A PEM ECDSA private key file (not passworded) is 241 bytes.  The DER 
equivalent is 121 bytes.  Even if we follow the ANIMA model that allows 
both the iDevID and lDevID certs to use the same key (shudder), a 120 
bytes of secure store savings is a big issue. Otherwise we double this 
storage cost.   Ed25519 should be smaller, as the public key is 32 
bytes, not the 64 of P256.  But I don't like that they used SHA512 for 
Ed25519 rather than SPAKE128 (they used SPAKE256 for Ed488).

And then there is the cert store in regular storage, plus whatever 
support (like chains) needed.  As I think more of this, 802.1AR-2009 
only expects to device to have its iDevID cert, not also the cert chain 
to the root.  It never has to verify its cert, the manufacturer stuffed 
it in at built time into read only memory with an expiry date of 
forever.  It is the lDevID part that ANIMA is building into a complex 
bootstrap process that I don't totally agree with.  And NETCONF is doing 
their flavor of it.  Sigh.

The IETF CORE wg is looking at this too.

I have to munch on this problem a lot more.

Bob

On 08/22/2017 10:19 AM, Viktor Dukhovni wrote:
>> On Aug 21, 2017, at 9:02 PM, Robert Moskowitz <rgm at htt-consult.com> wrote:
>>
>> openssl x509 -req -days 3650 -extensions v3_intermediate_ca -inform $format\
>> -in $dir/csr/intermediate.csr.$format -outform $format -out $dir/certs/intermediate.cert.$format\
>> -CAkeyform $format -CAkey $cadir/private/ca.key.$format -CAform $format\
>> -CA $cadir/certs/ca.cert.$format
>>
>> Where format=der and got that der is an invalid option.  Plus the 'help' reported:
> It is trivial to convert a PEM certificate to DER, just pipe the output through
> "openssl x509 -outform DER".  Mind you this is often the wrong thing to do, because
> the DER form of an X.509 certificate holds *exactly* one certificate, while users
> often need a certificate *chain*, that also includes the requisite intermediate
> certificates.  With PEM, the certificate file can just all the certificates back
> to back.  With DER only the EE certificate appears in the file.
>
> While PKCS#7 can hold a bunch of certificates in DER form, it is not typically
> used a certificate chain file by any applications, and IIRC there's no indication
> of which of the certificates is the end-entity certificate in a PKCS#7 file.
>
> The only widely used DER form for chains is PKCS#12 which holds the private
> key as well as the certificate chain, and has a mandatory passphrase.  I use
> PKCS#12 (instead of JKS) for Java TLS server applications, set the file
> access mode to 0600, and since there's no point in prompting batch applications
> for a passphrase, set the passphrase to "umask 077", since that's the only
> effective protection for the private key.
>
> It is not clear that PKCS#12 is compellingly more compact than PEM, the only
> reason I use it is that Java supports JKS and PKCS#12, but not PEM.
>
>> Note that -CAkeyform is invalid and that -CAkey can only be PEM.
> As explained before, the API for DER PrivateKey objects does not
> support passwords, and the CLI does not have a way to indicate
> the use PKCS8PrivateKey instead.  The PrivateKey interface can
> read only unencrypted PKCS#8 in PEM form.
>
>> Even when I used my pem CA key, I still got errors.  -config is
>> not an option, where does this command get the config file from?
>> -extensions says it looks to the config file for that label!
> The config file for "x509 -req" is specified with "-extfile ...".
>
>> SHA256 is not listed as a valid hash.
> Many more X.509 digest algorithms are supported in this context
> than (sadly) are listed in the manpage.  Perhaps there should
> be a command that lists all supported x.509 hash algorithms,
> and the documentation for commands that take any of the
> supported algorithms can just refer the reader to the output
> of that command.
>


From Brett.R.Nicholas.TH at dartmouth.edu  Wed Aug 23 01:44:38 2017
From: Brett.R.Nicholas.TH at dartmouth.edu (Brett R. Nicholas)
Date: Wed, 23 Aug 2017 01:44:38 +0000
Subject: [openssl-users] confusion with rsa_meth_st in a custom RSA engine
Message-ID: <BN3PR03MB1462DEDC32973000CDAB1622E0850@BN3PR03MB1462.namprd03.prod.outlook.com>

I am trying to develop a engine for a custom RSA hardware accelerator, and have a few questions about the RSA_METHOD stucture implementation.


Some context: for encryption, my accelerator takes as inputs the base, public exponent, and modulus, and returns the resulting ciphertext. For decryption, it takes as inputs the base, and modulus. It does not need a private key, as this is stored in hardware, and can only be configured through an out-of-band channel. I already have a kernel module that exposes an API to userspace programs to use the accelerator. Now I just need to integrate it into openSSL.


I've already created a similar engine for AES and SHA256, however I'm struggling with RSA. Ideally, I'd like to not have to worry about anything other than just performing the modular exponentiation on a pre-padded and prepared chunk of data. For SHA and AES, this is straightforward: all that was taken care of by the EVP interface, so all I needed to worry about was getting the data two and from my accelerators. But it doesn't appear to be as simple for RSA (pls correct me if I'm wrong).


I'm confused as to which RSA_METHOD function pointers that my engine needs to implement.  I show the structure below for reference:

struct rsa_meth_st {
    char *name;
    int (*rsa_pub_enc) (int flen, const unsigned char *from,
                        unsigned char *to, RSA *rsa, int padding);
    int (*rsa_pub_dec) (int flen, const unsigned char *from,
                        unsigned char *to, RSA *rsa, int padding);
    int (*rsa_priv_enc) (int flen, const unsigned char *from,
                         unsigned char *to, RSA *rsa, int padding);
    int (*rsa_priv_dec) (int flen, const unsigned char *from,
                         unsigned char *to, RSA *rsa, int padding);

    int (*rsa_mod_exp) (BIGNUM *r0, const BIGNUM *I, RSA *rsa, BN_CTX *ctx);

    int (*bn_mod_exp) (BIGNUM *r, const BIGNUM *a, const BIGNUM *p,
                       const BIGNUM *m, BN_CTX *ctx, BN_MONT_CTX *m_ctx);
    /* ....stuff.... */
    int flags;
    /* .... stuff ... */
};  // TYPEDEF'ED TO RSA_METHOD in include/ossl_typ.h


So, three questions:


  1.  Is it possible for the standard OpenSSL RSA implementation to use my engine's "modular exponentiation" function, without having to rewrite the RSA_[public|private]_[encrypt|decrypt] family of functions from /include/openssl/rsa.h?
  2.  If so, does it suffice to only implement the rsa_mod_exp function? Or must I implement both public_enc/dec and private_enc/dec functions as well? I ask, because the source code for the old Intel RSAX engine (https://gist.github.com/bigbrett/91903f773f9d150b7329c7d462cd220a) does this, but I can't figure out how and when in the "RSA flow" the engine's function gets invoked.
  3.  In  /include/openssl/rsa.h, I saw the following macro for the RSA_METHOD flag field (line 55):

/*
 * This flag means the private key operations will be handled by rsa_mod_exp
 * and that they do not depend on the private key components being present:
 * for example a key stored in external hardware. Without this flag
 * bn_mod_exp gets called when private key components are absent.
 */
# define RSA_FLAG_EXT_PKEY               0x0020


Does this mean that if I use this flag in the "flags" field of RSA_METHOD, that I DO NOT need to implement rsa_pub_enc/dec and friends? I guess I'm just confused as to at what point in the RSA encryption/decryption process my engine should be invoked at.


FWIW I'm planning on releasing a comprehensive engine tutorial and some documentation for all this stuff once I finish (will already be written up in my thesis), so I want to make sure I get these details ironed out!


Any words of wisdom would be greatly appreciated.


Best,

Brett

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170823/17064b4b/attachment.html>

From jb-openssl at wisemo.com  Wed Aug 23 19:52:29 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 23 Aug 2017 21:52:29 +0200
Subject: [openssl-users] Cant get openssl x509 to work as documented
In-Reply-To: <b81c814b-73b3-5b38-1d66-44ec150dc931@htt-consult.com>
References: <a0744d60-28cc-28a4-6866-2b09776bf65a@htt-consult.com>
 <b81c814b-73b3-5b38-1d66-44ec150dc931@htt-consult.com>
Message-ID: <a2bce8f9-2396-8d38-2305-1a07f302e3f2@wisemo.com>

On 22/08/2017 22:26, Robert Moskowitz wrote:
> Want to continue this thread but with new information.? I built a 
> Fedora-arm 26 system (on a Cubieboard2) and it has openssl version 1.1.0f
>
> I built my DER root cert (and private key) no problem.
>
> I built my DER Intermediate cert private key and CSR no problem.
>
> For the following command:
>
> sn=8
> format=der
> dir=/root/ca3
> cadir=/root/ca3
>
> openssl x509 -req -days 3650 -extfile $cadir/openssl-root.cnf 
> -extensions v3_intermediate_ca\
> ?-sha256 -set_serial 0x$(openssl rand -hex $sn)\
> ?-inform $format -in $dir/csr/intermediate.csr.$format\
> ?-outform $format -out $dir/certs/intermediate.cert.$format\
> ?-CAkeyform $format -CAkey $cadir/private/ca.key.$format\
> ?-CAform $format -CA $cadir/certs/ca.cert.$format
>
> I built this reading:
>
> https://www.openssl.org/docs/man1.1.0/apps/x509.html
>
> This generates:
>
> 3069592528:error:0906D06C:PEM routines:PEM_read_bio:no start 
> line:crypto/pem/pem_lib.c:691:Expecting: CERTIFICATE REQUEST
>
> The man page above has CAkeyform and CAform in the summary, but no 
> details below.? I am ASSUMEing DER is now supported.
>
> for -sha256, I finally figured out that -[digest] is how the the man 
> presents which hash to use.
>
> Why does this command use -extfile and not -config?? Is it because ALL 
> that is taken from config is -extensions?? Confusing to the casual user.
>
> But why the error?
>
> And yes, I know I can convert a PEM cert to DER, but I would also have 
> to convert the private key, and maintain duo structures in places.? 
> Would RATHER have a parallel setup.? Of course there is the challenge 
> of the cert chain that Viktor earlier explained. OCSP? :)
>
>
I don't think you have to pass all the various formats as PEM just
because you pass one of them as such.? After all, there are separate
-XXXform style options for most of them.

For example, you could store the CA private key in the encryption-
supporting PEM format on the plentyful memory of the SD card, while
using the more compact DER format for certificates and CSRs stored
on embedded controllers (ECUs, dashboard displays etc.).

Where OpenSSL bugs prevent use of DER for a file, it can be converted
on the fly, storing the converted file in RAM (using tmpfs or similar).


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 beldmit at gmail.com  Wed Aug 23 19:57:15 2017
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Wed, 23 Aug 2017 22:57:15 +0300
Subject: [openssl-users] ERR_add_error_data
Message-ID: <CADqLbzJJirtOcA_QWQ87Wxz-GCmv4mGuiJXVsDVY-3yqVGaAyg@mail.gmail.com>

Hello,

What happens if I call the ERR_add_error_data twice? Will it add the
arguments or replace them?

Thank you!

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170823/b80c3c0d/attachment.html>

From rgm at htt-consult.com  Wed Aug 23 20:54:11 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Wed, 23 Aug 2017 16:54:11 -0400
Subject: [openssl-users] Cant get openssl x509 to work as documented
In-Reply-To: <a2bce8f9-2396-8d38-2305-1a07f302e3f2@wisemo.com>
References: <a0744d60-28cc-28a4-6866-2b09776bf65a@htt-consult.com>
 <b81c814b-73b3-5b38-1d66-44ec150dc931@htt-consult.com>
 <a2bce8f9-2396-8d38-2305-1a07f302e3f2@wisemo.com>
Message-ID: <291f5034-4709-c646-61de-c4f8b0279887@htt-consult.com>



On 08/23/2017 03:52 PM, Jakob Bohm wrote:
> On 22/08/2017 22:26, Robert Moskowitz wrote:
>> Want to continue this thread but with new information.  I built a 
>> Fedora-arm 26 system (on a Cubieboard2) and it has openssl version 
>> 1.1.0f
>>
>> I built my DER root cert (and private key) no problem.
>>
>> I built my DER Intermediate cert private key and CSR no problem.
>>
>> For the following command:
>>
>> sn=8
>> format=der
>> dir=/root/ca3
>> cadir=/root/ca3
>>
>> openssl x509 -req -days 3650 -extfile $cadir/openssl-root.cnf 
>> -extensions v3_intermediate_ca\
>>  -sha256 -set_serial 0x$(openssl rand -hex $sn)\
>>  -inform $format -in $dir/csr/intermediate.csr.$format\
>>  -outform $format -out $dir/certs/intermediate.cert.$format\
>>  -CAkeyform $format -CAkey $cadir/private/ca.key.$format\
>>  -CAform $format -CA $cadir/certs/ca.cert.$format
>>
>> I built this reading:
>>
>> https://www.openssl.org/docs/man1.1.0/apps/x509.html
>>
>> This generates:
>>
>> 3069592528:error:0906D06C:PEM routines:PEM_read_bio:no start 
>> line:crypto/pem/pem_lib.c:691:Expecting: CERTIFICATE REQUEST
>>
>> The man page above has CAkeyform and CAform in the summary, but no 
>> details below.  I am ASSUMEing DER is now supported.
>>
>> for -sha256, I finally figured out that -[digest] is how the the man 
>> presents which hash to use.
>>
>> Why does this command use -extfile and not -config?  Is it because 
>> ALL that is taken from config is -extensions?  Confusing to the 
>> casual user.
>>
>> But why the error?
>>
>> And yes, I know I can convert a PEM cert to DER, but I would also 
>> have to convert the private key, and maintain duo structures in 
>> places.  Would RATHER have a parallel setup.  Of course there is the 
>> challenge of the cert chain that Viktor earlier explained. OCSP? :)
>>
>>
> I don't think you have to pass all the various formats as PEM just
> because you pass one of them as such.  After all, there are separate
> -XXXform style options for most of them.
>
> For example, you could store the CA private key in the encryption-
> supporting PEM format on the plentyful memory of the SD card, while
> using the more compact DER format for certificates and CSRs stored
> on embedded controllers (ECUs, dashboard displays etc.).
>
> Where OpenSSL bugs prevent use of DER for a file, it can be converted
> on the fly, storing the converted file in RAM (using tmpfs or similar).

I know this is an option, and if I can't get this working, then I have 
to punt.

I am considering to make the Root and Intermediate files all PEM, and 
only the EE is DER.

Should get to that tomorrow.  I would rather establish that what I tried 
above is just still not allowed, or it is a bug.

Bob


From rsalz at akamai.com  Wed Aug 23 22:00:45 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 23 Aug 2017 22:00:45 +0000
Subject: [openssl-users] ERR_add_error_data
In-Reply-To: <CADqLbzJJirtOcA_QWQ87Wxz-GCmv4mGuiJXVsDVY-3yqVGaAyg@mail.gmail.com>
References: <CADqLbzJJirtOcA_QWQ87Wxz-GCmv4mGuiJXVsDVY-3yqVGaAyg@mail.gmail.com>
Message-ID: <3D2829DF-8F80-4F9E-A23C-F8A4775884C8@akamai.com>

?  What happens if I call the ERR_add_error_data twice? Will it add the arguments or replace them?

It replaces, free?ing the old.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170823/d02067fe/attachment.html>

From nacao2001 at hotmail.com  Wed Aug 23 12:22:48 2017
From: nacao2001 at hotmail.com (Ignacio Alamo Corsino)
Date: Wed, 23 Aug 2017 12:22:48 +0000
Subject: [openssl-users] confusion with rsa_meth_st in a custom RSA
	engine
In-Reply-To: <BN3PR03MB1462DEDC32973000CDAB1622E0850@BN3PR03MB1462.namprd03.prod.outlook.com>
References: <BN3PR03MB1462DEDC32973000CDAB1622E0850@BN3PR03MB1462.namprd03.prod.outlook.com>
Message-ID: <DB6PR0701MB243993DA5388FCDC490E214FAE850@DB6PR0701MB2439.eurprd07.prod.outlook.com>

Hello Brett,


First, to your comment: "I'm just confused as to at what point in the RSA encryption/decryption process my engine should be invoked at":

It really depends on how your hardware performs the operations.


I mean, you are right, if you set RSA_FLAG_EXT_PKEY  then you only have to rewrite rsa_mod_exp but you have to make sure that you are at the right spot when your

hardware jumps in.

This is (more or less) the workflow for RSA signing:

(obtain digest) -> RSA_sign (makes pkcs1 encoding) -> RSA_private_encrypt (makes padding and blinding) -> rsa_mod_exp (with flag) or bn_mod_exp (without)

Each step makes different operations before calling the next function. So if your hardware takes care of the pkcs1 encoding and so on, then you should overwrite RSA_sign
(using the RSA_FLAG_SIGN_VER flag) but if you are sure that it only performs the rsa_mod_exp operations then go ahead and rewrite it with your userspace API.

I found really helpful to read the OpenSSL default rsa_method to see how RSA works: /crypto/rsa/rsa_ossl.c

Sorry if I could not directly answer your question on which method you should overwrite but I hope this info helps you to find out.

Regards,

Ignacio

________________________________
De: openssl-users <openssl-users-bounces at openssl.org> en nombre de Brett R. Nicholas <Brett.R.Nicholas.TH at dartmouth.edu>
Enviado: mi?rcoles, 23 de agosto de 2017 3:44
Para: openssl-users at openssl.org
Asunto: [openssl-users] confusion with rsa_meth_st in a custom RSA engine


I am trying to develop a engine for a custom RSA hardware accelerator, and have a few questions about the RSA_METHOD stucture implementation.


Some context: for encryption, my accelerator takes as inputs the base, public exponent, and modulus, and returns the resulting ciphertext. For decryption, it takes as inputs the base, and modulus. It does not need a private key, as this is stored in hardware, and can only be configured through an out-of-band channel. I already have a kernel module that exposes an API to userspace programs to use the accelerator. Now I just need to integrate it into openSSL.


I've already created a similar engine for AES and SHA256, however I'm struggling with RSA. Ideally, I'd like to not have to worry about anything other than just performing the modular exponentiation on a pre-padded and prepared chunk of data. For SHA and AES, this is straightforward: all that was taken care of by the EVP interface, so all I needed to worry about was getting the data two and from my accelerators. But it doesn't appear to be as simple for RSA (pls correct me if I'm wrong).


I'm confused as to which RSA_METHOD function pointers that my engine needs to implement.  I show the structure below for reference:

struct rsa_meth_st {
    char *name;
    int (*rsa_pub_enc) (int flen, const unsigned char *from,
                        unsigned char *to, RSA *rsa, int padding);
    int (*rsa_pub_dec) (int flen, const unsigned char *from,
                        unsigned char *to, RSA *rsa, int padding);
    int (*rsa_priv_enc) (int flen, const unsigned char *from,
                         unsigned char *to, RSA *rsa, int padding);
    int (*rsa_priv_dec) (int flen, const unsigned char *from,
                         unsigned char *to, RSA *rsa, int padding);

    int (*rsa_mod_exp) (BIGNUM *r0, const BIGNUM *I, RSA *rsa, BN_CTX *ctx);

    int (*bn_mod_exp) (BIGNUM *r, const BIGNUM *a, const BIGNUM *p,
                       const BIGNUM *m, BN_CTX *ctx, BN_MONT_CTX *m_ctx);
    /* ....stuff.... */
    int flags;
    /* .... stuff ... */
};  // TYPEDEF'ED TO RSA_METHOD in include/ossl_typ.h


So, three questions:


  1.  Is it possible for the standard OpenSSL RSA implementation to use my engine's "modular exponentiation" function, without having to rewrite the RSA_[public|private]_[encrypt|decrypt] family of functions from /include/openssl/rsa.h?
  2.  If so, does it suffice to only implement the rsa_mod_exp function? Or must I implement both public_enc/dec and private_enc/dec functions as well? I ask, because the source code for the old Intel RSAX engine (https://gist.github.com/bigbrett/91903f773f9d150b7329c7d462cd220a) does this, but I can't figure out how and when in the "RSA flow" the engine's function gets invoked.
  3.  In  /include/openssl/rsa.h, I saw the following macro for the RSA_METHOD flag field (line 55):

/*
 * This flag means the private key operations will be handled by rsa_mod_exp
 * and that they do not depend on the private key components being present:
 * for example a key stored in external hardware. Without this flag
 * bn_mod_exp gets called when private key components are absent.
 */
# define RSA_FLAG_EXT_PKEY               0x0020


Does this mean that if I use this flag in the "flags" field of RSA_METHOD, that I DO NOT need to implement rsa_pub_enc/dec and friends? I guess I'm just confused as to at what point in the RSA encryption/decryption process my engine should be invoked at.


FWIW I'm planning on releasing a comprehensive engine tutorial and some documentation for all this stuff once I finish (will already be written up in my thesis), so I want to make sure I get these details ironed out!


Any words of wisdom would be greatly appreciated.


Best,

Brett

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170823/fc54caa5/attachment-0001.html>

From uri at ll.mit.edu  Thu Aug 24 21:42:55 2017
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Thu, 24 Aug 2017 21:42:55 +0000
Subject: [openssl-users] Dgst sigopt parameters
Message-ID: <7D69FF2E-AE16-42A6-8F97-817A835E5153@ll.mit.edu>

OpenSSL dgst manual page only days that sigopt value are algorithm-specific. Where are they described for ECDSA and RSA PSS?

Thanks!

Regards,
Uri

Sent from my iPhone
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4223 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170824/e21f5a74/attachment.bin>

From rgm at htt-consult.com  Sun Aug 27 05:02:20 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Sun, 27 Aug 2017 01:02:20 -0400
Subject: [openssl-users] Cant get openssl x509 to work as documented
In-Reply-To: <a2bce8f9-2396-8d38-2305-1a07f302e3f2@wisemo.com>
References: <a0744d60-28cc-28a4-6866-2b09776bf65a@htt-consult.com>
 <b81c814b-73b3-5b38-1d66-44ec150dc931@htt-consult.com>
 <a2bce8f9-2396-8d38-2305-1a07f302e3f2@wisemo.com>
Message-ID: <dd08aeb0-4308-c72e-4948-98280cb8d0ca@htt-consult.com>

Jakob,

You make a good point.  In fact, after some reflection, there is 
probably no reason for the device to store more than the 96 bytes of 
keyvalue in secure store.  If some format is needed to use the key, that 
can be done at that time.  This is for the case where the device 
supports only one algorithm.

I know that the current practice is crypto agility, but IoT, 
particularly automotive IoT, will select and live with one for a 
generation of product.  When the next best thing is selected, then that 
will be used, but not retrofitted.  I hope that soon, I will be able to 
push Ed25519; I am concerned about the computational cost, though (still 
not clear why SHA512 and not SHAKE128).  Meanwhile P256 is what is fielded.

Bob

On 08/23/2017 03:52 PM, Jakob Bohm wrote:
> On 22/08/2017 22:26, Robert Moskowitz wrote:
>> Want to continue this thread but with new information.  I built a 
>> Fedora-arm 26 system (on a Cubieboard2) and it has openssl version 
>> 1.1.0f
>>
>> I built my DER root cert (and private key) no problem.
>>
>> I built my DER Intermediate cert private key and CSR no problem.
>>
>> For the following command:
>>
>> sn=8
>> format=der
>> dir=/root/ca3
>> cadir=/root/ca3
>>
>> openssl x509 -req -days 3650 -extfile $cadir/openssl-root.cnf 
>> -extensions v3_intermediate_ca\
>>  -sha256 -set_serial 0x$(openssl rand -hex $sn)\
>>  -inform $format -in $dir/csr/intermediate.csr.$format\
>>  -outform $format -out $dir/certs/intermediate.cert.$format\
>>  -CAkeyform $format -CAkey $cadir/private/ca.key.$format\
>>  -CAform $format -CA $cadir/certs/ca.cert.$format
>>
>> I built this reading:
>>
>> https://www.openssl.org/docs/man1.1.0/apps/x509.html
>>
>> This generates:
>>
>> 3069592528:error:0906D06C:PEM routines:PEM_read_bio:no start 
>> line:crypto/pem/pem_lib.c:691:Expecting: CERTIFICATE REQUEST
>>
>> The man page above has CAkeyform and CAform in the summary, but no 
>> details below.  I am ASSUMEing DER is now supported.
>>
>> for -sha256, I finally figured out that -[digest] is how the the man 
>> presents which hash to use.
>>
>> Why does this command use -extfile and not -config?  Is it because 
>> ALL that is taken from config is -extensions?  Confusing to the 
>> casual user.
>>
>> But why the error?
>>
>> And yes, I know I can convert a PEM cert to DER, but I would also 
>> have to convert the private key, and maintain duo structures in 
>> places.  Would RATHER have a parallel setup.  Of course there is the 
>> challenge of the cert chain that Viktor earlier explained. OCSP? :)
>>
>>
> I don't think you have to pass all the various formats as PEM just
> because you pass one of them as such.  After all, there are separate
> -XXXform style options for most of them.
>
> For example, you could store the CA private key in the encryption-
> supporting PEM format on the plentyful memory of the SD card, while
> using the more compact DER format for certificates and CSRs stored
> on embedded controllers (ECUs, dashboard displays etc.).
>
> Where OpenSSL bugs prevent use of DER for a file, it can be converted
> on the fly, storing the converted file in RAM (using tmpfs or similar).
>
>
> Enjoy
>
> Jakob


From mahesh116 at gmail.com  Mon Aug 28 05:09:01 2017
From: mahesh116 at gmail.com (mahesh gs)
Date: Mon, 28 Aug 2017 10:39:01 +0530
Subject: [openssl-users] Existing connections on certification expires
Message-ID: <CAF7NSfS743y+nF3tnRQh0D3g3eG4dg1mQcg2BeUmV2cigWNdQg@mail.gmail.com>

Hello All,

We are using openssl for providing the secured communication for our
application. I have some basic queries about the openssl behaviour.

1) What happens to the existing SSL connections on certification expiry?
Does the openssl disconnects the existing connection?

2) How can i get the list of ciphers supported by openssl 01.01.0f ?

These question looks to be very basic but i could not find any concrete
information regarding the same googling.

Thanks,
Mahesh G S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170828/9f12edab/attachment.html>

From paulyang.inf at gmail.com  Mon Aug 28 06:01:31 2017
From: paulyang.inf at gmail.com (Paul Yang)
Date: Mon, 28 Aug 2017 14:01:31 +0800
Subject: [openssl-users] Existing connections on certification expires
In-Reply-To: <CAF7NSfS743y+nF3tnRQh0D3g3eG4dg1mQcg2BeUmV2cigWNdQg@mail.gmail.com>
References: <CAF7NSfS743y+nF3tnRQh0D3g3eG4dg1mQcg2BeUmV2cigWNdQg@mail.gmail.com>
Message-ID: <884E8867-48B8-4412-99BB-B10D6B2F2AEB@gmail.com>


> On 28 Aug 2017, at 13:09, mahesh gs <mahesh116 at gmail.com> wrote:
> 
> Hello All,
> 
> We are using openssl for providing the secured communication for our application. I have some basic queries about the openssl behaviour.
> 
> 1) What happens to the existing SSL connections on certification expiry? Does the openssl disconnects the existing connection?

It depends on how you control OpenSSL to process the verification. Read the man page of SSL_CTX_set_verify (and related) function. Seems you can find the doc there: https://wiki.openssl.org/index.php/Manual:SSL_CTX_set_verify(3) <https://wiki.openssl.org/index.php/Manual:SSL_CTX_set_verify(3)>
> 
> 2) How can i get the list of ciphers supported by openssl 01.01.0f ?

Either by using an API as ?SSL_get_ciphers? or a command line tool ?openssl ciphers some-options', read related documentation for details.

> 
> These question looks to be very basic but i could not find any concrete information regarding the same googling. 
> 
> Thanks,
> Mahesh G S
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170828/d25ff20d/attachment.html>

From rgm at htt-consult.com  Mon Aug 28 10:13:51 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Mon, 28 Aug 2017 06:13:51 -0400
Subject: [openssl-users] Existing connections on certification expires
In-Reply-To: <CAF7NSfS743y+nF3tnRQh0D3g3eG4dg1mQcg2BeUmV2cigWNdQg@mail.gmail.com>
References: <CAF7NSfS743y+nF3tnRQh0D3g3eG4dg1mQcg2BeUmV2cigWNdQg@mail.gmail.com>
Message-ID: <0173e624-aa2b-23db-d050-e7a33e19cd7c@htt-consult.com>



On 08/28/2017 01:09 AM, mahesh gs wrote:
> Hello All,
>
> We are using openssl for providing the secured communication for our 
> application. I have some basic queries about the openssl behaviour.
>
> 1) What happens to the existing SSL connections on certification 
> expiry? Does the openssl disconnects the existing connection?

Generally speaking:

openssl has nothing to do with a SSL/TLS connection.  It created the 
certificate, it is not the application using the certificate.

That is commonly a server app (HTTPS, IMAPS, VPN server, etc.) and a 
client (Web browser, Mail client, VPN client).  Most of these pay no 
attention to the expiry date.  Some, like IPsec specify to check the 
expiry date and set the maximum connection lifetime to less that it.  Of 
course even there your mileage will vary by how each product author read 
the specs.

>
> 2) How can i get the list of ciphers supported by openssl 01.01.0f ?
>
> These question looks to be very basic but i could not find any 
> concrete information regarding the same googling.
>
> Thanks,
> Mahesh G S
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170828/0dde2edf/attachment-0001.html>

From rgm at htt-consult.com  Mon Aug 28 12:25:35 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Mon, 28 Aug 2017 08:25:35 -0400
Subject: [openssl-users] Existing connections on certification expires
In-Reply-To: <0173e624-aa2b-23db-d050-e7a33e19cd7c@htt-consult.com>
References: <CAF7NSfS743y+nF3tnRQh0D3g3eG4dg1mQcg2BeUmV2cigWNdQg@mail.gmail.com>
 <0173e624-aa2b-23db-d050-e7a33e19cd7c@htt-consult.com>
Message-ID: <81207f0d-2950-e7e5-8e1d-3d8ba49f55dd@htt-consult.com>



On 08/28/2017 06:13 AM, Robert Moskowitz wrote:
>
>
> On 08/28/2017 01:09 AM, mahesh gs wrote:
>> Hello All,
>>
>> We are using openssl for providing the secured communication for our 
>> application. I have some basic queries about the openssl behaviour.
>>
>> 1) What happens to the existing SSL connections on certification 
>> expiry? Does the openssl disconnects the existing connection?
>
> Generally speaking:
>
> openssl has nothing to do with a SSL/TLS connection.  It created the 
> certificate, it is not the application using the certificate.
>
> That is commonly a server app (HTTPS, IMAPS, VPN server, etc.) and a 
> client (Web browser, Mail client, VPN client).  Most of these pay no 
> attention to the expiry date.  Some, like IPsec specify to check the 
> expiry date and set the maximum connection lifetime to less that it.  
> Of course even there your mileage will vary by how each product author 
> read the specs.

I recall now the IPsec debate on this.  The consensus was that at the 
time of connection setup, the certificate was valid.  Thus the parties 
could set whatever connection lifetime they have in their policy.  It 
was not considered MANDATORY to shorten the lifetime to the certificate 
expiry date.  This was important, as there are IPsec policies with 
month-long connection lifetimes.

>
>>
>> 2) How can i get the list of ciphers supported by openssl 01.01.0f ?
>>
>> These question looks to be very basic but i could not find any 
>> concrete information regarding the same googling.
>>
>> Thanks,
>> Mahesh G S
>>
>>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170828/1cf42c25/attachment.html>

From openssl-users at dukhovni.org  Mon Aug 28 13:07:47 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 28 Aug 2017 13:07:47 +0000
Subject: [openssl-users] Existing connections on certification expires
In-Reply-To: <0173e624-aa2b-23db-d050-e7a33e19cd7c@htt-consult.com>
References: <CAF7NSfS743y+nF3tnRQh0D3g3eG4dg1mQcg2BeUmV2cigWNdQg@mail.gmail.com>
 <0173e624-aa2b-23db-d050-e7a33e19cd7c@htt-consult.com>
Message-ID: <20170828130747.GC3322@mournblade.imrryr.org>

On Mon, Aug 28, 2017 at 06:13:51AM -0400, Robert Moskowitz wrote:

> > 1) What happens to the existing SSL connections on certification expiry?
> > Does the openssl disconnects the existing connection?

No, once authenticated, TLS connections continue indefinitely,
until either party chooses to disconnect.  The expiration of the
certificate does not invalidate the integrity of the original key
exchange, and presents no obvious increased risk of active attack.

> Generally speaking:
> 
> openssl has nothing to do with a SSL/TLS connection.  It created the
> certificate, it is not the application using the certificate.

This is wrong.  Many applications delegate certificate verification
to the OpenSSL library.  OpenSSL does not limit connection lifetime
based on certificate expiration.

> That is commonly a server app (HTTPS, IMAPS, VPN server, etc.) and a client
> (Web browser, Mail client, VPN client).  Most of these pay no attention to
> the expiry date.

This is wrong.

-- 
	Viktor.

From rgm at htt-consult.com  Mon Aug 28 13:26:22 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Mon, 28 Aug 2017 09:26:22 -0400
Subject: [openssl-users] Existing connections on certification expires
In-Reply-To: <20170828130747.GC3322@mournblade.imrryr.org>
References: <CAF7NSfS743y+nF3tnRQh0D3g3eG4dg1mQcg2BeUmV2cigWNdQg@mail.gmail.com>
 <0173e624-aa2b-23db-d050-e7a33e19cd7c@htt-consult.com>
 <20170828130747.GC3322@mournblade.imrryr.org>
Message-ID: <8b00e592-6e05-e325-aed1-c88333063f9b@htt-consult.com>



On 08/28/2017 09:07 AM, Viktor Dukhovni wrote:
> On Mon, Aug 28, 2017 at 06:13:51AM -0400, Robert Moskowitz wrote:
>
>>> 1) What happens to the existing SSL connections on certification expiry?
>>> Does the openssl disconnects the existing connection?
> No, once authenticated, TLS connections continue indefinitely,
> until either party chooses to disconnect.  The expiration of the
> certificate does not invalidate the integrity of the original key
> exchange, and presents no obvious increased risk of active attack.
>
>> Generally speaking:
>>
>> openssl has nothing to do with a SSL/TLS connection.  It created the
>> certificate, it is not the application using the certificate.
> This is wrong.  Many applications delegate certificate verification
> to the OpenSSL library.  OpenSSL does not limit connection lifetime
> based on certificate expiration.

Argh, you are right.  The libraries are indeed used.  I was thinking the 
whole program.  My error.  Thinking too narrowly.

>
>> That is commonly a server app (HTTPS, IMAPS, VPN server, etc.) and a client
>> (Web browser, Mail client, VPN client).  Most of these pay no attention to
>> the expiry date.
> This is wrong.

They pay no attention to the expiry date to force the session to end at 
that time by adjusting the session lifetime to be no later than the 
expiry date.  Though there are probably apps out there with this behavior.

They do indeed ensure that the certificate is within its dates.  A 
nuance that I did not make clear.



From alan.buxey at gmail.com  Mon Aug 28 13:44:13 2017
From: alan.buxey at gmail.com (Alan Buxey)
Date: Mon, 28 Aug 2017 14:44:13 +0100
Subject: [openssl-users] Existing connections on certification expires
In-Reply-To: <81207f0d-2950-e7e5-8e1d-3d8ba49f55dd@htt-consult.com>
References: <CAF7NSfS743y+nF3tnRQh0D3g3eG4dg1mQcg2BeUmV2cigWNdQg@mail.gmail.com>
 <0173e624-aa2b-23db-d050-e7a33e19cd7c@htt-consult.com>
 <81207f0d-2950-e7e5-8e1d-3d8ba49f55dd@htt-consult.com>
Message-ID: <CAOVYXj_pdvmJFWUuj=gt9wUk8-wsMWr7jB=+E0UmYXR0Mi0ELg@mail.gmail.com>

hi,


> 2) How can i get the list of ciphers supported by openssl 01.01.0f ?


openssl ciphers -v ???


> These question looks to be very basic but i could not find any concrete
> information regarding the same googling.

Google provides the answers if your question is well formed. or you
could just read the
openssl man pages?

alan

From rgm at htt-consult.com  Mon Aug 28 13:58:03 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Mon, 28 Aug 2017 09:58:03 -0400
Subject: [openssl-users] Existing connections on certification expires
In-Reply-To: <CAOVYXj_pdvmJFWUuj=gt9wUk8-wsMWr7jB=+E0UmYXR0Mi0ELg@mail.gmail.com>
References: <CAF7NSfS743y+nF3tnRQh0D3g3eG4dg1mQcg2BeUmV2cigWNdQg@mail.gmail.com>
 <0173e624-aa2b-23db-d050-e7a33e19cd7c@htt-consult.com>
 <81207f0d-2950-e7e5-8e1d-3d8ba49f55dd@htt-consult.com>
 <CAOVYXj_pdvmJFWUuj=gt9wUk8-wsMWr7jB=+E0UmYXR0Mi0ELg@mail.gmail.com>
Message-ID: <12d60902-11f3-2200-eafb-df5daab686be@htt-consult.com>



On 08/28/2017 09:44 AM, Alan Buxey wrote:
> hi,
>
>
>> 2) How can i get the list of ciphers supported by openssl 01.01.0f ?
>
> openssl ciphers -v ???
>
>
>> These question looks to be very basic but i could not find any concrete
>> information regarding the same googling.
> Google provides the answers if your question is well formed. or you
> could just read the
> openssl man pages?

And I have found Professor Google to be very patient with me as I form 
my questions to get answers I can work with.  But there HAVE been times 
when my search foo has been weak, and the good Professor just can't 
figure out what I want to learn....

Bob



From mcr at sandelman.ca  Mon Aug 28 17:07:58 2017
From: mcr at sandelman.ca (Michael Richardson)
Date: Mon, 28 Aug 2017 13:07:58 -0400
Subject: [openssl-users] proposed changes to ruby-openssl create_extension
Message-ID: <12052.1503940078@obiwan.sandelman.ca>


Like Bob Moskowitz who has been posting about IDevID, I have also been
creating certificates with custom/private extensions in aid of creating
IDevIDs.

I'm one of the authors of both:
    https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/
and https://datatracker.ietf.org/doc/draft-ietf-anima-voucher/

I want to create certificates with custom/private extensions programatically,
and I found it very difficult to do using the current ruby-openssl modules.

I was sure that it must be possible from the C-API, and found that this
following change to ruby's interface worked well for me:
    https://github.com/ruby/openssl/pull/141


    } I haven't found a seperate openssl-ruby list as yet, so please  {
    } excuse the BCC, and as this is not a security issue, I haven't  {
    } used that address.  Please redirect me.                         {


The critical change being:
-    ext = X509V3_EXT_nconf_nid(conf, ctx, nid, RSTRING_PTR(valstr));
+    ext = X509V3_EXT_nconf(conf, ctx, RSTRING_PTR(oid), RSTRING_PTR(value));

Because EXT_nconf does all the nid lookups, and processes the generics
itself, no point in the ruby-ssl code limiting itself to OIDs predefined
in objects.h by it's use of nid lookups directly.


    ** I'm asking the Openssl team if I'm using the API reasonably **
    ** Clearly, I have some possible garbage that has leaked in    **

My code looks like:

    @idevid.add_extension(ef.create_extension(
                          "subjectAltName",
                          sprintf("otherName:1.3.6.1.4.1.46930.1;UTF8:%s",
                                   self.sanitized_eui64),
                          false))

which let me put a private extension having my private hardware number into
the SAN.  That works just great, I think.  I have in fact extracted the
result in metdtls code in my constrained device a few months ago.

After my changes above, I could now also do: (46930 being my PEN)

@idevid.add_extension(ef.create_extension(
                      "1.3.6.1.4.1.46930.2",
                      "ASN1:UTF8String:http://www.sandelman.ca",
                      false))

which would insert a MASAURL (using a PEN until we get an id-pe OID
allocated) as described in: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-07#section-2.2

Of concern is that when I look at the resulting certificate:

dooku-[fountain/spec/certs](2.3.0) mcr 10006 %openssl x509 -noout -text -in
12-00-00-66-4D-02.crt
Certificate:
...
            X509v3 Subject Alternative Name:
                othername:<unsupported>
            1.3.6.1.4.1.46930.2:
                ..http://www.sandelman.ca

Looking at a hexdump I see "0x0c" and "0x17" prior to the http, but maybe
it's a length or something.... I wondered if there was garbage or a UTF-8 BOM
or something inserted..  so, I pointed asn1parse at the result, and I see:

400:d=5  hl=2 l=   9 prim: OBJECT            :1.3.6.1.4.1.46930.2
411:d=5  hl=2 l=  25 prim: OCTET STRING      [HEX DUMP]:0C17687474703A2F2F7777772E73616E64656C6D616E2E6361

So the 0xc and 0x17 are really there.

Clearly, it's not being take as an UTF8String (because I would expect to see
UTF8STRING as the type if it were), yet the ASN1:UTF8String is in fact being
processed somehow.

If you want to see the whole certificate result, as sample/test data to my
Registrar:
  https://github.com/mcr/fountain/blob/master/spec/certs/12-00-00-66-4D-02.crt

--
]               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: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170828/69d0c641/attachment.sig>

From rsalz at akamai.com  Tue Aug 29 00:11:02 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 29 Aug 2017 00:11:02 +0000
Subject: [openssl-users] CVE 2017-3735 OOB read
Message-ID: <802EA6B2-0BE2-41D3-81BC-216BE0FEF478@akamai.com>

From https://www.openssl.org/news/secadv/20170828.txt

OpenSSL Security Advisory [28 Aug 2017]
========================================

Malformed X.509 IPAdressFamily could cause OOB read (CVE-2017-3735)
===================================================================

Severity: Low

If an X.509 certificate has a malformed IPAddressFamily extension,
OpenSSL could do a one-byte buffer overread. The most likely result
would be an erroneous display of the certificate in text format.

As this is a low severity fix, no release is being made. The fix can be
found in the source repository (1.0.2, 1.1.0, and master branches); see
https://github.com/openssl/openssl/pull/4276. This bug has been present
since 2006.


This issue was found by Google's OSS-Fuzz project on August 22.
The fix was developed by Rich Salz of the OpenSSL development team.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170829/d48d4e27/attachment-0001.html>

From andrey.ribalko at gmail.com  Tue Aug 29 05:02:17 2017
From: andrey.ribalko at gmail.com (Andrey Ribalko)
Date: Tue, 29 Aug 2017 08:02:17 +0300
Subject: [openssl-users] DH p parameter length
Message-ID: <CA+vnGZpnHXt30wRA_7bitd4113F+_gKdOJp1vtYm5MLcCn-esA@mail.gmail.com>

Hello everybody,

I'm trying to force openssl s_server to use DH p parameter of 2048 bits
length, but I can't find the way to do it.
I've noticed that the length of p parameter depends on chosen cipher.
For example, if I'm using DHE_PSK_WITH_AES_128_CBC_SHA256 the length of p
parameter is 1024 bits,
but if I'm using DHE_PSK_WITH_AES_256_CBC_SHA384 the length is 3072 bits.

I've tried to generate DH parameters PEM file by the following command:

*openssl genpkey -genparam -algorithm DH -out /tmp/test_dh_params.pem
-pkeyopt dh_paramgen_prime_len:2048*
And to load the file to s_server by:

*openssl s_server -state -trace -dhparam /tmp/test_dh_params.pem -accept
443 -psk 1a2b3c4d -nocert*
But I'm getting an error:

*Error with command: "-dhparam /tmp/test_dh_params.pem"*
Is there an easy way to do what I'm trying to do?
Any help would be appreciated.

Best regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170829/4f267113/attachment.html>

From mcr at sandelman.ca  Tue Aug 29 20:09:50 2017
From: mcr at sandelman.ca (Michael Richardson)
Date: Tue, 29 Aug 2017 16:09:50 -0400
Subject: [openssl-users] [ruby/openssl] instead of looking of NIDs and
	then using X509V3_EXT_nconf_nid, (#141)
In-Reply-To: <ruby/openssl/pull/141/c325541591@github.com>
References: <ruby/openssl/pull/141@github.com>
 <ruby/openssl/pull/141/c325541591@github.com>
Message-ID: <28735.1504037390@obiwan.sandelman.ca>


Thank you so much for the reply.

I will comment in the issue as requested, but I'll do so in email so that I
can CC the openssl-users list.

Kazuki Yamaguchi <notifications at github.com> wrote:
    > The ruby-core mailing list or this GitHub issue tracker is the right
    > place for questions about ruby-openssl.

    mcr> Of concern is that when I look at the resulting certificate:

    mcr> dooku-[fountain/spec/certs](2.3.0) mcr 10006 %openssl x509 -noout -text
    mcr> -in 12-00-00-66-4D-02.crt Certificate: ...  X509v3 Subject Alternative
    mcr> Name: othername: 1.3.6.1.4.1.46930.2: ..http://www.sandelman.ca

    mcr> Looking at a hexdump I see "0x0c" and "0x17" prior to the http, but
    mcr> maybe it's a length or something.... I wondered if there was garbage or
    mcr> a UTF-8 BOM or something inserted..  so, I pointed asn1parse at the
    mcr> result, and I see:

ky> NIDs can be added at run time with OpenSSL::ASN1::ObjectId.register
ky> (which calls OBJ_create()), but yes, this should be fixed.

I did not find a way to call OBJ_create() from ruby.  Is there one?
Many OpenSSL FAQs suggest you need to hack objects.h and recompile, which is
clearly a PITA if you are trying to live above distribute ruby binaries, so I
was looking for another way.

ky> For whatever reason, OpenSSL::X509::ExtensionFactory#create_ext has
ky> accepted long names which aren't handled by the non-generic extensions
ky> path of X509V3_EXT_nconf(). For compatibility I guess it will be like
ky> this...

Ah, that's why it uses that way.
I'll add that code to my tree, and update the pull request.

Are there regression tests which cover that?
I was hoping travis would tell me about such failures that I didn't know
about :-)

ky> It's working as expected. The ASN.1 type definition of Extension is:

ky>                 -- contains the DER encoding of an ASN.1 value

ky> The leading "\x0c\x17" is the BER tag and the length of the UTF8String
ky> encapsulated in the 'extnValue'.

okay, so "openssl x509 -text" is failing to decode that then.

#  @value="http://www.sandelman.ca">

Awesome!

--
]               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: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170829/b2a9f7a0/attachment.sig>

From rgm at htt-consult.com  Tue Aug 29 21:27:58 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Tue, 29 Aug 2017 17:27:58 -0400
Subject: [openssl-users] Not updating index.txt
Message-ID: <4624e107-f1da-b980-e1b5-8ff51496339a@htt-consult.com>

I started out making certs from csrs with:

openssl ca -config $dir/openssl-intermediate.cnf -extensions usr_cert 
-days 375 -notext -md sha256 \
       -in $dir/csr/$clientemail.csr.$format -out 
$dir/certs/$clientemail.cert.$format

And that worked well enough, but I found some limitations (DER) with it 
and switched to:


    openssl x509 -req -days 375 -extfile $dir/openssl-intermediate.cnf\
        -extensions usr_cert -sha256\
        -set_serial 0x$(openssl rand -hex $sn)\
        -inform $format -in $dir/csr/$clientemail.csr.$format\
        -outform $format -out $dir/certs/$clientemail.cert.$format\
        -CAkeyform $format -CAkey $dir/private/intermediate.key.$format\
        -CAform $format -CA $dir/certs/intermediate.cert.$format

I just noticed that this format does not update the index.txt file. 
Why?  What do I need to add so it does?

Bob



From rgm at htt-consult.com  Tue Aug 29 21:36:34 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Tue, 29 Aug 2017 17:36:34 -0400
Subject: [openssl-users] Another problem with openssl x509 -req --
	default_enddate
Message-ID: <cb7c3f52-a798-c1a5-2d69-6a56a89a03c3@htt-consult.com>

Another problem.  It is almost like it is not reading the CA selction?

openssl ca -config $dir/openssl-8021AR.cnf -extensions 8021ar_idevid 
-notext -md sha256 \
       -in $dir/csr/$DevID.csr.pem -out $dir/certs/$DevID.cert.pem

processes the default_enddate

default_enddate= 99991231235959Z # per IEEE 802.1AR

to produce:

             Not Before: Aug 29 21:19:33 2017 GMT
             Not After : Dec 31 23:59:59 9999 GMT


But

    openssl x509 -req -extfile $dir/openssl-8021AR.cnf\
         -extensions 8021ar_idevid -days 365 -sha256\
         -set_serial 0x$(openssl rand -hex $sn)\
         -inform $format -in $dir/csr/$DevID.csr.$format\
         -outform $format -out $dir/certs/$DevID.cert.$format\
         -CAkeyform $format -CAkey 
$dir/private/8021ARintermediate.key.$format\
         -CAform $format -CA $dir/certs/8021ARintermediate.cert.$format

does not.  Even if I leave out the -days option.

I am thinking, do I need to use:

-extensions ca 8021ar_idevid

?? but that will probably be a syntax error.

thanks



From steve at openssl.org  Tue Aug 29 23:24:09 2017
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 29 Aug 2017 23:24:09 +0000
Subject: [openssl-users] Not updating index.txt
In-Reply-To: <4624e107-f1da-b980-e1b5-8ff51496339a@htt-consult.com>
References: <4624e107-f1da-b980-e1b5-8ff51496339a@htt-consult.com>
Message-ID: <20170829232409.GA8925@openssl.org>

On Tue, Aug 29, 2017, Robert Moskowitz wrote:

> I started out making certs from csrs with:
> 
> openssl ca -config $dir/openssl-intermediate.cnf -extensions
> usr_cert -days 375 -notext -md sha256 \
>       -in $dir/csr/$clientemail.csr.$format -out
> $dir/certs/$clientemail.cert.$format
> 
> And that worked well enough, but I found some limitations (DER) with
> it and switched to:
> 
> 
>    openssl x509 -req -days 375 -extfile $dir/openssl-intermediate.cnf\
>        -extensions usr_cert -sha256\
>        -set_serial 0x$(openssl rand -hex $sn)\
>        -inform $format -in $dir/csr/$clientemail.csr.$format\
>        -outform $format -out $dir/certs/$clientemail.cert.$format\
>        -CAkeyform $format -CAkey $dir/private/intermediate.key.$format\
>        -CAform $format -CA $dir/certs/intermediate.cert.$format
> 
> I just noticed that this format does not update the index.txt file.
> Why?  What do I need to add so it does?
> 

Unlike ca the  index.txt file is not used by the x509 utility at all it also
only uses the configuration file for extensions.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From openssl-users at dukhovni.org  Tue Aug 29 23:25:33 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 29 Aug 2017 23:25:33 +0000
Subject: [openssl-users] Another problem with openssl x509 -req --
 default_enddate
In-Reply-To: <cb7c3f52-a798-c1a5-2d69-6a56a89a03c3@htt-consult.com>
References: <cb7c3f52-a798-c1a5-2d69-6a56a89a03c3@htt-consult.com>
Message-ID: <20170829232533.GL3322@mournblade.imrryr.org>

On Tue, Aug 29, 2017 at 05:36:34PM -0400, Robert Moskowitz wrote:

> Another problem.  It is almost like it is not reading the CA selction?

Not "almost", but actually as expected, since "openssl x509 -req"
is not the ca(1) application.

>    openssl x509 -req -extfile $dir/openssl-8021AR.cnf \
>         -extensions 8021ar_idevid -days 365 -sha256 \
>         -set_serial 0x$(openssl rand -hex $sn) \
>         -inform $format -in $dir/csr/$DevID.csr.$format \
>         -outform $format -out $dir/certs/$DevID.cert.$format \
>         -CAkeyform $format -CAkey $dir/private/8021ARintermediate.key.$format \
>         -CAform $format -CA $dir/certs/8021ARintermediate.cert.$format
> 
> does not.  Even if I leave out the -days option.

It just creates a signed certificate based on the command-line
options, with only the extensions (-extfile option) read from a
configuration file.  The only concession to ca(1)-like behaviour
is support for a compatible serial number file (likely subject to
race conditions absent external locks to serialize invocations).

    * The version is 3, since you're using extensions
    * The serial number is specified on the command line.
    * The issuer DN is taken from the signing certificate.
    * The subject DN and public key are copied from the CSR

That just leaves the dates, and you get to specify the duration
from *now* with "-days".

With "x509 -req" you're building certs pretty much from the ground
up, a short C program will do exactly the same work, and could use
an explicit end date, rather than an increment of 'n' days from
the present.

-- 
	Viktor.

From rgm at htt-consult.com  Wed Aug 30 03:35:05 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Tue, 29 Aug 2017 23:35:05 -0400
Subject: [openssl-users] Not updating index.txt
In-Reply-To: <20170829232409.GA8925@openssl.org>
References: <4624e107-f1da-b980-e1b5-8ff51496339a@htt-consult.com>
 <20170829232409.GA8925@openssl.org>
Message-ID: <6859e4b8-3a0e-0923-822f-36292a69e236@htt-consult.com>



On 08/29/2017 07:24 PM, Dr. Stephen Henson wrote:
> On Tue, Aug 29, 2017, Robert Moskowitz wrote:
>
>> I started out making certs from csrs with:
>>
>> openssl ca -config $dir/openssl-intermediate.cnf -extensions
>> usr_cert -days 375 -notext -md sha256 \
>>        -in $dir/csr/$clientemail.csr.$format -out
>> $dir/certs/$clientemail.cert.$format
>>
>> And that worked well enough, but I found some limitations (DER) with
>> it and switched to:
>>
>>
>>     openssl x509 -req -days 375 -extfile $dir/openssl-intermediate.cnf\
>>         -extensions usr_cert -sha256\
>>         -set_serial 0x$(openssl rand -hex $sn)\
>>         -inform $format -in $dir/csr/$clientemail.csr.$format\
>>         -outform $format -out $dir/certs/$clientemail.cert.$format\
>>         -CAkeyform $format -CAkey $dir/private/intermediate.key.$format\
>>         -CAform $format -CA $dir/certs/intermediate.cert.$format
>>
>> I just noticed that this format does not update the index.txt file.
>> Why?  What do I need to add so it does?
>>
> Unlike ca the  index.txt file is not used by the x509 utility at all it also
> only uses the configuration file for extensions.

This, and what Viktor said is 'waking me up to' req is NOT a solution.

Back to ca.

thanks



From rgm at htt-consult.com  Wed Aug 30 04:17:09 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Wed, 30 Aug 2017 00:17:09 -0400
Subject: [openssl-users] Another problem with openssl x509 -req --
 default_enddate
In-Reply-To: <20170829232533.GL3322@mournblade.imrryr.org>
References: <cb7c3f52-a798-c1a5-2d69-6a56a89a03c3@htt-consult.com>
 <20170829232533.GL3322@mournblade.imrryr.org>
Message-ID: <222e638f-aa34-1781-eea3-83dfd5bc8011@htt-consult.com>

Viktor,

thanks for the explanation. Obviously I read more into the man that was 
really there:

https://www.openssl.org/docs/man1.1.0/apps/x509.html

So back to openssl ca and deal with no way to directly create a DER 
formatted cert.

Definitely a deficiency.

On 08/29/2017 07:25 PM, Viktor Dukhovni wrote:
> On Tue, Aug 29, 2017 at 05:36:34PM -0400, Robert Moskowitz wrote:
>
>> Another problem.  It is almost like it is not reading the CA selction?
> Not "almost", but actually as expected, since "openssl x509 -req"
> is not the ca(1) application.
>
>>     openssl x509 -req -extfile $dir/openssl-8021AR.cnf \
>>          -extensions 8021ar_idevid -days 365 -sha256 \
>>          -set_serial 0x$(openssl rand -hex $sn) \
>>          -inform $format -in $dir/csr/$DevID.csr.$format \
>>          -outform $format -out $dir/certs/$DevID.cert.$format \
>>          -CAkeyform $format -CAkey $dir/private/8021ARintermediate.key.$format \
>>          -CAform $format -CA $dir/certs/8021ARintermediate.cert.$format
>>
>> does not.  Even if I leave out the -days option.
> It just creates a signed certificate based on the command-line
> options, with only the extensions (-extfile option) read from a
> configuration file.  The only concession to ca(1)-like behaviour
> is support for a compatible serial number file (likely subject to
> race conditions absent external locks to serialize invocations).
>
>      * The version is 3, since you're using extensions
>      * The serial number is specified on the command line.
>      * The issuer DN is taken from the signing certificate.
>      * The subject DN and public key are copied from the CSR
>
> That just leaves the dates, and you get to specify the duration
> from *now* with "-days".
>
> With "x509 -req" you're building certs pretty much from the ground
> up, a short C program will do exactly the same work, and could use
> an explicit end date, rather than an increment of 'n' days from
> the present.
>


From openssl-users at dukhovni.org  Wed Aug 30 04:59:27 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 30 Aug 2017 04:59:27 +0000
Subject: [openssl-users] Another problem with openssl x509 -req --
 default_enddate
In-Reply-To: <222e638f-aa34-1781-eea3-83dfd5bc8011@htt-consult.com>
References: <cb7c3f52-a798-c1a5-2d69-6a56a89a03c3@htt-consult.com>
 <20170829232533.GL3322@mournblade.imrryr.org>
 <222e638f-aa34-1781-eea3-83dfd5bc8011@htt-consult.com>
Message-ID: <20170830045927.GN3322@mournblade.imrryr.org>

On Wed, Aug 30, 2017 at 12:17:09AM -0400, Robert Moskowitz wrote:

> So back to openssl ca and deal with no way to directly create a DER
> formatted cert.
> 
> Definitely a deficiency.

Not really a deficiency, as the certificates in question need to
be squirreled away in PEM format in the CA's "certs/" directory
(compatibility with longstanding behaviour), and are much more
easily exported, via email etc., in PEM format.

It is trivial to convert a PEM certificate to DER.  Mind you,
if I wanted a specialized CA, I'd go with the C API, where
you can do *exactly* what you want:

  * Store metadata in a SQL database.
  * Read keys directly from PKCS8
  * Write certs directly in DER form
  * ...

The openssl ca(1) program is to some extent just a demo, that meets
only the simplest needs.  Perhaps you were looking for a turnkey
CLI, but you have a specialized new use-case, and it is not entirely
surprising that it is not directly supported.

Patches to support missing features that might be of use to others
are welcome.  The software evolves best through community participation.

-- 
	Viktor.

From rgm at htt-consult.com  Wed Aug 30 10:03:03 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Wed, 30 Aug 2017 06:03:03 -0400
Subject: [openssl-users] Another problem with openssl x509 -req --
 default_enddate
In-Reply-To: <20170830045927.GN3322@mournblade.imrryr.org>
References: <cb7c3f52-a798-c1a5-2d69-6a56a89a03c3@htt-consult.com>
 <20170829232533.GL3322@mournblade.imrryr.org>
 <222e638f-aa34-1781-eea3-83dfd5bc8011@htt-consult.com>
 <20170830045927.GN3322@mournblade.imrryr.org>
Message-ID: <ed4ec87d-c8e5-d016-a891-1dd14510e83a@htt-consult.com>

Viktor,

On 08/30/2017 12:59 AM, Viktor Dukhovni wrote:
> On Wed, Aug 30, 2017 at 12:17:09AM -0400, Robert Moskowitz wrote:
>
>> So back to openssl ca and deal with no way to directly create a DER
>> formatted cert.
>>
>> Definitely a deficiency.
> Not really a deficiency, as the certificates in question need to
> be squirreled away in PEM format in the CA's "certs/" directory
> (compatibility with longstanding behaviour), and are much more
> easily exported, via email etc., in PEM format.
>
> It is trivial to convert a PEM certificate to DER.  Mind you,
> if I wanted a specialized CA, I'd go with the C API, where
> you can do *exactly* what you want:
>
>    * Store metadata in a SQL database.
>    * Read keys directly from PKCS8
>    * Write certs directly in DER form
>    * ...
>
> The openssl ca(1) program is to some extent just a demo, that meets
> only the simplest needs.  Perhaps you were looking for a turnkey
> CLI, but you have a specialized new use-case, and it is not entirely
> surprising that it is not directly supported.
>
> Patches to support missing features that might be of use to others
> are welcome.  The software evolves best through community participation.

I am not a coder.  In fact I pretty much stopped writing code in the 
'80s.  I DID some programming in B on Honeywells.  The only place where 
B escaped Bell Labs.  I never got to C; moved on to other IT support 
work, then to coding standards in English...

I have some limited scripting skills.

So as much as would like to contribute code, with maybe 2 years to 
retirement, I am not going to pick it up.  But who knows, maybe I will 
take a C programming course as part of my retirement activities.

I kind-of slept on this issue. I know that I can convert a PEM cert to 
DER, but I have been thinking about 'what of the other portions, like 
the keypair file?'  I woke up a little clearer head, and realized, that 
a truly constrained device won't even bother with DER, but just store 
the raw keypair.  So doing the creation all PEM and converting what is 
needed as DER to DER may be a realistic approach.

thanks for your help on this.

Bob


From daniel.andrade at tecnico.ulisboa.pt  Wed Aug 30 12:21:20 2017
From: daniel.andrade at tecnico.ulisboa.pt (Daniel Andrade)
Date: Wed, 30 Aug 2017 13:21:20 +0100
Subject: [openssl-users] AES-CMAC digest with EVP
In-Reply-To: <31506e93-b6de-f7fa-6181-17d926c9c5fb@tecnico.ulisboa.pt>
References: <31506e93-b6de-f7fa-6181-17d926c9c5fb@tecnico.ulisboa.pt>
Message-ID: <cd051636-22b0-fa2a-4e9f-8dcba5048d2b@tecnico.ulisboa.pt>

Hello,

I have two buffers, one with a key and one with some data. The objective 
is to calculate the AES-CMAC of the data with this key. I managed to 
compute the AES-CMAC using type `EVP_aes_128_cbc()` with the low-level 
interface:

1. CMAC_CTX *ctx = CMAC_CTX_new()
2. CMAC_Init
3. CMAC_Update
4. CMAC_Final
5. CMAC_CTX_free

Can this be done with the high-level EVP interface?

The EVP_DigestSign* set of functions expects a type EVP_MD, but 
EVP_aes_128_cbc() is of type EVP_CIPHER.

Daniel

From rgm at htt-consult.com  Wed Aug 30 14:21:31 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Wed, 30 Aug 2017 10:21:31 -0400
Subject: [openssl-users] Internet Draft Guide to creating an EDSA PKI
Message-ID: <151765c0-abea-814d-4565-7e3aaf099b8d@htt-consult.com>

I want to thank people here for their help.  I welcome you to look at 
the 1st cut of my work, I welcome comments.

I have to 'keep my fingers off of it' for a bit.  Start on the CRL and 
OCSP parts in a week or so.

Bob


-------- Forwarded Message --------
Subject: 	New Version Notification for draft-moskowitz-ecdsa-pki-00.txt
Date: 	Wed, 30 Aug 2017 06:53:03 -0700
From: 	internet-drafts at ietf.org
To: 	Robert Moskowitz <rgm at labs.htt-consult.com>, Liang Xia 
<frank.xialiang at huawei.com>, Henk Birkholz 
<henk.birkholz at sit.fraunhofer.de>, Liang Xia <Frank.xialiang at huawei.com>



A new version of I-D, draft-moskowitz-ecdsa-pki-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name:		draft-moskowitz-ecdsa-pki
Revision:	00
Title:		Guide for building an ECC pki
Document date:	2017-08-30
Group:		Individual Submission
Pages:		26
URL:            https://www.ietf.org/internet-drafts/draft-moskowitz-ecdsa-pki-00.txt
Status:         https://datatracker.ietf.org/doc/draft-moskowitz-ecdsa-pki/
Htmlized:       https://tools.ietf.org/html/draft-moskowitz-ecdsa-pki-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-moskowitz-ecdsa-pki-00


Abstract:
    This memo provides a guide for building a PKI (Public Key
    Infrastructure) using openSSL.  All certificates in this guide are
    ECDSA, P-256, with SHA256 certificates.  Along with common End Entity
    certificates, this guide provides instructions for creating IEEE
    802.1AR [IEEE.802.1AR_2009] iDevID Secure Device certificates.

                                                                                   


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170830/8623cf2b/attachment.html>

From openssl-users at dukhovni.org  Wed Aug 30 14:33:52 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 30 Aug 2017 14:33:52 +0000
Subject: [openssl-users] Another problem with openssl x509 -req --
 default_enddate
In-Reply-To: <ed4ec87d-c8e5-d016-a891-1dd14510e83a@htt-consult.com>
References: <cb7c3f52-a798-c1a5-2d69-6a56a89a03c3@htt-consult.com>
 <20170829232533.GL3322@mournblade.imrryr.org>
 <222e638f-aa34-1781-eea3-83dfd5bc8011@htt-consult.com>
 <20170830045927.GN3322@mournblade.imrryr.org>
 <ed4ec87d-c8e5-d016-a891-1dd14510e83a@htt-consult.com>
Message-ID: <20170830143351.GO3322@mournblade.imrryr.org>

On Wed, Aug 30, 2017 at 06:03:03AM -0400, Robert Moskowitz wrote:

> I woke up a little clearer head, and realized, that a truly
> constrained device won't even bother with DER, but just store the raw
> keypair.

FWIW, Apple's boot firmware stores the signature key as the raw
RSA key bits in little-endian form for efficient computation on
Intel CPUs.  No PEM or ASN.1 in sight.

Similarly, there's no ASN.1 in the DNSSEC DNSKEY RDATA format.
For RSA just the key and exponent octets:

    $ echo $(dig +short +nosplit -t dnskey . | grep -w 256 | awk '{print $NF}' | openssl base64 -A -d | hexdump -ve '/1 "%02x"')
    030100018bf1ad038eba329d673fb7ecffa82f897b7b7e7fd1d887fe66484c68e5a787fcd591902b8d8737149f92249a8629cf477b746108630b7f77357e13a2b4a24c9cbbe9305675d34e902fc8686a9c6f87ab53e9d0ef99362dfd2822903ba930a4dd4933601aa12831c702bd94762b44eee14b0dca17e2704b0a8687e45b5fc6152ac93951bb44415c012e28efab3914c53f45e0039be5cd5997b700a46fd1bc1a49c7b8ed63540c2edecc8f4551c4ac86da5ecd7e8da86f5962fe0e8e3077e940f932f7fa9524fb32930f69dcabb65b24165d768f53ecf663be7b56254cc81c83166511408e98be57ba60874a352985d980351b880d6cf682c02f528b49d9a82183

The "03" is the exponent length (limited to 255 octets), the "10
00 01" is the usual F_4 (65537) exponent, and the remaining 512
nibbles are the RSA modulus.

So indeed, you'd not be the first to consider a special-purpose
concise format.  It is somewhat surprising that the applications
you're considering use X.509 certificates at all, rather than just
raw public keys.  With expiration times in the year "9999", the
extra bloat of certificates is perhaps just useless baggage.
Admittedly, I don't know how the security model in question relates
to the real-world constraints of the supply chain, who gets to sign
certificates for devices allowed to participate, and whether a
certificateless public key database might have been a realistic
option.

-- 
	Viktor.

From rgm at htt-consult.com  Wed Aug 30 15:57:08 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Wed, 30 Aug 2017 11:57:08 -0400
Subject: [openssl-users] Another problem with openssl x509 -req --
 default_enddate
In-Reply-To: <20170830143351.GO3322@mournblade.imrryr.org>
References: <cb7c3f52-a798-c1a5-2d69-6a56a89a03c3@htt-consult.com>
 <20170829232533.GL3322@mournblade.imrryr.org>
 <222e638f-aa34-1781-eea3-83dfd5bc8011@htt-consult.com>
 <20170830045927.GN3322@mournblade.imrryr.org>
 <ed4ec87d-c8e5-d016-a891-1dd14510e83a@htt-consult.com>
 <20170830143351.GO3322@mournblade.imrryr.org>
Message-ID: <6a725df5-0ec9-e45d-e4d4-eb53ff34c7cc@htt-consult.com>



On 08/30/2017 10:33 AM, Viktor Dukhovni wrote:
> On Wed, Aug 30, 2017 at 06:03:03AM -0400, Robert Moskowitz wrote:
>
>> I woke up a little clearer head, and realized, that a truly
>> constrained device won't even bother with DER, but just store the raw
>> keypair.
> FWIW, Apple's boot firmware stores the signature key as the raw
> RSA key bits in little-endian form for efficient computation on
> Intel CPUs.  No PEM or ASN.1 in sight.
>
> Similarly, there's no ASN.1 in the DNSSEC DNSKEY RDATA format.
> For RSA just the key and exponent octets:
>
>      $ echo $(dig +short +nosplit -t dnskey . | grep -w 256 | awk '{print $NF}' | openssl base64 -A -d | hexdump -ve '/1 "%02x"')
>      030100018bf1ad038eba329d673fb7ecffa82f897b7b7e7fd1d887fe66484c68e5a787fcd591902b8d8737149f92249a8629cf477b746108630b7f77357e13a2b4a24c9cbbe9305675d34e902fc8686a9c6f87ab53e9d0ef99362dfd2822903ba930a4dd4933601aa12831c702bd94762b44eee14b0dca17e2704b0a8687e45b5fc6152ac93951bb44415c012e28efab3914c53f45e0039be5cd5997b700a46fd1bc1a49c7b8ed63540c2edecc8f4551c4ac86da5ecd7e8da86f5962fe0e8e3077e940f932f7fa9524fb32930f69dcabb65b24165d768f53ecf663be7b56254cc81c83166511408e98be57ba60874a352985d980351b880d6cf682c02f528b49d9a82183
>
> The "03" is the exponent length (limited to 255 octets), the "10
> 00 01" is the usual F_4 (65537) exponent, and the remaining 512
> nibbles are the RSA modulus.
>
> So indeed, you'd not be the first to consider a special-purpose
> concise format.  It is somewhat surprising that the applications
> you're considering use X.509 certificates at all, rather than just
> raw public keys.  With expiration times in the year "9999", the
> extra bloat of certificates is perhaps just useless baggage.
> Admittedly, I don't know how the security model in question relates
> to the real-world constraints of the supply chain, who gets to sign
> certificates for devices allowed to participate, and whether a
> certificateless public key database might have been a realistic
> option.

I am the author of HIP (rfc 7401) and to a large extent, raw public keys 
for Identity.  I started this work in January '99, before most of the 
current stuff using raw keys came around.  I know that Apple parallel 
developed much of their work.  Stewart Cheshire has said that if he had 
found the time to read HIP, he would have used it for the call home 
function.  And I know all about DNSKEY, as a few years into HIP, we 
chose to use the DNSKEY format in the HI parameter payload, dropping our 
own format.

I also worked with Sigma Design on Zwave 2.0 which uses raw EC25519 keys.

But not everyone agrees with me on raw keys, and I do recognize the need 
of 3rd party identity assertions.  And this is, to a large measure, what 
IEEE 802.1AR-2009 Secure Identities offers.  But 1AR is only about the 
Identities, and not how to manage and bootstrap from iDevIDs to 
lDevIDs.  The IETF workgroup, ANIMA is working on this.  And Michael 
Richardson, who just joined this list, is one of the authors on those 
documents.  Oh, and NETCONF is working on it for network infrastructure 
devices with their 'zero touch' drafts. Of course those are NOT 
constrained devices...

Getting 802.1AR-2009 does require an IEEE login, but is free thanks to 
us IEEE 802 meeting attendees paying a bit extra to IEEE to make our 
docs free 6 months after publication.  Of course the addendum that is in 
final prep is NOT available free (to non-attendees), but the changes do 
not impact this discussion.



From mcr at sandelman.ca  Thu Aug 31 01:12:37 2017
From: mcr at sandelman.ca (Michael Richardson)
Date: Wed, 30 Aug 2017 21:12:37 -0400
Subject: [openssl-users] Another problem with openssl x509 -req --
	default_enddate
In-Reply-To: <20170830045927.GN3322@mournblade.imrryr.org>
References: <cb7c3f52-a798-c1a5-2d69-6a56a89a03c3@htt-consult.com>
 <20170829232533.GL3322@mournblade.imrryr.org>
 <222e638f-aa34-1781-eea3-83dfd5bc8011@htt-consult.com>
 <20170830045927.GN3322@mournblade.imrryr.org>
Message-ID: <3980.1504141957@obiwan.sandelman.ca>

Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
    > The openssl ca(1) program is to some extent just a demo, that meets

I'd actually suggest that it be either:
  1) ripped out of the source code, and turned into a seperate "application".
  2) pushed internal to the source code (not installed), and used only for
     running regression tests.

The two actions are not mutually exclusive!

There are probably a dozen commands to which such an approach would help
improve both the APIs, and make the code easier for (others) to innovate
with.

    > only the simplest needs.  Perhaps you were looking for a turnkey
    > CLI, but you have a specialized new use-case, and it is not entirely
    > surprising that it is not directly supported.

+10.

--
]               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 mcr at sandelman.ca  Thu Aug 31 01:22:54 2017
From: mcr at sandelman.ca (Michael Richardson)
Date: Wed, 30 Aug 2017 21:22:54 -0400
Subject: [openssl-users] Another problem with openssl x509 -req --
	default_enddate
In-Reply-To: <20170830143351.GO3322@mournblade.imrryr.org>
References: <cb7c3f52-a798-c1a5-2d69-6a56a89a03c3@htt-consult.com>
 <20170829232533.GL3322@mournblade.imrryr.org>
 <222e638f-aa34-1781-eea3-83dfd5bc8011@htt-consult.com>
 <20170830045927.GN3322@mournblade.imrryr.org>
 <ed4ec87d-c8e5-d016-a891-1dd14510e83a@htt-consult.com>
 <20170830143351.GO3322@mournblade.imrryr.org>
Message-ID: <6444.1504142574@obiwan.sandelman.ca>


Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
    > So indeed, you'd not be the first to consider a special-purpose
    > concise format.  It is somewhat surprising that the applications
    > you're considering use X.509 certificates at all, rather than just
    > raw public keys.  With expiration times in the year "9999", the
    > extra bloat of certificates is perhaps just useless baggage.

We are leveraging the political unity behind 802.1AR (which defines the
IDevID). As a profile it's pretty thin, relying extensively (but
appropriately) on IETF documents,  yet still leaving a bunch of stuff rather
under-specified.

While devices possessing IDevIDs don't need all the cert chain stuff,
the network infrastructure validating them may need it.  Given supply chain
complexity, it could well be in the IDevID that linking back to the
manufacturer requires a chain of certificates.  (My KitchenAid dishwasher is
made and serviced by Whirlpool, but was sold to me by Sears.  I'd expect
Sears' certificate to be in the electronic invoice)

    > Admittedly, I don't know how the security model in question relates
    > to the real-world constraints of the supply chain, who gets to sign
    > certificates for devices allowed to participate, and whether a
    > certificateless public key database might have been a realistic
    > option.

No, it's just not.
In the 6tisch (constrained) version of BRSKI, which is at:
   https://bitbucket.org/6tisch/draft-richardson-6tisch-dtsecurity-secure-join/src/b84347549d469806067cf60b323444f97a98ee83/dtsecurity-zerotouch-join-00.txt?at=master&fileviewer=file-view-default
until the rename of the document is approved.  Section 2.2 explains that the
constrained device will have/need only the raw public key of the manufacturer, and
will treat the IDevID as a blob.  The private key should be stored in
whatever form is most convenient for computation, like the Apple boot loader
does.   Still, some people will have TPMs with complicated interfaces.

--
]               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: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170830/c733bf52/attachment.sig>

From mcr at sandelman.ca  Thu Aug 31 01:33:17 2017
From: mcr at sandelman.ca (Michael Richardson)
Date: Wed, 30 Aug 2017 21:33:17 -0400
Subject: [openssl-users] Another problem with openssl x509 -req --
	default_enddate
In-Reply-To: <20170830143351.GO3322@mournblade.imrryr.org>
References: <cb7c3f52-a798-c1a5-2d69-6a56a89a03c3@htt-consult.com>
 <20170829232533.GL3322@mournblade.imrryr.org>
 <222e638f-aa34-1781-eea3-83dfd5bc8011@htt-consult.com>
 <20170830045927.GN3322@mournblade.imrryr.org>
 <ed4ec87d-c8e5-d016-a891-1dd14510e83a@htt-consult.com>
 <20170830143351.GO3322@mournblade.imrryr.org>
Message-ID: <8784.1504143197@obiwan.sandelman.ca>


Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
    > So indeed, you'd not be the first to consider a special-purpose
    > concise format.  It is somewhat surprising that the applications
    > you're considering use X.509 certificates at all, rather than just

I meant to add in my previous email, that the reason to use the PKIX
containers is because we need the identifiers for algorithms and hashes, and
the like so that we can have algorithm agility going forward.

Of course, we could get that from some other format: OpenPGP for instance.
Alas, none are very popular in the greater world.  Maybe CWT will win out
where PGP (for keys and signatures) did not... but I don't think the industry
outside of the IETF is ready for that yet. (The IETF is not even ready...)

--
]               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: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170830/3cc71666/attachment.sig>

From rgm at htt-consult.com  Thu Aug 31 02:43:13 2017
From: rgm at htt-consult.com (Robert Moskowitz)
Date: Wed, 30 Aug 2017 22:43:13 -0400
Subject: [openssl-users] Another problem with openssl x509 -req --
 default_enddate
In-Reply-To: <6444.1504142574@obiwan.sandelman.ca>
References: <cb7c3f52-a798-c1a5-2d69-6a56a89a03c3@htt-consult.com>
 <20170829232533.GL3322@mournblade.imrryr.org>
 <222e638f-aa34-1781-eea3-83dfd5bc8011@htt-consult.com>
 <20170830045927.GN3322@mournblade.imrryr.org>
 <ed4ec87d-c8e5-d016-a891-1dd14510e83a@htt-consult.com>
 <20170830143351.GO3322@mournblade.imrryr.org>
 <6444.1504142574@obiwan.sandelman.ca>
Message-ID: <eb9a736b-dc3e-8b8c-ee20-e935bd5f1e18@htt-consult.com>



On 08/30/2017 09:22 PM, Michael Richardson wrote:
> Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
>      > So indeed, you'd not be the first to consider a special-purpose
>      > concise format.  It is somewhat surprising that the applications
>      > you're considering use X.509 certificates at all, rather than just
>      > raw public keys.  With expiration times in the year "9999", the
>      > extra bloat of certificates is perhaps just useless baggage.
>
> We are leveraging the political unity behind 802.1AR (which defines the
> IDevID). As a profile it's pretty thin, relying extensively (but
> appropriately) on IETF documents,  yet still leaving a bunch of stuff rather
> under-specified.

By intent.

> While devices possessing IDevIDs don't need all the cert chain stuff,
> the network infrastructure validating them may need it.  Given supply chain
> complexity, it could well be in the IDevID that linking back to the
> manufacturer requires a chain of certificates.  (My KitchenAid dishwasher is
> made and serviced by Whirlpool, but was sold to me by Sears.  I'd expect
> Sears' certificate to be in the electronic invoice)

Actually there was extensive discussion that this would be LDevIDs. The 
manufacturer is KitchenAId.  Their IDevID.  So that Whirlpool can 
service it, a Whirlpool LDevID.  We could not come to any consistent 
scenario on Sears as the Merchant.  No real difference than Target 
selling a TracPhone.  What interaction do they have after the sale?

Or there is NO KitchenAid Identity in the machine.  They were just a job 
shop for Whirlpool so only a Whirlpool IDevID...

You missed out on all the fun discussions, Michael.  You just get to 
pick up the pieces!

The real drivers, at the time was Cisco and Aruba for their phones...

>      > Admittedly, I don't know how the security model in question relates
>      > to the real-world constraints of the supply chain, who gets to sign
>      > certificates for devices allowed to participate, and whether a
>      > certificateless public key database might have been a realistic
>      > option.
>
> No, it's just not.
> In the 6tisch (constrained) version of BRSKI, which is at:
>     https://bitbucket.org/6tisch/draft-richardson-6tisch-dtsecurity-secure-join/src/b84347549d469806067cf60b323444f97a98ee83/dtsecurity-zerotouch-join-00.txt?at=master&fileviewer=file-view-default
> until the rename of the document is approved.  Section 2.2 explains that the
> constrained device will have/need only the raw public key of the manufacturer, and
> will treat the IDevID as a blob.  The private key should be stored in
> whatever form is most convenient for computation, like the Apple boot loader
> does.   Still, some people will have TPMs with complicated interfaces.

Lots of groups taking the basics and putting them together in a way that 
SHOULD work for them...

Bob


From bhat.jayalakshmi at gmail.com  Thu Aug 31 05:55:16 2017
From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat)
Date: Thu, 31 Aug 2017 11:25:16 +0530
Subject: [openssl-users] how to compile out selected ciphers
Message-ID: <CALq8RvJrMZ=zmymQ1Z1HiHDDWwdCWMKjZL5whjGrET=Jw5asgQ@mail.gmail.com>

Hi All,

I am trying to build openssl. As part of that I want to remove some ciphers
like md4, rc5 etc.

I tried ./config no-md5, no-rc5 and ./Configure no-md5, no-rc5. In both the
case MD4 and RC5 directories are still getting compiled.

Please can you let me know what could be going wrong.

Regards
Jaya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170831/8564449a/attachment.html>

From levitte at openssl.org  Thu Aug 31 09:13:13 2017
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 31 Aug 2017 11:13:13 +0200 (CEST)
Subject: [openssl-users] [openssl-dev] how to compile out selected
	ciphers
In-Reply-To: <CALq8RvJrMZ=zmymQ1Z1HiHDDWwdCWMKjZL5whjGrET=Jw5asgQ@mail.gmail.com>
References: <CALq8RvJrMZ=zmymQ1Z1HiHDDWwdCWMKjZL5whjGrET=Jw5asgQ@mail.gmail.com>
Message-ID: <20170831.111313.259508043850633407.levitte@openssl.org>

In message <CALq8RvJrMZ=zmymQ1Z1HiHDDWwdCWMKjZL5whjGrET=Jw5asgQ at mail.gmail.com> on Thu, 31 Aug 2017 11:25:16 +0530, Jayalakshmi bhat <bhat.jayalakshmi at gmail.com> said:

bhat.jayalakshmi> Hi All,
bhat.jayalakshmi> 
bhat.jayalakshmi> I am trying to build openssl. As part of that I want
bhat.jayalakshmi> to remove some ciphers like md4, rc5 etc.
bhat.jayalakshmi> 
bhat.jayalakshmi> I tried ./config no-md5, no-rc5 and ./Configure
bhat.jayalakshmi> no-md5, no-rc5. In both the case MD4 and RC5 
bhat.jayalakshmi> directories are still getting compiled.
bhat.jayalakshmi> 
bhat.jayalakshmi> Please can you let me know what could be going wrong.

Your configuration line says 'no-md5', which is an attempt to remove
MD5, not MD4.  Your config line should be this:

    ./config no-md4 no-rc5

It's possible, though, that you really meant to remove MD5...
unfortunately, it's such an integral part of most SSL/TLS protocol
versions that we cannot for the moment allow it to be disabled.
That's the issue you're hitting.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From steve at openssl.org  Thu Aug 31 12:27:46 2017
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 31 Aug 2017 12:27:46 +0000
Subject: [openssl-users] AES-CMAC digest with EVP
In-Reply-To: <cd051636-22b0-fa2a-4e9f-8dcba5048d2b@tecnico.ulisboa.pt>
References: <31506e93-b6de-f7fa-6181-17d926c9c5fb@tecnico.ulisboa.pt>
 <cd051636-22b0-fa2a-4e9f-8dcba5048d2b@tecnico.ulisboa.pt>
Message-ID: <20170831122746.GA10947@openssl.org>

On Wed, Aug 30, 2017, Daniel Andrade wrote:

> Hello,
> 
> I have two buffers, one with a key and one with some data. The
> objective is to calculate the AES-CMAC of the data with this key. I
> managed to compute the AES-CMAC using type `EVP_aes_128_cbc()` with
> the low-level interface:
> 
> 1. CMAC_CTX *ctx = CMAC_CTX_new()
> 2. CMAC_Init
> 3. CMAC_Update
> 4. CMAC_Final
> 5. CMAC_CTX_free
> 
> Can this be done with the high-level EVP interface?
> 
> The EVP_DigestSign* set of functions expects a type EVP_MD, but
> EVP_aes_128_cbc() is of type EVP_CIPHER.
> 

Yes it is possible. One way is to create a new key using
EVP_PKEY_new_mac_key() with type EVP_PKEY_CMAC. You pass that key to
EVP_DigestSign*() with the digest set to NULL. You then have to set the cipher
to use with the EVP_PKEY_CTRL_CIPHER ctrl (unfortunately there is currently no
macro for this).

Then calling EVP_DigestSignUpdate() and EVP_DigestSignaFinal() should work in
the usual way and produce the correct CMAC.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From rsalz at akamai.com  Thu Aug 31 12:43:56 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 31 Aug 2017 12:43:56 +0000
Subject: [openssl-users] how to compile out selected ciphers
In-Reply-To: <CALq8RvJrMZ=zmymQ1Z1HiHDDWwdCWMKjZL5whjGrET=Jw5asgQ@mail.gmail.com>
References: <CALq8RvJrMZ=zmymQ1Z1HiHDDWwdCWMKjZL5whjGrET=Jw5asgQ@mail.gmail.com>
Message-ID: <7919C15F-1D08-4537-A314-8412070EBBA0@akamai.com>

What version of openssl are you  building?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170831/2e3287ef/attachment-0001.html>