[no subject]

[jennifer Deborja]

https://mta.openssl.org/pipermail/openssl-users/attachments/20211109/b5cd5f1e/attachment-0001.html

[no subject]

[Jean Sweeny via openssl-users]

[no subject]

[Jean Sweeny via openssl-users]

[no subject]

[Jean Sweeny via openssl-users]

[no subject]

[Antonio Santagiuliana]

Hello
I was wondering how to migrate to a provider for Openssl 3.0 an engine for
openssl 1.0.2 that was simply defining on an RSA_METHOD structure the
method for modular exponentiation for RSA and getting call parameters from
RSA_get_ex_data(), in order then to use an hw accelerator.
Other methods were not re-defined .
What should I do for making it a provider to run with Openssl 3.0? I cannot
find this in the list of possible operations.
Thank you

Antonio

[no subject]

[Shivakumar Poojari]

Hi
#define of BIOerr and BUFerr  is deprecated in openssl3.0

# ifndef OPENSSL_NO_DEPRECATED_3_0
 #define BIOerr(f, r) ERR_raise_data(ERR_LIB_BIO, (r), NULL)
 # define BUFerr(f, r) ERR_raise_data(ERR_LIB_BUF, (r), NULL)
#endif

The BIOerr and BUFerr are used in the code something like below

BIOerr(BIO_F_BIO_NEW_MEM_BUF, BIO_R_NULL_PARAMETER);
BIOerr(BIO_F_MEM_WRITE, BIO_R_NULL_PARAMETER);
BIOerr(BIO_F_MEM_WRITE, BIO_R_WRITE_TO_READ_ONLY_BIO);
BIOerr(BIO_F_MEM_WRITE, BIO_R_NULL_PARAMETER);

 BUFerr(BUF_F_BUF_MEM_NEW, ERR_R_MALLOC_FAILURE);
 BUFerr(BUF_F_BUF_MEM_GROW, ERR_R_MALLOC_FAILURE);
 BUFerr(BUF_F_BUF_MEM_GROW_CLEAN, ERR_R_MALLOC_FAILURE);


Now im trying to replace with

void ERR_raise(int lib, int reason);

But how do i manage "f" paramater  which is highlighted in #define

please suggest,

thanks,
shiva kumar



Notice: This e-mail together with any attachments may contain information of 
Ribbon Communications Inc. and its Affiliates that is confidential and/or 
proprietary for the sole use of the intended recipient. Any review, disclosure, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please notify the 
sender immediately and then delete all copies, including any attachments.

Re: Parsing subject/issuer strings in X.509

[Philip Prindeville]

Yeah, agreed, although I'd like the parser to work with the output of "openssl 
x509 ... -subject", i.e. RFC-4514 format, which is "CN=name, O=Acme 
Corporation, C=US" ... etc.



> On Jul 23, 2021, at 12:57 AM, David von Oheimb  wrote:
> 
> What I use is
> 
> X509_NAME *nname = parse_name(string, MBSTRING_ASC, 1, desc);
> 
> which is not an official API function but defined in apps/lib/apps.c:
> 
> /*
>  * name is expected to be in the format /type0=value0/type1=value1/type2=...
>  * where + can be used instead of / to form multi-valued RDNs if canmulti
>  * and characters may be escaped by \
>  */
> X509_NAME *parse_name(const char *cp, int chtype, int canmulti, const char 
> *desc)
> 
> Would be good to have such a function as part of the X.509 API.
> 
> David
> 
> On 23.07.21 07:49, Viktor Dukhovni wrote:
>>> On 22 Jul 2021, at 9:29 pm, Philip Prindeville 
>>> 
>>>  wrote:
>>> 
>>> I'm wondering what the function is that takes a string and returns 
>>> X509_NAME with the attribute/value pairs of the parsed DN.
>>> 
>> There is no such function in general, since the are many potential
>> string forms of X.509 names, not all of which are unambiguously
>> machine readable.
>> 
>> There are various functions for augmenting a partially built name
>> with an attribute-value pair, but the parsing of a string a list
>> of such attribute-value pairs is up to you. :-(
>> 
>> 

Re: Parsing subject/issuer strings in X.509

[Philip Prindeville]

> On Jul 23, 2021, at 8:52 AM, Viktor Dukhovni  
> wrote:
> 
>> On 23 Jul 2021, at 2:57 am, David von Oheimb  wrote:
>> 
>> What I use is
>> 
>>X509_NAME *nname = parse_name(string, MBSTRING_ASC, 1, desc);
>> 
>> which is not an official API function but defined in apps/lib/apps.c:
>> 
>> /*
>> * name is expected to be in the format /type0=value0/type1=value1/type2=...
>> * where + can be used instead of / to form multi-valued RDNs if canmulti
>> * and characters may be escaped by \
>> */
>> X509_NAME *parse_name(const char *cp, int chtype, int canmulti, const char 
>> *desc)
>> 
>> Would be good to have such a function as part of the X.509 API.
> 
> Note that the "/"-separated form is not the output format of the issuer or
> subject names in X509_NAME_oneline(3), x509(1), ...  So a public API for
> that format may not be a good idea.  Perhaps there could be parsers for
> the "rfc2253", "rfc2254" and "oneline" formats (or a single parser with
> flags to select the format).
> 
> -- 
>   Viktor.
> 


And "rfc4514"... yeah, that would work too.

-Philip

Re: Parsing subject/issuer strings in X.509

[Philip Prindeville]

Yeah, agreed, although I'd like the parser to work with the output of "openssl 
x509 ... -subject", i.e. RFC-4514 format, which is "CN=name, O=Acme 
Corporation, C=US" ... etc.



> On Jul 23, 2021, at 12:57 AM, David von Oheimb  wrote:
> 
> What I use is
> 
> X509_NAME *nname = parse_name(string, MBSTRING_ASC, 1, desc);
> 
> which is not an official API function but defined in apps/lib/apps.c:
> 
> /*
>  * name is expected to be in the format /type0=value0/type1=value1/type2=...
>  * where + can be used instead of / to form multi-valued RDNs if canmulti
>  * and characters may be escaped by \
>  */
> X509_NAME *parse_name(const char *cp, int chtype, int canmulti, const char 
> *desc)
> 
> Would be good to have such a function as part of the X.509 API.
> 
> David
> 
> On 23.07.21 07:49, Viktor Dukhovni wrote:
>>> On 22 Jul 2021, at 9:29 pm, Philip Prindeville 
>>>  
>>> <mailto:philipp_s...@redfish-solutions.com> wrote:
>>> 
>>> I'm wondering what the function is that takes a string and returns 
>>> X509_NAME with the attribute/value pairs of the parsed DN.
>> There is no such function in general, since the are many potential
>> string forms of X.509 names, not all of which are unambiguously
>> machine readable.
>> 
>> There are various functions for augmenting a partially built name
>> with an attribute-value pair, but the parsing of a string a list
>> of such attribute-value pairs is up to you. :-(
>> 

Re: Parsing subject/issuer strings in X.509

[Viktor Dukhovni]

> On 23 Jul 2021, at 2:57 am, David von Oheimb  wrote:
> 
> What I use is
> 
> X509_NAME *nname = parse_name(string, MBSTRING_ASC, 1, desc);
> 
> which is not an official API function but defined in apps/lib/apps.c:
> 
> /*
>  * name is expected to be in the format /type0=value0/type1=value1/type2=...
>  * where + can be used instead of / to form multi-valued RDNs if canmulti
>  * and characters may be escaped by \
>  */
> X509_NAME *parse_name(const char *cp, int chtype, int canmulti, const char 
> *desc)
> 
> Would be good to have such a function as part of the X.509 API.

Note that the "/"-separated form is not the output format of the issuer or
subject names in X509_NAME_oneline(3), x509(1), ...  So a public API for
that format may not be a good idea.  Perhaps there could be parsers for
the "rfc2253", "rfc2254" and "oneline" formats (or a single parser with
flags to select the format).

-- 
Viktor.

Re: Parsing subject/issuer strings in X.509

[David von Oheimb]

What I use is

    X509_NAME *nname = parse_name(string, MBSTRING_ASC, 1, desc);

which is not an official API function but defined in apps/lib/apps.c:

/*
 * name is expected to be in the format /type0=value0/type1=value1/type2=...
 * where + can be used instead of / to form multi-valued RDNs if canmulti
 * and characters may be escaped by \
 */
X509_NAME *parse_name(const char *cp, int chtype, int canmulti, const
char *desc)

Would be good to have such a function as part of the X.509 API.

    David

On 23.07.21 07:49, Viktor Dukhovni wrote:
>> On 22 Jul 2021, at 9:29 pm, Philip Prindeville 
>>  wrote:
>>
>> I'm wondering what the function is that takes a string and returns X509_NAME 
>> with the attribute/value pairs of the parsed DN.
> There is no such function in general, since the are many potential
> string forms of X.509 names, not all of which are unambiguously
> machine readable.
>
> There are various functions for augmenting a partially built name
> with an attribute-value pair, but the parsing of a string a list
> of such attribute-value pairs is up to you. :-(
>

Re: Parsing subject/issuer strings in X.509

[Viktor Dukhovni]

> On 22 Jul 2021, at 9:29 pm, Philip Prindeville 
>  wrote:
> 
> I'm wondering what the function is that takes a string and returns X509_NAME 
> with the attribute/value pairs of the parsed DN.

There is no such function in general, since the are many potential
string forms of X.509 names, not all of which are unambiguously
machine readable.

There are various functions for augmenting a partially built name
with an attribute-value pair, but the parsing of a string a list
of such attribute-value pairs is up to you. :-(

-- 
Viktor.

Parsing subject/issuer strings in X.509

[Philip Prindeville]

Hi,

I'm wondering what the function is that takes a string and returns X509_NAME 
with the attribute/value pairs of the parsed DN.

Thanks,

-Philip

[no subject]

[Nagarjun J]

Hi,

I am building Nginx application with openssl-3.0.0, i have added below code
in main function of nginx application to load fips provider,

  OSSL_PROVIDER *fips;
   OSSL_PROVIDER *base;

   fips = OSSL_PROVIDER_load(NULL, "fips");
   if (fips == NULL) {
   printf("Failed to load FIPS provider\n");
   exit(EXIT_FAILURE);
   }
   base = OSSL_PROVIDER_load(NULL, "base");
   if (base == NULL) {
   OSSL_PROVIDER_unload(fips);
   printf("Failed to load base provider\n");
   exit(EXIT_FAILURE);
   }

but when I start the application it's giving *Failed to load FIPS
provider *error
, with initial debugging I found SELF_TEST_post is failing in below
code st->module_checksum_data in null and returning  error.

if (st == NULL
|| st->module_checksum_data == NULL) {
ERR_raise(ERR_LIB_PROV, PROV_R_MISSING_CONFIG_DATA);
goto end;
}

Anything I am missing here?

Regards,
Nagarjun

[no subject]

[Nagarjun J]

Hi,

How to verify if the application is using fips provider from openssl-3.0.0
( similar to fips_mode() api in openssl-fips-2.0.16) and  does fips
provider do run time check and through error if application using non fips
ciphers.

Regards,
Nagarjun

Re: Multi-valued RDN in Subject Alternative Name extension

[Williams, Gareth]

On Sat, 20 Jun 2020 at 10:21, Michael Ströder  wrote:
>
> On 6/18/20 9:12 AM, Williams, Gareth wrote:
> > I can successfully add a multi-value RDN to the Subject of a
> > certificate request using the + format in the config file:
> > [..]
> > However, if I add a SAN to the request:
> > [..]
> > the resulting request has them as separate RDNs (as if the + is not
> > noticed).
> Probably not the answer you were expecting:
>
> In general multi-valued RDNs are a can of worms. Even if you solve this
> particular step within OpenSSL you might run into many more issues with
> other components using the certs.
>
> => I'd strongly recommend to avoid multi-valued RDNs.
>
> Sometimes people want to make the subject DN unique by adding attributes
> to the RDN. But those attribute values would have to be unique in a
> certain scope anyway to achieve that. C (country ISO code) does not look
> like a good candiate for that. Or did you just use that as demo example?
>

Thanks for the response.

I chose the country attribute simply as an example.

I stumbled upon this while testing something else, so thought I’d ask
the question.  Your pragmatic answer is fine by me as I had no real
use case – just a matter of curiosity.

Thanks again,

Gareth

Re: Multi-valued RDN in Subject Alternative Name extension

[Michael Ströder]

On 6/18/20 9:12 AM, Williams, Gareth wrote:
> I can successfully add a multi-value RDN to the Subject of a
> certificate request using the + format in the config file:
> [..]
> However, if I add a SAN to the request:
> [..]
> the resulting request has them as separate RDNs (as if the + is not
> noticed).
Probably not the answer you were expecting:

In general multi-valued RDNs are a can of worms. Even if you solve this
particular step within OpenSSL you might run into many more issues with
other components using the certs.

=> I'd strongly recommend to avoid multi-valued RDNs.

Sometimes people want to make the subject DN unique by adding attributes
to the RDN. But those attribute values would have to be unique in a
certain scope anyway to achieve that. C (country ISO code) does not look
like a good candiate for that. Or did you just use that as demo example?

Ciao, Michael.

Multi-valued RDN in Subject Alternative Name extension

[Williams, Gareth]

I can successfully add a multi-value RDN to the Subject of a
certificate request using the + format in the config file:

distinguished_name = req_dn

[ req_dn ]
O=Acme
CN=Bloggs
+C=GB

However, if I add a SAN to the request:

subjectAltName = @alt_names

[ alt_names ]
DNS = www.example.com
dirName = req_dn

the resulting request has them as separate RDNs (as if the + is not noticed).

That is, the resulting subject field is: O = Acme, C = GB + CN = Test
While the resulting SAN extension is: DNS:www.example.com,
DirName:/O=Acme/C=GB/CN=Test

Should multi-value RDNs work in the SAN too?

Kind regards,

Gareth Williams

Re: Certificate subject match validation

[George-Theodor Serbana]

Yes, indeed I don't want to take into account the CN, only the SANs. Thanks
for the extra flag and all the clarifications!

Best regards,
Theodor


>
>
> > >  > For now I am using X509_VERIFY_PARAM_set1_host with
> SSL_CTX_set1_param to
> > >  > do this specific check.
> > >
> > >  That's the slightly less convenient legacy API from OpenSSL 1.0.2.
> > >  In 1.1.0 and later, you can use SSL_set1_host() (and in some
> > >  cases also SSL_add1_host()).
> > >
> > >  See the SSL_set1_host(3) manpage for details.
> >
> > Indeed I re-read the docs and it says that users should not assume that
> > hostnames are validated by default without explicitly calling the API, I
> > must've missed that bit and thank you for letting me know. I will shift
> > towards using the newer SSL_set1_host together with some flags (I don't
> > want any wildcards).
>
> If your needs are sufficiently narrow to rule out connecting to sites
> that use wildcard certificates, perhaps they're also narrow enough to
> rule out sites that don't have subjectAltNames, in which case the
> flags could be:
>
> So you'll call either of (here a NULL callback, set a non-null callback
> if appropriate):
>
> SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, NULL); /* Just once */
> SSL_set_verify(ssl, SSL_VERIFY_PEER, NULL); /* Per connection
> */
>
> followed by (per connection):
>
> SSL_set1_host(ssl, "www.example.org");
> SSL_set_hostflags(ssl, X509_CHECK_FLAG_NO_WILDCARDS
>      | X509_CHECK_FLAG_NEVER_CHECK_SUBJECT);
>
> which also insists on a DNS subject altname (the preferred way to
> authenticate DNS names), and never looks at any CN field in the subject
> DN.
>
> > Now just to be extra safe I'm still asking: will the VERIFY_PEER option
> > together with SSL_set1_host instruct OpenSSL to perform all possible
> checks
> > on the certificate presented by the server such that no security breach
> > remains at this level? Is there anything else that I should call or
> perform
> > manually?
>
> No, the above is enough.
>
> --
> Viktor.
>

Re: Certificate subject match validation

[Viktor Dukhovni]

On Sat, Mar 28, 2020 at 10:56:20PM +0200, George-Theodor Serbana wrote:

> >  > For now I am using X509_VERIFY_PARAM_set1_host with SSL_CTX_set1_param to
> >  > do this specific check.
> >  
> >  That's the slightly less convenient legacy API from OpenSSL 1.0.2.
> >  In 1.1.0 and later, you can use SSL_set1_host() (and in some
> >  cases also SSL_add1_host()).
> >  
> >  See the SSL_set1_host(3) manpage for details.
> 
> Indeed I re-read the docs and it says that users should not assume that
> hostnames are validated by default without explicitly calling the API, I
> must've missed that bit and thank you for letting me know. I will shift
> towards using the newer SSL_set1_host together with some flags (I don't
> want any wildcards).

If your needs are sufficiently narrow to rule out connecting to sites
that use wildcard certificates, perhaps they're also narrow enough to
rule out sites that don't have subjectAltNames, in which case the
flags could be:

So you'll call either of (here a NULL callback, set a non-null callback
if appropriate):

SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, NULL); /* Just once */
SSL_set_verify(ssl, SSL_VERIFY_PEER, NULL); /* Per connection */

followed by (per connection):

SSL_set1_host(ssl, "www.example.org");
SSL_set_hostflags(ssl, X509_CHECK_FLAG_NO_WILDCARDS
     | X509_CHECK_FLAG_NEVER_CHECK_SUBJECT);

which also insists on a DNS subject altname (the preferred way to
authenticate DNS names), and never looks at any CN field in the subject
DN.

> Now just to be extra safe I'm still asking: will the VERIFY_PEER option
> together with SSL_set1_host instruct OpenSSL to perform all possible checks
> on the certificate presented by the server such that no security breach
> remains at this level? Is there anything else that I should call or perform
> manually?

No, the above is enough.  

-- 
Viktor.

Re: Certificate subject match validation

[George-Theodor Serbana]

> I am writing a SSL/TLS client (using Boost.Beast but underlying it's using
> OpenSSL) and although I have set on the SSL context the 'verify_peer'
flag,
> there is no verification to prove the server presents an X509 which
> contains in the Subject Alternative Names the hostname of that server.
>
> As this is probably the dumbest type of attack someone could do (using a
> valid certificate with another domain name), I am thinking I'm doing
> something wrong. But from the documentation, I saw that using
"verify_peer"
> should perform all the verifications...

It verifies the trust chain.  To also verify the peer name, you need to
specify the peer name via:

SSL_set1_host()

> Now if not even this simple check is being done, how about expiration of
> the certificate, revocation status and other checks? Should they be
> performed manually as well?

No, that's what VERIFY_PEER is for.

> For now I am using X509_VERIFY_PARAM_set1_host with SSL_CTX_set1_param to
> do this specific check.

That's the slightly less convenient legacy API from OpenSSL 1.0.2.
In 1.1.0 and later, you can use SSL_set1_host() (and in some
cases also SSL_add1_host()).

See the SSL_set1_host(3) manpage for details.

---


Indeed I re-read the docs and it says that users should not assume that
hostnames are validated by default without explicitly calling the API, I
must've missed that bit and thank you for letting me know. I will shift
towards using the newer SSL_set1_host together with some flags (I don't
want any wildcards).

Now just to be extra safe I'm still asking: will the VERIFY_PEER option
together with SSL_set1_host instruct OpenSSL to perform all possible checks
on the certificate presented by the server such that no security breach
remains at this level? Is there anything else that I should call or perform
manually?

-- Theodor

Re: Certificate subject match validation

[Viktor Dukhovni]

On Fri, Mar 27, 2020 at 07:38:35PM +0200, George-Theodor Serbana wrote:

> I am writing a SSL/TLS client (using Boost.Beast but underlying it's using
> OpenSSL) and although I have set on the SSL context the 'verify_peer' flag,
> there is no verification to prove the server presents an X509 which
> contains in the Subject Alternative Names the hostname of that server.
> 
> As this is probably the dumbest type of attack someone could do (using a
> valid certificate with another domain name), I am thinking I'm doing
> something wrong. But from the documentation, I saw that using "verify_peer"
> should perform all the verifications...

It verifies the trust chain.  To also verify the peer name, you need to
specify the peer name via:

SSL_set1_host() 

> Now if not even this simple check is being done, how about expiration of
> the certificate, revocation status and other checks? Should they be
> performed manually as well?

No, that's what VERIFY_PEER is for.

> For now I am using X509_VERIFY_PARAM_set1_host with SSL_CTX_set1_param to
> do this specific check.

That's the slightly less convenient legacy API from OpenSSL 1.0.2.
In 1.1.0 and later, you can use SSL_set1_host() (and in some
cases also SSL_add1_host()).

See the SSL_set1_host(3) manpage for details.

-- 
Viktor.

Certificate subject match validation

[George-Theodor Serbana]

I am writing a SSL/TLS client (using Boost.Beast but underlying it's using
OpenSSL) and although I have set on the SSL context the 'verify_peer' flag,
there is no verification to prove the server presents an X509 which
contains in the Subject Alternative Names the hostname of that server.

As this is probably the dumbest type of attack someone could do (using a
valid certificate with another domain name), I am thinking I'm doing
something wrong. But from the documentation, I saw that using "verify_peer"
should perform all the verifications...

Now if not even this simple check is being done, how about expiration of
the certificate, revocation status and other checks? Should they be
performed manually as well?

For now I am using X509_VERIFY_PARAM_set1_host with SSL_CTX_set1_param to
do this specific check.

Best regards,
Theodor

[no subject]

[hamed salini]

[no subject]

[hamed salini]

[no subject]

[Abid Butt]

[no subject]

[hamed salini]

[no subject]

[Naveen Shivanna]

Hi,

After adding 'enable-sctp' compile option, OpenSSL (DTLS) can work with
SCTP as transport.

OpenSSL bss_dgram.c file includes the kernel /netinet/sctp.h.

We have our own custom SCTP implementation (also implements  custom BIO
METHODS, do not use the default methods), so we need to remove the
dependency of kernel sctp.h from bss_gram.c file. Our build environment do
not have the sctp.h and we are not supposed to install lksctp-tools.

Can we tailor the bss_gram.c with new compile macro or is there any other
better solution ?

Rgds,
Navi

Re: Subject: SSL_connect returned=1 errno=0 state=error: dh key too small

[Jakob Bohm via openssl-users]

On 29/08/2019 17:05, Hubert Kario wrote:

On Wednesday, 28 August 2019 23:20:49 CEST Marcelo Lauxen wrote:

...

that server is willing to negotiate ECDHE_RSA ciphers, you'd be better off
disabling ciphers that use DHE and RSA key exchange and using ECDHE_RSA
instead of trying to make 1024 bit work – it really is weak and should not be
used (see also: LOGJAM)



Where in the LOGJAM papers does it say that 1024 bit DH is too little,
provided the group is not shared among millions of servers?

Where, does it reliably say that ECDH with a choice of very few published
groups is more secure than DH with random group parameters shared among
a much smaller number of connections and servers?

Also note that the following factors make it necessary to support
traditional DHE for compatibility:

1. Red Hat OpenSSL builds until a few years ago disabled EC support.

2. Microsoft (and the TLS protocol specs themselves) until fairly
  recently allowed ECDHE only with (EC)DSA server certificates, which
  are not as easily available as RSA certs.

3. The "supported groups" TLS extension cannot be used without jamming
  the TLS clients into a short list of fixed DH groups.  Thus servers
  have to ignore that extension and use heuristic guesses to choose the
  DH strength.


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

Re: Subject: SSL_connect returned=1 errno=0 state=error: dh key too small

[Salz, Rich via openssl-users]

  *   I've another question, based on your suggestion Salz Rich, this config 
@SECLEVEL can be set per host/domain, or is it impossible?

It totally depends on which webserver you are running and what it’s 
configuration allows. I’m not able to answer webserver config questions BTW.

Re: Subject: SSL_connect returned=1 errno=0 state=error: dh key too small

[Marcelo Lauxen]

Thank you guys for the answers!

I've another question, based on your suggestion Salz Rich, this
config @SECLEVEL can be set per host/domain, or is it impossible?

On Thu, Aug 29, 2019 at 12:38 PM Salz, Rich  wrote:

>
>- We haven't control of the server who are using DH key size of 1048
>bits.
>
> In order to work with this kind of server (terribly poor security
> characteristics), you need to add “@SECLEVEL=0” to your OpenSSL
> configuration.
>
>
>

Re: Subject: SSL_connect returned=1 errno=0 state=error: dh key too small

[Hubert Kario]

On Wednesday, 28 August 2019 23:20:49 CEST Marcelo Lauxen wrote:
>   Our server runs with DH key size of 2048 bits and we are trying to make
> requests with httparty(https://github.com/jnunemaker/httparty) to a server
> that uses DH key size of 1024 bits, i want to now for what reason we are
> getting this error SSL_connect returned=1 errno=0 state=error: dh key too
> small, it's because different DH key sizes? 樂
> 
> We haven't control of the server who are using DH key size of 1048 bits.
> 
> I've opened the same issue on httparty
> https://github.com/jnunemaker/httparty/issues/664, but seems not a problem
> with httparty and something with OpenSSL.
> 
> Currently our server is using *OpenSSL 1.1.1c*, but before we was
> using *OpenSSL
> 1.1.0j* and this error doesn't happen. Is OpenSSL blocking the
> communication between our server who uses DH 2048 bits and the other server
> who uses DH 1024 bits (weak Diffie-Hellman)? If yes, is it reported in
> somewhere?
> 
> Our server SSL Labs results:
> https://www.ssllabs.com/ssltest/analyze.html?d=web.monde.com.br
> 
> Server who we are trying make requests:
> https://www.ssllabs.com/ssltest/analyze.html?d=webservices.voeazul.com.br
> test

that server is willing to negotiate ECDHE_RSA ciphers, you'd be better off 
disabling ciphers that use DHE and RSA key exchange and using ECDHE_RSA 
instead of trying to make 1024 bit work – it really is weak and should not be 
used (see also: LOGJAM)


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.

Re: Subject: SSL_connect returned=1 errno=0 state=error: dh key too small

[Salz, Rich]

  *   We haven't control of the server who are using DH key size of 1048 bits.
In order to work with this kind of server (terribly poor security 
characteristics), you need to add “@SECLEVEL=0” to your OpenSSL configuration.

Subject: SSL_connect returned=1 errno=0 state=error: dh key too small

[Marcelo Lauxen]

  Our server runs with DH key size of 2048 bits and we are trying to make
requests with httparty(https://github.com/jnunemaker/httparty) to a server
that uses DH key size of 1024 bits, i want to now for what reason we are
getting this error SSL_connect returned=1 errno=0 state=error: dh key too
small, it's because different DH key sizes? 樂

We haven't control of the server who are using DH key size of 1048 bits.

I've opened the same issue on httparty
https://github.com/jnunemaker/httparty/issues/664, but seems not a problem
with httparty and something with OpenSSL.

Currently our server is using *OpenSSL 1.1.1c*, but before we was
using *OpenSSL
1.1.0j* and this error doesn't happen. Is OpenSSL blocking the
communication between our server who uses DH 2048 bits and the other server
who uses DH 1024 bits (weak Diffie-Hellman)? If yes, is it reported in
somewhere?

Our server SSL Labs results:
https://www.ssllabs.com/ssltest/analyze.html?d=web.monde.com.br

Server who we are trying make requests:
https://www.ssllabs.com/ssltest/analyze.html?d=webservices.voeazul.com.br

How we can handle with this?
I would be happy if anyone can help me with this. :(

Att, Marcelo.

CRL issuer does not match CA subject

[Aram Akhavan]

Hello!

I'm creating a small PKI following the guide here: 
https://jamielinux.com/docs/openssl-certificate-authority


The intermediate CA cert is created with:
/openssl ca -config $ROOT_CONF -extensions v3_intermediate_ca //-days 
3650 -notext -md sha256/


If I then dump the cert, I see that subject line is
/Subject: C = us, ST = ca, O = test, CN = intermediate CA/

I then create the CRL using:
/openssl ca -config $INTRMDT_CONF //-gencrl -out $INTRMDT_CRL/

When I dump the CRL, though, the issuer is
/Issuer: /C=us/ST=ca/O=test/CN=intermediate ca/

When I put my certificate through 
https://certificate.revocationcheck.com/, it complains that the CRL 
issuer and intermediate CA subject don't match byte for byte.


Is there a way to have both generated with the same formatting? I looked 
through my configuration files and couldn't find anything that would 
explain the difference. I think it works anyways, but it would be nice 
to have them match...


Best regards,

Aram

Re: [openssl-users] Subject CN and SANs

[Viktor Dukhovni]

> On Dec 24, 2018, at 5:51 PM, Kyle Hamilton  wrote:

> If a certificate identifies an Issuer, then the certificate cannot contain an 
> empty sequence of RDNs in the Subject and still be conformant to PKIX.

Yes, CA certificates need to have a non-empty subject name if they're
to be used for signing subordinate certificates.

End-entity certificates do not need to have a non-empty subject name,
and some do not.  The usual public CAs have on the whole not yet
stopped populating CN values into the subject DN of subordinate EE
certificates, but when the DNS name in question is longer than ~64 bytes,
they have no choice but to omit the CN.

Undoubtedly a search through the CT logs would find some examples.

-- 
Viktor.

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

Re: [openssl-users] Subject CN and SANs

[Kyle Hamilton]

In order for an Issuer to exist in PKIX, it must be the Subject of another
Certificate (or of a trust anchor).  If a certificate identifies an Issuer,
then the certificate cannot contain an empty sequence of RDNs in the
Subject and still be conformant to PKIX.  This is because the Subject of
the issuing authority certificate needs to be copied (in some way which is
compatible with RFC4518's string preparation rules) into the Issuer of the
certificate that it issues.  This is implied by the path validation
algorithm, and stated explicitly in the last paragraph of RFC5280 section
4.1.2.4 which also refers to RFC5280 section 7.1.

However, PKIX is just a profile of X.509, and alternative approaches to
identifying the Issuer of a certificate exist.  (For self-signed
certificates, Issuer can be an empty sequence of RDNs, but I like to think
of that as a degenerate case that is also explicitly not conformant to PKIX
[RFC5280 section 4.1.2.4 last paragraph].  More importantly, the
IssuerKeyIdentifier can also be set, and matched with the
SubjectKeyIdentifier of another certificate.  This use is contemplated in
RFC 5280 section 4.2.1.2.)

(Note, though, that RFC 5914, "Trust Anchor Format", defines certPath :==
CertPathControls OPTIONAL.  In this case, *only*
IssuerKeyIdentifier/SubjectKeyIdentifier matching can work, and Issuer
otherwise apparently should be blank because the Anchor has no
taName/Subject.  You have to love the inconsistency of the PKIX standards,
yes?)

I haven't ever seen anything claiming that OpenSSL is expected to be
completely and invariably conformant to the PKIX profile.  It's possible
that it could be implied (if SSL or TLS specify that the certificates in
their Certificate records either "SHALL" or "MUST" be PKIX-profiled --
which does not appear to be the case in RFC 8846, which defines TLS 1.3),
but even then I'm not sure it would be appropriate to restrict its utility
in the manner of preventing newer versions from interoperating with
certificates issued by or which worked with older versions that permitted
such degenerate cases.

Merry Christmas (or happy holidays!),

-Kyle H



On Sun, Dec 23, 2018 at 5:33 PM Viktor Dukhovni 
wrote:
>
>
>
> > On Dec 23, 2018, at 6:01 PM, Kyle Hamilton  wrote:
> >
> > You're right, I typoed.  SubjectDN is non-optional.  But it can, as
> > you mentioned, be an empty sequence.
> >
> > But for PKIX purposes, it can't be empty if it's an Issuer (because
> > IssuerDN can't be empty in the certificates that it issues).
>
> That's an odd use of "it", since the issuerDN while also a DN is not
> a subjectDN.  The "it" that is the subjectDN is sometimes legitimately
> empty.  The other "it" that is the issuerDN is supposed to always be
> non-empty, but some self-signed certificates violate that requirement
> with apparent impunity, e.g. nothing in OpenSSL requires a non-empty
> issuer DN in an end-entity self-signed certificate, if it breaks, the
> constraint would be at the application layer.
>
> --
> Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Subject CN and SANs

[Felipe Gasper]

I’m not sure, heh. ;-)

-F

> On Dec 24, 2018, at 3:17 AM, Walter H.  wrote:
> 
> and which CA does this as the forum guidelines say?
> 
>> On 23.12.2018 22:50, Felipe Gasper wrote:
>> Actually, per the latest CA/Browser forum guidelines, subject.CN is not only 
>> optional but “discouraged”.
>> 
>> -FG
>> 
> 
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

Re: [openssl-users] Subject CN and SANs

[chris . gray]

A bit off-topic but is it also a good idea to follow these guidelines in
non-browser use cases, for example for a client certificate which is used
to autenticate on a TLS connection which will be used for another protocol
such as MQTT? In this case the SubjectCN looks like a "natural" place to
put the client's identity, but maybe it is still better to use
subjectAltName?

 - Chris

> Actually, per the latest CA/Browser forum guidelines, subject.CN is not
> only optional but “discouraged”.
>
> -FG
>
>> On Dec 23, 2018, at 4:29 PM, Kyle Hamilton  wrote:
>>
>> SubjectCN is an operational requirement of X.509, I believe.  It's not
>> optional in the data structure, at any rate.
>>
>> -Kyle H
>>
>>> On Sun, Dec 23, 2018 at 9:22 AM Michael Richardson 
>>> wrote:
>>>
>>>
>>> Salz, Rich via openssl-users  wrote:
 Putting the DNS name in the CN part of the subjectDN has been
 deprecated for a very long time (more than 10 years), although it
 is still supported by many existing browsers. New certificates
 should only use the subjectAltName extension.
>>>
>>> Fair enough.
>>>
>>> It seems that the "openssl ca" mechanism still seem to want a subjectDN
>>> defined.  Am I missing some mechanism that would let me omit all of
>>> that?  Or
>>> is a patch needed to kill what seems like a current operational
>>> requirement?
>>>
>>> --
>>> ]   Never tell me the odds! | ipv6 mesh
>>> networks [
>>> ]   Michael Richardson, Sandelman Software Works|IoT
>>> architect   [
>>> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on
>>> rails[
>>>
>>> --
>>> openssl-users mailing list
>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>


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

Re: [openssl-users] Subject CN and SANs

[Walter H.]

and which CA does this as the forum guidelines say?

On 23.12.2018 22:50, Felipe Gasper wrote:

Actually, per the latest CA/Browser forum guidelines, subject.CN is not only 
optional but “discouraged”.

-FG






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

Re: [openssl-users] Subject CN and SANs

[Viktor Dukhovni]

> On Dec 23, 2018, at 6:01 PM, Kyle Hamilton  wrote:
> 
> You're right, I typoed.  SubjectDN is non-optional.  But it can, as
> you mentioned, be an empty sequence.
> 
> But for PKIX purposes, it can't be empty if it's an Issuer (because
> IssuerDN can't be empty in the certificates that it issues).

That's an odd use of "it", since the issuerDN while also a DN is not
a subjectDN.  The "it" that is the subjectDN is sometimes legitimately
empty.  The other "it" that is the issuerDN is supposed to always be
non-empty, but some self-signed certificates violate that requirement
with apparent impunity, e.g. nothing in OpenSSL requires a non-empty
issuer DN in an end-entity self-signed certificate, if it breaks, the
constraint would be at the application layer.

-- 
Viktor.

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

Re: [openssl-users] Subject CN and SANs

[Kyle Hamilton]

You're right, I typoed.  SubjectDN is non-optional.  But it can, as
you mentioned, be an empty sequence.

But for PKIX purposes, it can't be empty if it's an Issuer (because
IssuerDN can't be empty in the certificates that it issues).

-Kyle H

On Sun, Dec 23, 2018 at 3:35 PM Viktor Dukhovni
 wrote:
>
>
>
> > On Dec 23, 2018, at 4:29 PM, Kyle Hamilton  wrote:
> >
> > SubjectCN is an operational requirement of X.509, I believe.
>
> You're confusing the DN and the CN.
>
> >  It's not optional in the data structure, at any rate.
>
> The subjectDN is not optional, but it can be empty sequence, and
> is empty for domains whose name exceeds the CN length limit of either
> 63 or 64 characters (can't recall which of the two just now, but that
> is not important).
>
> --
> Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Subject CN and SANs

[Felipe Gasper]

Actually, per the latest CA/Browser forum guidelines, subject.CN is not only 
optional but “discouraged”.

-FG

> On Dec 23, 2018, at 4:29 PM, Kyle Hamilton  wrote:
> 
> SubjectCN is an operational requirement of X.509, I believe.  It's not
> optional in the data structure, at any rate.
> 
> -Kyle H
> 
>> On Sun, Dec 23, 2018 at 9:22 AM Michael Richardson  wrote:
>> 
>> 
>> Salz, Rich via openssl-users  wrote:
>>> Putting the DNS name in the CN part of the subjectDN has been
>>> deprecated for a very long time (more than 10 years), although it
>>> is still supported by many existing browsers. New certificates
>>> should only use the subjectAltName extension.
>> 
>> Fair enough.
>> 
>> It seems that the "openssl ca" mechanism still seem to want a subjectDN
>> defined.  Am I missing some mechanism that would let me omit all of that?  Or
>> is a patch needed to kill what seems like a current operational requirement?
>> 
>> --
>> ]   Never tell me the odds! | ipv6 mesh networks 
>> [
>> ]   Michael Richardson, Sandelman Software Works|IoT architect   
>> [
>> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails   
>>  [
>> 
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

Re: [openssl-users] Subject CN and SANs

[Viktor Dukhovni]

> On Dec 23, 2018, at 4:29 PM, Kyle Hamilton  wrote:
> 
> SubjectCN is an operational requirement of X.509, I believe.

You're confusing the DN and the CN.

>  It's not optional in the data structure, at any rate.

The subjectDN is not optional, but it can be empty sequence, and
is empty for domains whose name exceeds the CN length limit of either
63 or 64 characters (can't recall which of the two just now, but that
is not important).

-- 
Viktor.

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

Re: [openssl-users] Subject CN and SANs

[Kyle Hamilton]

SubjectCN is an operational requirement of X.509, I believe.  It's not
optional in the data structure, at any rate.

-Kyle H

On Sun, Dec 23, 2018 at 9:22 AM Michael Richardson  wrote:
>
>
> Salz, Rich via openssl-users  wrote:
> > Putting the DNS name in the CN part of the subjectDN has been
> > deprecated for a very long time (more than 10 years), although it
> > is still supported by many existing browsers. New certificates
> > should only use the subjectAltName extension.
>
> Fair enough.
>
> It seems that the "openssl ca" mechanism still seem to want a subjectDN
> defined.  Am I missing some mechanism that would let me omit all of that?  Or
> is a patch needed to kill what seems like a current operational requirement?
>
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works|IoT architect   [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Subject CN and SANs

[Viktor Dukhovni]

> On Dec 23, 2018, at 10:21 AM, Michael Richardson  wrote:
> 
> It seems that the "openssl ca" mechanism still seem to want a subjectDN
> defined.  Am I missing some mechanism that would let me omit all of that?  Or
> is a patch needed to kill what seems like a current operational requirement?

It is not a matter of "openssl ca".  An X.509 certificate has a subjectDN,
that's a required part of the certificate structure.  However, a "DN" is a
SEQUENCE of "RDNs", and that sequence can be empty, for example (requires 
"bash"):

  $ openssl req -config <(
  printf "%s\n[dn]\n%s\n[ext]\n%s\n" \
"distinguished_name = dn" \
"prompt = yes" \
"$(printf "subjectAltName = DNS:%s\n" "example.com")"
  ) \
-extensions ext -new -newkey rsa:1024 -nodes -keyout /dev/null \
-x509 -subj / 2>/dev/null |
  openssl x509 -noout -text -certopt no_pubkey,no_sigdump
  Certificate:
  Data:
  Version: 3 (0x2)
  Serial Number:
  47:37:cb:39:a4:9c:be:c2:ea:42:2f:ed:e2:df:bc:62:bb:2b:cb:dd
  Signature Algorithm: sha256WithRSAEncryption
  Issuer: 
      Validity
  Not Before: Dec 23 18:56:08 2018 GMT
  Not After : Jan 22 18:56:08 2019 GMT
  Subject: 
  X509v3 extensions:
  X509v3 Subject Alternative Name: 
  DNS:example.com

Note the empty subjectDN and issuerDN.  The latter violates RFC5280, but
will suffice for this example.  An RFC compliant *self-signed* certificate
needs to have a non-empty issuer name, so it could be something like:

  $ openssl req -config <(
  printf "%s\n[dn]\n%s\n[ext]\n%s\n" \
"distinguished_name = dn" \
"prompt = yes" \
"$(printf "subjectAltName = DNS:%s\n" "example.com")"
  ) \
-extensions ext -new -newkey rsa:1024 -nodes -keyout /dev/null \
-x509 -subj "/O=Self" 2>/dev/null |
  openssl x509 -noout -text -certopt no_pubkey,no_sigdump
  Certificate:
  Data:
  Version: 3 (0x2)
  Serial Number:
  6b:f0:9e:6c:ff:27:f3:cb:eb:79:10:6d:ac:9a:c2:54:e4:78:06:b0
  Signature Algorithm: sha256WithRSAEncryption
  Issuer: O = Self
  Validity
  Not Before: Dec 23 19:08:51 2018 GMT
      Not After : Jan 22 19:08:51 2019 GMT
  Subject: O = Self
  X509v3 extensions:
  X509v3 Subject Alternative Name: 
  DNS:example.com

with an actual CA, the subject could be empty, and the issuer will be the
CA's DN.

-- 
Viktor.

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

Re: [openssl-users] Subject CN and SANs

[Michael Richardson]

Salz, Rich via openssl-users  wrote:
> Putting the DNS name in the CN part of the subjectDN has been
> deprecated for a very long time (more than 10 years), although it
> is still supported by many existing browsers. New certificates
> should only use the subjectAltName extension.

Fair enough.

It seems that the "openssl ca" mechanism still seem to want a subjectDN
defined.  Am I missing some mechanism that would let me omit all of that?  Or
is a patch needed to kill what seems like a current operational requirement?

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works|IoT architect   [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Subject CN and SANs

[Walter H.]

I guess its a matter of which Linux you use,

CentOS 7 doesn't give this warning;
CentOS 6 warns about this;

a Debian (don't really know which release)
uname -a
Linux a2f78 3.16.0-7-amd64 #1 SMP Debian 3.16.59-1 (2018-10-03) x86_64 
GNU/Linux

does warn ...

Walter

On 23.12.2018 13:21, Felipe Gasper wrote:

Wow that’s pretty bad .. is that the current version of httpd??

That’d be worth a big report if so, IMO, though I’d imagine it’s an issue 
they’re aware of.

-FG


On Dec 23, 2018, at 6:53 AM, Walter H.  wrote:


I tried the following

the certificate had a CN oftest.example.com   and in subjectAltNames dNS 
were
test.example.com  and test.example.net

when the Apache ServerName is   test.example.net  I get this warning

[Sun Dec 23 12:45:03 2018] [warn] RSA server certificate CommonName (CN) 
`test.example.com' does NOT match server name!?

so the CN matters ...

so the server behavior is something different to the behavior of the client ...

Walter


On 23.12.2018 10:44, Kyle Hamilton wrote:
Does Apache only examine CN=, or does it also check subjectAltNames dNS entries?

-Kyle H


On Sun, Dec 23, 2018 at 3:25 AM Walter H.   wrote:

On 23.12.2018 03:47, Salz, Rich via openssl-users wrote:
 >>. New certificates should only use the subjectAltName extension.


 Are any CAs actually doing that? I thought they all still included 
subject.CN.

Yes, I think commercial CA's still do it.  But that doesn't make my statement 
wrong :)


Apache raises a warning at the following condition

e.g. a virtual Host defines this:

ServerName  www.example.com:443

and the SSL certificate has a CN which does not correspond to
CN=www.example.com, e.g.  CN=example.com

then the warning looks like this

[Fri Dec 07 07:08:19.393876 2018] [ssl:warn] [pid 29746] AH01909:
www.example.com:443:0 server certificate does NOT include an ID which
matches the server name

and fills up the logs

Walter







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

Re: [openssl-users] Subject CN and SANs

[Felipe Gasper]

Wow that’s pretty bad .. is that the current version of httpd??

That’d be worth a big report if so, IMO, though I’d imagine it’s an issue 
they’re aware of.

-FG

> On Dec 23, 2018, at 6:53 AM, Walter H.  wrote:
> 
> 
> I tried the following
> 
> the certificate had a CN oftest.example.com   and in subjectAltNames dNS 
> were
> test.example.com  and test.example.net
> 
> when the Apache ServerName is   test.example.net  I get this warning
> 
> [Sun Dec 23 12:45:03 2018] [warn] RSA server certificate CommonName (CN) 
> `test.example.com' does NOT match server name!?
> 
> so the CN matters ...
> 
> so the server behavior is something different to the behavior of the client 
> ...
> 
> Walter
> 
>> On 23.12.2018 10:44, Kyle Hamilton wrote:
>> Does Apache only examine CN=, or does it also check subjectAltNames dNS 
>> entries?
>> 
>> -Kyle H
>> 
>>> On Sun, Dec 23, 2018 at 3:25 AM Walter H.  
>>> wrote:
 On 23.12.2018 03:47, Salz, Rich via openssl-users wrote:
 >   >. New certificates should only use the subjectAltName extension.
 
> Are any CAs actually doing that? I thought they all still included 
> subject.CN.
 Yes, I think commercial CA's still do it.  But that doesn't make my 
 statement wrong :)
 
>>> Apache raises a warning at the following condition
>>> 
>>> e.g. a virtual Host defines this:
>>> 
>>> ServerName  www.example.com:443
>>> 
>>> and the SSL certificate has a CN which does not correspond to
>>> CN=www.example.com, e.g.  CN=example.com
>>> 
>>> then the warning looks like this
>>> 
>>> [Fri Dec 07 07:08:19.393876 2018] [ssl:warn] [pid 29746] AH01909:
>>> www.example.com:443:0 server certificate does NOT include an ID which
>>> matches the server name
>>> 
>>> and fills up the logs
>>> 
>>> Walter
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

Re: [openssl-users] Subject CN and SANs

[Walter H.]

I tried the following

the certificate had a CN oftest.example.com   and in subjectAltNames 
dNS were

test.example.com  and test.example.net

when the Apache ServerName is   test.example.net  I get this warning

[Sun Dec 23 12:45:03 2018] [warn] RSA server certificate CommonName (CN) 
`test.example.com' does NOT match server name!?


so the CN matters ...

so the server behavior is something different to the behavior of the 
client ...


Walter

On 23.12.2018 10:44, Kyle Hamilton wrote:

Does Apache only examine CN=, or does it also check subjectAltNames dNS entries?

-Kyle H

On Sun, Dec 23, 2018 at 3:25 AM Walter H.  wrote:

On 23.12.2018 03:47, Salz, Rich via openssl-users wrote:

 >   >. New certificates should only use the subjectAltName extension.


 Are any CAs actually doing that? I thought they all still included 
subject.CN.

Yes, I think commercial CA's still do it.  But that doesn't make my statement 
wrong :)


Apache raises a warning at the following condition

e.g. a virtual Host defines this:

ServerName  www.example.com:443

and the SSL certificate has a CN which does not correspond to
CN=www.example.com, e.g.  CN=example.com

then the warning looks like this

[Fri Dec 07 07:08:19.393876 2018] [ssl:warn] [pid 29746] AH01909:
www.example.com:443:0 server certificate does NOT include an ID which
matches the server name

and fills up the logs

Walter




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

Re: [openssl-users] Subject CN and SANs

[Kyle Hamilton]

Does Apache only examine CN=, or does it also check subjectAltNames dNS entries?

-Kyle H

On Sun, Dec 23, 2018 at 3:25 AM Walter H.  wrote:
>
> On 23.12.2018 03:47, Salz, Rich via openssl-users wrote:
> > >  >. New certificates should only use the subjectAltName extension.
> >
> >> Are any CAs actually doing that? I thought they all still included 
> >> subject.CN.
> >
> > Yes, I think commercial CA's still do it.  But that doesn't make my 
> > statement wrong :)
> >
> Apache raises a warning at the following condition
>
> e.g. a virtual Host defines this:
>
> ServerName  www.example.com:443
>
> and the SSL certificate has a CN which does not correspond to
> CN=www.example.com, e.g.  CN=example.com
>
> then the warning looks like this
>
> [Fri Dec 07 07:08:19.393876 2018] [ssl:warn] [pid 29746] AH01909:
> www.example.com:443:0 server certificate does NOT include an ID which
> matches the server name
>
> and fills up the logs
>
> Walter
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Subject CN and SANs

[Walter H.]

On 23.12.2018 03:47, Salz, Rich via openssl-users wrote:

>  >. New certificates should only use the subjectAltName extension.


Are any CAs actually doing that? I thought they all still included 
subject.CN.


Yes, I think commercial CA's still do it.  But that doesn't make my statement 
wrong :)


Apache raises a warning at the following condition

e.g. a virtual Host defines this:

ServerName  www.example.com:443

and the SSL certificate has a CN which does not correspond to
CN=www.example.com, e.g.  CN=example.com

then the warning looks like this

[Fri Dec 07 07:08:19.393876 2018] [ssl:warn] [pid 29746] AH01909: 
www.example.com:443:0 server certificate does NOT include an ID which 
matches the server name


and fills up the logs

Walter



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

Re: [openssl-users] Subject CN and SANs

[Salz, Rich via openssl-users]

   > >. New certificates should only use the subjectAltName extension.

>Are any CAs actually doing that? I thought they all still included 
> subject.CN.
  
Yes, I think commercial CA's still do it.  But that doesn't make my statement 
wrong :)

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

Re: [openssl-users] Subject CN and SANs

[Felipe Gasper]

> On Dec 22, 2018, at 9:12 PM, Salz, Rich via openssl-users 
>  wrote:
> 
> Putting the DNS name in the CN part of the subjectDN has been deprecated for 
> a very long time (more than 10 years), although it is still supported by many 
> existing browsers. New certificates should only use the subjectAltName 
> extension.

Are any CAs actually doing that? I thought they all still included subject.CN.

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

Re: [openssl-users] Subject CN and SANs

[Salz, Rich via openssl-users]

Putting the DNS name in the CN part of the subjectDN has been deprecated for a 
very long time (more than 10 years), although it is still supported by many 
existing browsers. New certificates should only use the subjectAltName 
extension.
 

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

Re: [openssl-users] Subject CN and SANs

[Felipe Gasper]

It shouldn’t matter. Technically subject.CN is deprecated anyway, but all the 
CAs still create it.

-FG


> On Dec 22, 2018, at 4:29 PM, Walter H.  wrote:
> 
> Hello,
> 
> I found several different certificates on the net
> 
> some are like this:
> 
> CN=example.com
> SANs areDNS:example.com, DNS:www.example.com
> 
> and some are like this:
> 
> CN=www.example.com
> SANs areDNS:example.com, DNS:www.example.com
> 
> does this matter or is one them the preferred one?
> 
> Thanks,
> Walter
> 
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

[openssl-users] Subject CN and SANs

[Walter H.]

Hello,

I found several different certificates on the net

some are like this:

CN=example.com
SANs areDNS:example.com, DNS:www.example.com

and some are like this:

CN=www.example.com
SANs areDNS:example.com, DNS:www.example.com

does this matter or is one them the preferred one?

Thanks,
Walter




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

Re: [openssl-users] [openssl]: Subject alternative names not recognized when signing certificates

[Viktor Dukhovni]

> On Sep 22, 2018, at 8:28 AM, Carsten  wrote:
> 
> I can sign certificate requests successfully, BUT
> if the request contains SAN attributs (subjectalternatenames) they are 
> ignored -not visible in the signed certificate.
> 
> I found many exambles how to create a SAN-Certificate using the selfsigned 
> mechanism, but that is not what I want.
> 
> Is there any how-to in the wild, how to set up a fully working CA including 
> SAN (v3) attributs?

My approach is generally to dynamically generate a config file with the 
requisite
extensions, and use that to build the certificate.  It is possible to copy
extensions from the request (CSR) to the certificate, but not always wise
if you've not carefully checked that all the extensions in the CSR are 
appropriate.

  https://www.openssl.org/docs/man1.1.0/apps/ca.html

  copy_extensions

  determines how extensions in certificate requests should be handled.
  If set to none or this option is not present then extensions are
  ignored and not copied to the certificate. If set to copy then any
  extensions present in the request that are not already present are
  copied to the certificate. If set to copyall then all extensions
  in the request are copied to the certificate: if the extension is
  already present in the certificate it is deleted first. See the
  WARNINGS section before using this option.

  ...

  The copy_extensions option should be used with caution. If care is
  not taken then it can be a security risk. For example if a certificate
  request contains a basicConstraints extension with CA:TRUE and the
  copy_extensions value is set to copyall and the user does not spot
  this when the certificate is displayed then this will hand the
  requester a valid CA certificate.
  
  This situation can be avoided by setting copy_extensions to copy
  and including basicConstraints with CA:FALSE in the configuration
  file. Then if the request contains a basicConstraints extension it
  will be ignored.
  
  It is advisable to also include values for other extensions such
  as keyUsage to prevent a request supplying its own values.
  
  Additional restrictions can be placed on the CA certificate itself.
  For example if the CA certificate has:
  
   basicConstraints = CA:TRUE, pathlen:0
  
  then even if a certificate is issued with CA:TRUE it will not be
  valid.

-- 
Viktor.

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

[openssl-users] [openssl]: Subject alternative names not recognized when signing certificates

[Carsten]

Hi list,

this is about setting up a certificate authority to sign incoming 
(forgeign) certificate requests.

I have installed

/var/caintermed # openssl version -a
OpenSSL 1.1.2-dev  xx XXX 
built on: Fri Sep 21 10:19:51 2018 UTC
platform: linux-armv4
options:  bn(64,32) rc4(char) des(long) idea(int) blowfish(ptr)
compiler: gcc -fPIC -pthread  -march=armv7-a -Wa,--noexecstack -Wall -O3 
-DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
-DSHA512_ASM -DKECCAK1600_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM 
-DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG

OPENSSLDIR: "/usr/local/ssl"
ENGINESDIR: "/usr/local/lib/engines-1.1"
Seeding source: os-specific


My setup is based on this:
https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html

I can sign certificate requests successfully, BUT
if the request contains SAN attributs (subjectalternatenames) they are 
ignored -not visible in the signed certificate.


I found many exambles how to create a SAN-Certificate using the 
selfsigned mechanism, but that is not what I want.


Is there any how-to in the wild, how to set up a fully working CA 
including SAN (v3) attributs?


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

[openssl-users] (no subject)

[Jason Jordan]

Get Outlook for Android

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

[openssl-users] (no subject)

[timmy pony]

Hi,

Trying to get the Openssl command line version of the following snippet.

I have tried this  openssl dgst -sha256 -sign my_private.key -out
/tmp/sign.sha256 codeTosign.txt

But the  the results do not match ?

```
From: "tim.fortinbras" 
To: openssl-users@openssl.org
Cc:
Bcc:
Date: Tue, 31 Jul 2018 06:48:59 -0700 (MST)
Subject: Looking for exact openssl commands to do the following from
command line ?
import java.security.KeyFactory;
import java.security.Signature;
import java.security.spec.PKCS8EncodedKeySpec;
import java.util.Base64;

public class SHA256RSA {

public static void main(String[] args) throws Exception {
String input = "sample input";

// Not a real private key! Replace with your private key!
String strPk = "-BEGIN PRIVATE KEY-\nMIIEvwIBADANBgkqhkiG9"
+ "w0BAQEFAASCBKkwggSlAgEAAoIBAQDJUGqaRB11KjxQ\nKHDeG"
+ ""
+ "Ldt0hAPNl4QKYWCfJm\nNf7Afqaa/RZq0+y/36v83NGENQ==\n"
+ "-END PRIVATE KEY-\n";

String base64Signature = signSHA256RSA(input,strPk);
System.out.println("Signature="+base64Signature);
}

// Create base64 encoded signature using SHA256/RSA.
private static String signSHA256RSA(String input, String strPk) throws
Exception {
// Remove markers and new line characters in private key
String realPK = strPk.replaceAll("-END PRIVATE KEY-", "")
 .replaceAll("-BEGIN PRIVATE KEY-", "")
 .replaceAll("\n", "");

byte[] b1 = Base64.getDecoder().decode(realPK);
PKCS8EncodedKeySpec spec = new PKCS8EncodedKeySpec(b1);
KeyFactory kf = KeyFactory.getInstance("RSA");

Signature privateSignature = Signature.getInstance("SHA256withRSA");
privateSignature.initSign(kf.generatePrivate(spec));
privateSignature.update(input.getBytes("UTF-8"));
byte[] s = privateSignature.sign();
return Base64.getEncoder().encodeToString(s);
}
}
```
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] (no subject)

[Joanna Marazewska]

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

[openssl-users] (no subject)

[81]

Gesendet von Mail für Windows 10

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

[openssl-users] (no subject)

[Guido]

Gesendet von Mail für Windows 10

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

[openssl-users] (no subject)

[Guido]

Gesendet von Mail für Windows 10

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

[openssl-users] (no subject)

[guido]

import rlcompleter
import readline
readline.parse_and_bind("tab: complete")

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

[openssl-users] (no subject)

[Guido]

Gesendet von Mail für Windows 10

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

Re: [openssl-users] x509: recent change in Subject and Issuer printing?

[Matt Caswell]

On 04/03/18 02:22, Adam Shannon wrote:
> Was there a change included in the 1.1.0 series which prints names
> differently? I've looked, but been unable to narrow down what in
> specific changed.

This was changed by commit f1cece554d.

The default "nameopt" setting for the x509 app (and a few others)
changed from "compat" to "oneline". See the man page here for
descriptions of these options:

https://www.openssl.org/docs/man1.1.0/apps/x509.html

If you add "-nameopt compat" to your 1.1.0 command line you should see
the old behaviour.

Matt



> 
> $ /usr/local/opt/openssl/bin/openssl version
> OpenSSL 1.0.2n  7 Dec 2017
> 
> $ /usr/local/opt/openssl/bin/openssl x509 -in thawte.pem -noout -text |
> grep -E 'Issuer:|Subject:'
>     Issuer: C=US, O=thawte, Inc., OU=Certification Services
> Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte
> Primary Root CA
>     Subject: C=US, O=Thawte, Inc., CN=Thawte SSL CA
> 
> $ openssl version
> OpenSSL 1.1.0f  25 May 2017
> 
> $ openssl x509 -in thawte.pem -noout -text | grep -E 'Issuer:|Subject:'
>     Issuer: C = US, O = "thawte, Inc.", OU = Certification Services
> Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN =
> thawte Primary Root CA
>     Subject: C = US, O = "Thawte, Inc.", CN = Thawte SSL CA
> 
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] x509: recent change in Subject and Issuer printing?

[Adam Shannon]

Was there a change included in the 1.1.0 series which prints names
differently? I've looked, but been unable to narrow down what in specific
changed.

$ /usr/local/opt/openssl/bin/openssl version
OpenSSL 1.0.2n  7 Dec 2017

$ /usr/local/opt/openssl/bin/openssl x509 -in thawte.pem -noout -text |
grep -E 'Issuer:|Subject:'
Issuer: C=US, O=thawte, Inc., OU=Certification Services Division,
OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary Root
CA
Subject: C=US, O=Thawte, Inc., CN=Thawte SSL CA

$ openssl version
OpenSSL 1.1.0f  25 May 2017

$ openssl x509 -in thawte.pem -noout -text | grep -E 'Issuer:|Subject:'
Issuer: C = US, O = "thawte, Inc.", OU = Certification Services
Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN =
thawte Primary Root CA
Subject: C = US, O = "Thawte, Inc.", CN = Thawte SSL CA
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openssl.cnf asking Subject Alternative Names certificates.

[Jorge Novo]

Hi,

On 13 October 2017 at 12:03, lists <li...@rustichelli.net> wrote:

> On 10/10/2017 05:40 PM, Jorge Novo wrote:
>
>   As most of us know, the Google Chrome Navigator ask about Subject
> Alternative Name instead the Common Name.
>
> I want to distribute a little *openssl.cnf* file for creation the CSR
> files with my specific values and establish the Subject Alternative Name =
> Common Name. I want yo ask about the CN and assign this value to SAN.
>
> This is my beta *openssl.cnf* file:
>
> *Sorry for the comments in Spanish
>
> I do not how to set a variable (CN Variable) to assign to SAN value.
>
>
> In my limited knowledge, you can't copy the CN name into the SAN in the
> configuration.
> Obvious yet clumsy workaround is to have a shell script ask for the FQDN,
> set a shell variable with the CN value and then recall the ENV variable
> from inside openssl.cnf, or you can have the script dynamically write/edit
> opessl.cnf with the user-entered value.
>

This is correct, it does not exist any configuration to copy the CN to SNA
or
vice versa, although it is weird because, in fact it exists, a
configuration to
copy the SMA email address from the distinguished name. This can be
done with these settings subjectAltName=email:copy or
subjectAltName=email:move. With move I can not confirm it.

https://www.openssl.org/docs/man1.1.0/apps/x509v3_config.html

_Subject Alternative Name_

[...]
The email option include a special 'copy' value. This will automatically
include any email addresses contained in the certificate subject name in
the extension.
[...]


My solution for this was:

# export Cert_Name=www.micasa.local
# openssl req -new -keyout $Cert_Name.key -out $Cert_Name.csr -config
opensslMiCasa.cnf
# unset $Cert_Name



---

SALUDE3.

http://www.rodeiroag.es/
http://soloeningles.blogspot.com/
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] openssl.cnf asking Subject Alternative Names certificates.

[lists]

On 10/10/2017 05:40 PM, Jorge Novo wrote:

Hi everyone,

  As most of us know, the Google Chrome Navigator ask about Subject 
Alternative Name instead the Common Name.


I want to distribute a little /openssl.cnf/ file for creation the CSR 
files with my specific values and establish the Subject Alternative 
Name = Common Name. I want yo ask about the CN and assign this value 
to SAN.


This is my beta /openssl.cnf/ file:

*Sorry for the comments in Spanish

I do not how to set a variable (CN Variable) to assign to SAN value.
/
/


In my limited knowledge, you can't copy the CN name into the SAN in the 
configuration.
Obvious yet clumsy workaround is to have a shell script ask for the 
FQDN, set a shell variable with the CN value and then recall the ENV 
variable from inside openssl.cnf, or you can have the script dynamically 
write/edit opessl.cnf with the user-entered value.


/ 8<  
8< ---

/#
# Este fichero genera los CSR de nuestros sistemas con los paremetros
# acordados.
#
# openssl genrsa -aes256 -out www.rra.lan.key 2048 -config 
opensslMiCasa.cnf

#

# Establecemos un directorio de trabajo, el actual para ser exactos.

dir                             = .

[ req ]
default_bits                    = 2048    # Size of keys
default_keyfile                 = key.pem     # name of generated keys
default_md                      = sha256    # message digest algorithm
string_mask                     = nombstr     # permitted characters
distinguished_name              = req_distinguished_name
req_extensions                  = v3_req

[ req_distinguished_name ]
# Variable name                         Prompt string
#-  --
0.organizationName              = Nombre de la Organizacion
organizationalUnitName          = Mi Casa 
[Desarrollo|Infraestructuras|Laboratorio]

emailAddress                    = Cuenta de Correo
emailAddress_max                = 64
localityName                    = Localidad
stateOrProvinceName             = Comunidad Autónoma
countryName                     = ISO 3166-1 Codigo de País
countryName_min                 = 2
countryName_max                 = 2
commonName                      = Common Name

# Default values for the above, for consistency and less typing.
# Variable name                         Value
# --
0.organizationName_default      = Mi Casa
organizationalUnitName_default  = Mi Casa Infraestructuras
localityName_default            = Madrid
stateOrProvinceName_default     = Comunidad de Madrid
countryName_default             = ES

[ v3_req ]
basicConstraints                = CA:FALSE
subjectKeyIdentifier            = hash
subjectAltName                  =
// //>8// 
 >8 ---//


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

[openssl-users] openssl.cnf asking Subject Alternative Names certificates.

[Jorge Novo]

Hi everyone,

  As most of us know, the Google Chrome Navigator ask about Subject
Alternative Name instead the Common Name.

I want to distribute a little *openssl.cnf* file for creation the CSR files
with my specific values and establish the Subject Alternative Name = Common
Name. I want yo ask about the CN and assign this value to SAN.

This is my beta *openssl.cnf* file:

*Sorry for the comments in Spanish

I do not how to set a variable (CN Variable) to assign to SAN value.


* 8<  8<
---*#
# Este fichero genera los CSR de nuestros sistemas con los paremetros
# acordados.
#
# openssl genrsa -aes256 -out www.rra.lan.key 2048 -config opensslMiCasa.cnf
#

# Establecemos un directorio de trabajo, el actual para ser exactos.

dir = .

[ req ]
default_bits= 2048  # Size of
keys
default_keyfile = key.pem   # name of
generated keys
default_md  = sha256# message
digest algorithm
string_mask = nombstr   # permitted
characters
distinguished_name  = req_distinguished_name
req_extensions  = v3_req

[ req_distinguished_name ]
# Variable name Prompt string
#---
0.organizationName  = Nombre de la Organizacion
organizationalUnitName  = Mi Casa
[Desarrollo|Infraestructuras|Laboratorio]
emailAddress= Cuenta de Correo
emailAddress_max= 64
localityName= Localidad
stateOrProvinceName = Comunidad Autónoma
countryName = ISO 3166-1 Codigo de País
countryName_min = 2
countryName_max = 2
commonName  = Common Name

# Default values for the above, for consistency and less typing.
# Variable name Value
# --
0.organizationName_default  = Mi Casa
organizationalUnitName_default  = Mi Casa Infraestructuras
localityName_default= Madrid
stateOrProvinceName_default = Comunidad de Madrid
countryName_default = ES

[ v3_req ]
basicConstraints= CA:FALSE
subjectKeyIdentifier= hash
subjectAltName  =
* **>8  >8
---*


---

SALUDE3.

http://www.rodeiroag.es/
http://soloeningles.blogspot.com/
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Creating requests and certificates with Subject Alternative Names

[Angus Robertson - Magenta Systems Ltd]

I'm creating X509 certificate requests and certificates in code, trying
to add X509v3 Subject Alternative Name, with 1.1.0f.  

But if I add a list of four domains, ie: 

www1.mydomain
www2.mydomain
www3.mydomain
www4.mydomain

The certificate seems to ignore some and repeat others:

X509v3 Subject Alternative Name: 
DNS:www3.mydomain, DNS:www4.mydomain, DNS:www3.mydomain,
DNS:www4.mydomain

Finding documentation for SANs in OpenSSL is very hard, there don't
seem to be high level APIs to create extension content stacks.   The
best I found is set_altname in v3nametest.c which builds a stack of
GENERAL_NAMES and adds it using X509_add1_ext_i2d. 

I must be something correct since it half works, but no idea why the
data is corrupted. 

To complicate matters, I'm not writing in C, but using Delphi pascal,
so all the OpenSSL APIs and macros have been converted to Delphi, which
does potentially cause errors in translation.  This is an open source
Delphi interface to OpenSSL.  

Angus

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

Re: [openssl-users] Trusting certificates with the same subject name and overlapping validity periods

[Jeffrey Walton]

On Wed, Sep 20, 2017 at 5:48 PM, Jordan Brown
<open...@jordan.maileater.net> wrote:
> ...
> The above also works with "authorityCertSerialNumber", see
>
>https://tools.ietf.org/html/rfc5280#section-4.2.1.1
>
> If, however, the newer certificate has a different key, and the same
> subject DN, but does not place matching distinct subject key identifiers
> in the certificates it issues, then OpenSSL will not correctly handle
> multiple candidate issuers that differ in the public key, but provide
> no hints in the issued certificates which issuer to use.
>
> I'm not familiar with those extensions and will need to do more research.

I believe the controlling IETF document is "Internet X.509 Public Key
Infrastructure: Certification Path Building",
https://tools.ietf.org/html/rfc4158.

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

Re: [openssl-users] Trusting certificates with the same subject name and overlapping validity periods

[Jordan Brown]

On 9/20/2017 2:25 PM, Viktor Dukhovni wrote:
>> On Sep 20, 2017, at 12:33 PM, Jordan Brown <open...@jordan.maileater.net> 
>> wrote:
>>
>> Q:  Does OpenSSL's trust-list verification support trusting multiple 
>> certificates with the same subject name and overlapping validity periods?
>>
>> In more detail:
>>
>> We have customers who issue replacement certificates with the same subject 
>> name and different validity periods.  We'd like to be able to 
>> straightforwardly add the new certificates to the trust list and have them 
>> work, but seem to find that certificate verification doesn't handle the 
>> case.  (Mozilla NSS does seem to handle it.)
> Generally speaking, if the latest certificate has the same key, then
> it should cover the older ones, which can be dropped from the trust list.
>
> If, however, the newer certificates have a different key, then everything
> should work, provided the certificates issued under the new key carry
> an "authority key identifier" extension, which matches the corresponding
> "subject key identifier" in the issuer CA certificate.
>
> The above also works with "authorityCertSerialNumber", see
>
>https://tools.ietf.org/html/rfc5280#section-4.2.1.1
>
> If, however, the newer certificate has a different key, and the same
> subject DN, but does not place matching distinct subject key identifiers
> in the certificates it issues, then OpenSSL will not correctly handle
> multiple candidate issuers that differ in the public key, but provide
> no hints in the issued certificates which issuer to use.

I'm not familiar with those extensions and will need to do more research.

However, it sounds like you're assuming a CA-issued certificate where we
have the CA certificate in the trust list.

That's not the case.  These are (in the most relevant cases) self-signed
certificates or CA-issued certificates where we have only the leaf
certificate in the trust list.

I suspect that they are indeed falling into that last case, where the
only way to know which certificate in the trust list is "right" is to
try the crypto verification on each trusted certificate until one
succeeds.  (Or just compare the certificate presented with the ones in
the trust list.)

-- 
Jordan Brown, Oracle Solaris

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

Re: [openssl-users] Trusting certificates with the same subject name and overlapping validity periods

[Viktor Dukhovni]

> On Sep 20, 2017, at 12:33 PM, Jordan Brown <open...@jordan.maileater.net> 
> wrote:
> 
> Q:  Does OpenSSL's trust-list verification support trusting multiple 
> certificates with the same subject name and overlapping validity periods?
> 
> In more detail:
> 
> We have customers who issue replacement certificates with the same subject 
> name and different validity periods.  We'd like to be able to 
> straightforwardly add the new certificates to the trust list and have them 
> work, but seem to find that certificate verification doesn't handle the case. 
>  (Mozilla NSS does seem to handle it.)

Generally speaking, if the latest certificate has the same key, then
it should cover the older ones, which can be dropped from the trust list.

If, however, the newer certificates have a different key, then everything
should work, provided the certificates issued under the new key carry
an "authority key identifier" extension, which matches the corresponding
"subject key identifier" in the issuer CA certificate.

The above also works with "authorityCertSerialNumber", see

   https://tools.ietf.org/html/rfc5280#section-4.2.1.1

If, however, the newer certificate has a different key, and the same
subject DN, but does not place matching distinct subject key identifiers
in the certificates it issues, then OpenSSL will not correctly handle
multiple candidate issuers that differ in the public key, but provide
no hints in the issued certificates which issuer to use.

-- 
Viktor.

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

Re: [openssl-users] Trusting certificates with the same subject name and overlapping validity periods

[Jordan Brown]

On 9/20/2017 10:28 AM, Walter H. via openssl-users wrote:
> On 20.09.2017 18:33, Jordan Brown wrote:
>>
>> Q:  Does OpenSSL's trust-list verification support trusting multiple
>> certificates with the same subject name and overlapping validity periods?
>>
> do these replacement certificates have the same serial number and the
> same private key?

I'll check with my colleague who is doing the actual work, but...

I assume that they do not have the same serial number, since they are
new certificates.

I don't know whether they have the same private key.  For discussion
purposes, let's say that they might or might not have the same key.

Remember that these are customer-controlled certificates; I don't get to
tell them how the certificates should be structured.

Note that this would be easy if each successive certificate had a
different Subject, because then the trust list could contain all of them
and there would be no possibility for confusion.  But they don't.

-- 
Jordan Brown, Oracle Solaris

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

Re: [openssl-users] Trusting certificates with the same subject name and overlapping validity periods

[Walter H. via openssl-users]

On 20.09.2017 18:33, Jordan Brown wrote:


Q:  Does OpenSSL's trust-list verification support trusting multiple 
certificates with the same subject name and overlapping validity periods?


do these replacement certificates have the same serial number and the 
same private key?




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

[openssl-users] Trusting certificates with the same subject name and overlapping validity periods

[Jordan Brown]

Q:  Does OpenSSL's trust-list verification support trusting multiple
certificates with the same subject name and overlapping validity periods?

In more detail:

We have customers who issue replacement certificates with the same
subject name and different validity periods.  We'd like to be able to
straightforwardly add the new certificates to the trust list and have
them work, but seem to find that certificate verification doesn't handle
the case.  (Mozilla NSS does seem to handle it.)

-- 
Jordan Brown, Oracle Solaris

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

Re: [openssl-users] X509 subject public key id-RSASSA-PSS

[Salz, Rich via openssl-users]

> Does your response mean, that RSA-PSS meanhile _is_ fully supported in 1.1.0?

I hesitate to  say fully, because there are no doubt parts that don't work.  
But RSAPSS signatures are supported.
But more importantly, 1.1.1 not 1.1.0

> Any estimations about how much work has to be done for adopting the newer 
> version?

It depends.  Almost all structures are opaque now, so you can't look inside at 
the fields direcdtly.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] X509 subject public key id-RSASSA-PSS

[weber]

Am 27.06.2017 um 14:18 schrieb Salz, Rich via openssl-users:


1.0.2 does not have full RSA-PSS support; you can’t use it.



Thanks Rich, in my case it works, because we partially do the 
verification (and algo selection) work externally.

We just need to access the public key which is rsa in both cases.

Does your response mean, that RSA-PSS meanhile _is_ fully supported in 
1.1.0?
Any estimations about how much work has to be done for adopting the 
newer version?


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

Re: [openssl-users] X509 subject public key id-RSASSA-PSS

[Salz, Rich via openssl-users]

1.0.2 does not have full RSA-PSS support; you can’t use it.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] X509 subject public key id-RSASSA-PSS

[weber]

Am 26.06.2017 um 22:30 schrieb Benjamin Kaduk:

On 06/25/2017 03:06 PM, we...@infotech.de wrote:

Dear OpenSSSL users,

we recently came across a certificate with OID: id-RSASSA-PSS aka 
rsassaPss in x509 subjects public key AlgorithmIdentifier.


According to rfc4056 it is legitimate to use rsaEncryption or 
id-RSASSA-PSS as OID for the subject public key.


But when listing the certs's contents or during verification, openssl 
v1.0.2h bails out:
12392:error:0609E09C:digital envelope 
routines:PKEY_SET_TYPE:unsupported algorithm:.\crypto\evp\p_lib.c:231:
12392:error:0B07706F:x509 certificate 
routines:X509_PUBKEY_get:unsupported 
algorithm:.\crypto\asn1\x_pubkey.c:148:
which is caused by failing to assign the proper ameth structure to 
the key.


Later in x_pubkey.c, only the method pub_decode is needed, which 
seems to work for rsassa pubkeys.
So may we assign the same methods associated to rsaEncryption in this 
case or are we breaking other functionality by doing so?


It might be more interesting to just try using the current OpenSSL 
master branch (or a snapshot), which has more proper RSA-PSS support.


-Ben


It's absolutely the same with Version 1.0.2l.
Due to time limitation we avoid updating to 1.1.0 as we assume that 
there will be several adaptations neccessary ...


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

Re: [openssl-users] (no subject)

[Matt Caswell]

On 27/06/17 01:05, Neetish Pathak wrote:
> Hi ,
> 
> 1) I am working with a client and server program and want to use
> ECDHE-ECDSA type ciphers.
> I see that default Elliptic curve group supported is X25519. (when I
> check client  and server logs on wireshark)
> I wish to generate a self-signed certificate for X25519 curve. But I am
> unable to do that the way I do for other curves like secp256r1,
> secp521r1 etc.
> 
> I generate a private key for secp521r1 using ecparam command and  then I
> generate the self-signed certificate.
> 
> openssl ecparam -name secp521r1 -genkey -param_enc named_curve -out
> server_key.pem
> 
> openssl req -new -x509 -key server_key.pem -out server_cert.pem -days 730
> 
> 
> On man page for X25519,
> 
> I found the command to generate private key
> 
> openssl genpkey -algorithm X25519 -out xkey.pem
> 
> But as I try to generate a self signed certificate, I am getting the
> following error
> 
> EVP_PKEY_sign_init:operation not supported for this keytype

It is not possible to "self-sign" an X25519 certificate because X25519
is a key-exchange algorithm only, not a digital signature algorithm. You
would not typically create an X25519 certificate at all but an Ed25519
one (only supported in the master branch).


> 
> 
> Could you please clarify where am I going wrong. Also, why is X25519 not
> mentioned
> 
> in ec curve list
> 
> using openssl ecparam -list_curves

X25519 is different. "Standard" EC keys can be used for ECDH or ECDSA.
X25519 keys are for X25519 only (similar to ECDH). Internally X25519 is
treated as a standalone algorithm and not integrated into the rest of
the EC logic.

> 
> 
> Any references to clarify my understanding will be appreciated.
> 
> 2) Also, can you direct me towards what hack is needed in Openssl to
> support pre-generated PSK in TLS 1.3 and false start in TLS 1.2 (for my
> study purpose).

For external PSKs in TLS1.3 (again only supported in master), you need
to use the new
SSL_CTX_set_psk_use_session_callback()/SSL_CTX_set_psk_find_session_callback()
APIs. See the man pages in master for this (for some reason I notice
that the documentation for this has not been updated on the website -
but it *is* in the doc/man3 folder in git).

> 
> Are you planning to integrate false start in OpenSSL any time. Thanks

I am not aware of anyone working on this.

Matt


> 
> Thanks
> 
> 
> Best Regards,
> Neetish
> 
> On Wed, Jun 21, 2017 at 3:17 PM, Neetish Pathak  > wrote:
> 
> 
> 
> On Wed, Jun 21, 2017 at 3:11 AM, Matt Caswell  > wrote:
> 
> 
> 
> On 21/06/17 00:38, Neetish Pathak wrote:
> > I wanted to understand the replay attack vulnerability in case of 
> enable
> > early data of TLS 1.3 while false start is secure in that respect 
> as I
> > have read from https://github.com/openssl/openssl/issues/1541
> 
> > So, with false start, the application data is sent from client 
> after the
> > first leg of the handshake i.e. one round trip is complete, so the 
> data
> > goes encrypted even though the handshake is not completed. In enable
> > early data mode in TLS 1.3 for 0-RTT for session resumption, the
> > application data is sent from the client along with the client hello
> > message. Does the application data in early data mode go as clear 
> text ?
> 
> No, it is encrypted using a traffic key derived from the PSK.
> 
> > I assume this is also encrypted using the PSK because 0-RTT is only
> > applicable when PSK is available on the client side. How is it
> > vulnerable to replay attack. Please help me understand.
> 
> The same PSK can be used multiple times. Because the traffic key
> for the
> early data is derived from the PSK, if you later re-use the PSK
> and send
> early data again then the same traffic key will be derived. This
> can be
> exploited by an attacker who can record the early data from an
> earlier
> session and replay it later. The server will think that the replayed
> data is a new connection and process the early data accordingly.
> 
> Early data (aka 0-RTT data) can be dangerous if not used
> properly. For
> this reason the current TLSv1.3 draft makes this note:
> 
>Protocols MUST NOT use 0-RTT data without a profile that
> defines its
>use.  That profile needs to identify which messages or
> interactions
>are safe to use with 0-RTT.  In addition, to avoid accidental
> misuse,
>implementations SHOULD NOT enable 0-RTT unless specifically
>requested.  Implementations SHOULD provide special functions for
>0-RTT data to ensure that an application is always aware that
>   

[openssl-users] (no subject)

[Neetish Pathak]

Hi ,

1) I am working with a client and server program and want to use
ECDHE-ECDSA type ciphers.
I see that default Elliptic curve group supported is X25519. (when I check
client  and server logs on wireshark)
I wish to generate a self-signed certificate for X25519 curve. But I am
unable to do that the way I do for other curves like secp256r1, secp521r1
etc.

I generate a private key for secp521r1 using ecparam command and  then I
generate the self-signed certificate.

openssl ecparam -name secp521r1 -genkey -param_enc named_curve -out
server_key.pem

openssl req -new -x509 -key server_key.pem -out server_cert.pem -days 730


On man page for X25519,

I found the command to generate private key

openssl genpkey -algorithm X25519 -out xkey.pem

But as I try to generate a self signed certificate, I am getting the
following error

EVP_PKEY_sign_init:operation not supported for this keytype


Could you please clarify where am I going wrong. Also, why is X25519 not
mentioned

in ec curve list

using openssl ecparam -list_curves


Any references to clarify my understanding will be appreciated.

2) Also, can you direct me towards what hack is needed in Openssl to
support pre-generated PSK in TLS 1.3 and false start in TLS 1.2 (for my
study purpose).

Are you planning to integrate false start in OpenSSL any time. Thanks

Thanks


Best Regards,
Neetish

On Wed, Jun 21, 2017 at 3:17 PM, Neetish Pathak  wrote:

>
>
> On Wed, Jun 21, 2017 at 3:11 AM, Matt Caswell  wrote:
>
>>
>>
>> On 21/06/17 00:38, Neetish Pathak wrote:
>> > I wanted to understand the replay attack vulnerability in case of enable
>> > early data of TLS 1.3 while false start is secure in that respect as I
>> > have read from https://github.com/openssl/openssl/issues/1541
>> > So, with false start, the application data is sent from client after the
>> > first leg of the handshake i.e. one round trip is complete, so the data
>> > goes encrypted even though the handshake is not completed. In enable
>> > early data mode in TLS 1.3 for 0-RTT for session resumption, the
>> > application data is sent from the client along with the client hello
>> > message. Does the application data in early data mode go as clear text ?
>>
>> No, it is encrypted using a traffic key derived from the PSK.
>>
>> > I assume this is also encrypted using the PSK because 0-RTT is only
>> > applicable when PSK is available on the client side. How is it
>> > vulnerable to replay attack. Please help me understand.
>>
>> The same PSK can be used multiple times. Because the traffic key for the
>> early data is derived from the PSK, if you later re-use the PSK and send
>> early data again then the same traffic key will be derived. This can be
>> exploited by an attacker who can record the early data from an earlier
>> session and replay it later. The server will think that the replayed
>> data is a new connection and process the early data accordingly.
>>
>> Early data (aka 0-RTT data) can be dangerous if not used properly. For
>> this reason the current TLSv1.3 draft makes this note:
>>
>>Protocols MUST NOT use 0-RTT data without a profile that defines its
>>use.  That profile needs to identify which messages or interactions
>>are safe to use with 0-RTT.  In addition, to avoid accidental misuse,
>>implementations SHOULD NOT enable 0-RTT unless specifically
>>requested.  Implementations SHOULD provide special functions for
>>0-RTT data to ensure that an application is always aware that it is
>>sending or receiving data that might be replayed.
>>
>>
>> >
>> > Is there any API available in OpenSSL for false start ?
>>
>> No, OpenSSL does not support false start. As an aside please note that
>> false start only applies to <= TLSv1.2.
>
>
> Thanks for your comments.
>
> I need some direction on the doing server and client side authentication
> during the handshake.
>
> *1) For certificate sent from the server side, I am using*
>
> SSL_CTX_load_verify_locations(ssl_ctx, CAFILE, NULL))   for loading
> verification file *on the client side*
>
> Where do I get a CAFILE in the above API. If the server is sending a self
> signed certificate, what will be the CA file on the client side for
> verification.
>
>
> *2) For Client side authentication*
>
> I am using SSL_CTX_use_PrivateKey_file and SSL_CTX_use_certificate file
> on the client side to load the private key and the certificate.
> I read that client side authentication will not kick off unless the server
> sends CertificateRequest. I can use SSL_CTX_set_client_cert_cb() that
> sets the client_cert_cb() callback to be called on CertificateRequest.
>
> I am not sure how I can enable the server side to send CertificateRequest.
> What is the API for that.
> Should SSL_CTX_set_verify((ssl_ctx,SSL_VERIFY_PEER, NULL)) be used on
> server side for sending the certificateRequest message. Please correct me ?
>
> *3) Certificate request Message*
> Also, what is the use of 

Re: [openssl-users] X509 subject public key id-RSASSA-PSS

[Benjamin Kaduk via openssl-users]

On 06/25/2017 03:06 PM, we...@infotech.de wrote:
> Dear OpenSSSL users,
>
> we recently came across a certificate with OID: id-RSASSA-PSS aka
> rsassaPss in x509 subjects public key AlgorithmIdentifier.
>
> According to rfc4056 it is legitimate to use rsaEncryption or
> id-RSASSA-PSS as OID for the subject public key.
>
> But when listing the certs's contents or during verification, openssl
> v1.0.2h bails out:
>> 12392:error:0609E09C:digital envelope
>> routines:PKEY_SET_TYPE:unsupported algorithm:.\crypto\evp\p_lib.c:231:
>> 12392:error:0B07706F:x509 certificate
>> routines:X509_PUBKEY_get:unsupported
>> algorithm:.\crypto\asn1\x_pubkey.c:148:
> which is caused by failing to assign the proper ameth structure to the
> key.
>
> Later in x_pubkey.c, only the method pub_decode is needed, which seems
> to work for rsassa pubkeys.
> So may we assign the same methods associated to rsaEncryption in this
> case or are we breaking other functionality by doing so?

It might be more interesting to just try using the current OpenSSL
master branch (or a snapshot), which has more proper RSA-PSS support.

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

[openssl-users] X509 subject public key id-RSASSA-PSS

[weber]

Dear OpenSSSL users,

we recently came across a certificate with OID: id-RSASSA-PSS aka 
rsassaPss in x509 subjects public key AlgorithmIdentifier.


According to rfc4056 it is legitimate to use rsaEncryption or 
id-RSASSA-PSS as OID for the subject public key.


But when listing the certs's contents or during verification, openssl 
v1.0.2h bails out:
12392:error:0609E09C:digital envelope 
routines:PKEY_SET_TYPE:unsupported algorithm:.\crypto\evp\p_lib.c:231:
12392:error:0B07706F:x509 certificate 
routines:X509_PUBKEY_get:unsupported 
algorithm:.\crypto\asn1\x_pubkey.c:148:

which is caused by failing to assign the proper ameth structure to the key.

Later in x_pubkey.c, only the method pub_decode is needed, which seems 
to work for rsassa pubkeys.
So may we assign the same methods associated to rsaEncryption in this 
case or are we breaking other functionality by doing so?


Thanks
--
Christian Weber

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

Re: [openssl-users] CSR with multiple subject names?

[Jakob Bohm]

On 01/06/2017 16:26, l vic wrote:
I am working with service with TLS authn that uses subject name to 
authenticate client.
Is it possible to use list of subject names in client certificate so 
that service could authenticate several clients with the same 
key/certificate? If not, would it be possible to use alternative 
subject names for the same purpose? Can SANs only used in the context 
of DNS domains, eg to authenticate the same subject name calling from 
different DNS domains?

SANs (SubjectAlternativeNames) can contain all the name types
(unlike the main Subject, which can only contain a backwards
compatible DirectoryName).

Depending on what kind of identity a server wants to identify,
good choices for user identifying SANs are:

 - rfc822Name ("u...@sub.domain.tld")
 - DirectoryName (CN=First Middle Last, OU=Department, O=Example 
company, street=SomeRoad 123, L=12345 SomeCity, ST=SomeState, C=US)


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

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

Re: [openssl-users] CSR with multiple subject names?

[Salz, Rich via openssl-users]

By default, TLS only does server-side verification.  If you are using client 
certificates, you will have to write some code for your application.

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] CSR with multiple subject names?

[l vic]

I am working with service with TLS authn that uses subject name to
authenticate client.
Is it possible to use list of subject names in client certificate so that
service could authenticate several clients with the same key/certificate?
If not, would it be possible to use alternative subject names for the same
purpose? Can SANs only used in the context of DNS domains, eg to
authenticate the same subject name calling from different DNS domains?
Thank you,
lvic
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] (no subject)

[CÔNG NGUYỄN VĂN]

Nguyễn Văn Công.pdf




-- 
Nguyễn Văn Công
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] C++ How to parse Subject Directory Attributes Extension?

[Matthias Ballreich]

Thanks for reply.
Ohh that's bad news. So I have will look at the various d2i_XXX and i2d_XXX 
functions you mentioned.


Von: openssl-users [mailto:openssl-users-boun...@openssl.org] Im Auftrag von 
Salz, Rich via openssl-users
Gesendet: Dienstag, 9. Mai 2017 15:55
An: openssl-users@openssl.org
Betreff: Re: [openssl-users] C++ How to parse Subject Directory Attributes 
Extension?

That attribute is not currently supported.

Someone would have to write ASN1 parsing code.  There are examples all over the 
place within OpenSSL; see the various d2i_XXX and i2d_XXX functions.  There are 
macro/define's available to make the job easier.  But, it is not really 
documented.

Maybe there are other people here who are interested, and could write the code 
and make a pull request on GitHub.

I doubt the team will get to it quickly.  Sorry, but I just want to be 
realistic.

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at<mailto:richs...@jabber.at> Twitter: RichSalz
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] C++ How to parse Subject Directory Attributes Extension?

[Matthias Ballreich]

I will take a look on it. Thanks.
Can you explain it a little bit more what you mean with "You can either add a 
custom extension or just parse the structure from the extentsion contents." ?





-Ursprüngliche Nachricht-
Von: openssl-users [mailto:openssl-users-boun...@openssl.org] Im Auftrag von 
Dr. Stephen Henson
Gesendet: Dienstag, 9. Mai 2017 18:06
An: openssl-users@openssl.org
Betreff: Re: [openssl-users] C++ How to parse Subject Directory Attributes 
Extension?

On Tue, May 09, 2017, Matthias Ballreich wrote:

> Here are nor some more details, which may help you to better understand.
> 
> 
> My Certificate contains the SubjectDirectoryAttributes-Extension with the 
> following Attributes:
> 
> OID   : Value
> ---
> (1.3.6.1.5.5.7.9.4) countryOfCitizenship  : DE
> (1.3.6.1.5.5.7.9.3) gender: F
> (1.3.6.1.5.5.7.9.1) dateOfBirth   : 1971-10-14 12:00:00 UTC
> (1.3.6.1.5.5.7.9.2) placeOfBirth  : Darmstadt
> 
> So i want to get these pairs of OID and Value.
> 
> I found no Struct like SUBJECT_DIRECTORY_ATTRIBUTES in the Source-Code i can 
> use. I got the Extension this way:
> 
> int loc = X509_get_ext_by_NID(certificate, 
> NID_subject_directory_attributes, -1); X509_EXTENSION *ex = 
> X509_get_ext(certificate, loc);
> 
> But how can i get then all the data, which means all the OIDs and Values to 
> the OIDs? The ASN.1 Structure is:
> 
> SubjectDirectoryAttributes ::= Attributes
> 
> Attributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
> 
> Attribute ::= SEQUENCE
> {
> type AttributeType
> values SET OF AttributeValue
> }
> 
> AttributeType ::= OBJECT IDENTIFIER
> AttributeValue ::= ANY DEFINED BY AttributeType
> 
> I found out that i get a custom extension with: X509_EXTENSION_get_object(ex) 
> and that the OpenSSL-Type X509_NAME_ENTRY is the equvivalent to the 
> ASN.1-Structure Attribute resp. AttributeTypeAndValue. So i tried to cast the 
> result of X509_EXTENSION_get_data(ex) to a STACK_OF(X509_NAME_ENTRY) and to 
> X509_NAME. But X509_NAME is the same as STACK_OF(X509_NAME_ENTRY).
> 
> Then i tried to get the number of attributes by calling the 
> sk_X509_NAME_ENTRY_num() function on the STACK_OF(X509_NAME_ENTRY) resp. 
> X509_NAME.entries, but i got not the right number. I expect to get the number 
> 3 or 4 (don't know the exactly internal counting - but the example cert 
> contains 4 Attributes, so the output should be 3 or 4 depending if the 
> counting will start at 0 or 1). But instead of 3 or 4 i got a much larger 
> number like 34335029 and this number is different every time i run the code. 
> So i think there is a problem with the casting or i did not choose the right 
> Data-Type(s).
> 
> I'm using OpenSSL 1.0.2j.
> 
> So what's wrong and how can i fix it? - Thanks in advice!
> 

Looks like the type isn't X509_NAME_ENTRY but X509_ATTRIBUTE and the extension 
is a SEQUENCE OF Attribute. We don't have the direct equivalent as a specific 
type IIRC but it isn't hard to add one just follow what is done for 
GENERAL_NAMES which is a SEQUENCE OF GENERAL_NAME.

You can either add a custom extension or just parse the structure from the 
extentsion contents.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] C++ How to parse Subject Directory Attributes Extension?

[Dr. Stephen Henson]

On Tue, May 09, 2017, Matthias Ballreich wrote:

> Here are nor some more details, which may help you to better understand.
> 
> 
> My Certificate contains the SubjectDirectoryAttributes-Extension with the 
> following Attributes:
> 
> OID   : Value
> ---
> (1.3.6.1.5.5.7.9.4) countryOfCitizenship  : DE
> (1.3.6.1.5.5.7.9.3) gender: F
> (1.3.6.1.5.5.7.9.1) dateOfBirth   : 1971-10-14 12:00:00 UTC
> (1.3.6.1.5.5.7.9.2) placeOfBirth  : Darmstadt
> 
> So i want to get these pairs of OID and Value.
> 
> I found no Struct like SUBJECT_DIRECTORY_ATTRIBUTES in the Source-Code i can 
> use. I got the Extension this way:
> 
> int loc = X509_get_ext_by_NID(certificate, NID_subject_directory_attributes, 
> -1);
> X509_EXTENSION *ex = X509_get_ext(certificate, loc);
> 
> But how can i get then all the data, which means all the OIDs and Values to 
> the OIDs? The ASN.1 Structure is:
> 
> SubjectDirectoryAttributes ::= Attributes
> 
> Attributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
> 
> Attribute ::= SEQUENCE
> {
> type AttributeType
> values SET OF AttributeValue
> }
> 
> AttributeType ::= OBJECT IDENTIFIER
> AttributeValue ::= ANY DEFINED BY AttributeType
> 
> I found out that i get a custom extension with: X509_EXTENSION_get_object(ex) 
> and that the OpenSSL-Type X509_NAME_ENTRY is the equvivalent to the 
> ASN.1-Structure Attribute resp. AttributeTypeAndValue. So i tried to cast the 
> result of X509_EXTENSION_get_data(ex) to a STACK_OF(X509_NAME_ENTRY) and to 
> X509_NAME. But X509_NAME is the same as STACK_OF(X509_NAME_ENTRY).
> 
> Then i tried to get the number of attributes by calling the 
> sk_X509_NAME_ENTRY_num() function on the STACK_OF(X509_NAME_ENTRY) resp. 
> X509_NAME.entries, but i got not the right number. I expect to get the number 
> 3 or 4 (don't know the exactly internal counting - but the example cert 
> contains 4 Attributes, so the output should be 3 or 4 depending if the 
> counting will start at 0 or 1). But instead of 3 or 4 i got a much larger 
> number like 34335029 and this number is different every time i run the code. 
> So i think there is a problem with the casting or i did not choose the right 
> Data-Type(s).
> 
> I'm using OpenSSL 1.0.2j.
> 
> So what's wrong and how can i fix it? - Thanks in advice!
> 

Looks like the type isn't X509_NAME_ENTRY but X509_ATTRIBUTE and the extension
is a SEQUENCE OF Attribute. We don't have the direct equivalent as a specific
type IIRC but it isn't hard to add one just follow what is done for
GENERAL_NAMES which is a SEQUENCE OF GENERAL_NAME.

You can either add a custom extension or just parse the structure from the
extentsion contents.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] C++ How to parse Subject Directory Attributes Extension?

[Salz, Rich via openssl-users]

That attribute is not currently supported.

Someone would have to write ASN1 parsing code.  There are examples all over the 
place within OpenSSL; see the various d2i_XXX and i2d_XXX functions.  There are 
macro/define’s available to make the job easier.  But, it is not really 
documented.

Maybe there are other people here who are interested, and could write the code 
and make a pull request on GitHub.

I doubt the team will get to it quickly.  Sorry, but I just want to be 
realistic.

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] C++ How to parse Subject Directory Attributes Extension?

[Matthias Ballreich]

Here are nor some more details, which may help you to better understand.


My Certificate contains the SubjectDirectoryAttributes-Extension with the 
following Attributes:

OID   : Value
---
(1.3.6.1.5.5.7.9.4) countryOfCitizenship  : DE
(1.3.6.1.5.5.7.9.3) gender: F
(1.3.6.1.5.5.7.9.1) dateOfBirth   : 1971-10-14 12:00:00 UTC
(1.3.6.1.5.5.7.9.2) placeOfBirth  : Darmstadt

So i want to get these pairs of OID and Value.

I found no Struct like SUBJECT_DIRECTORY_ATTRIBUTES in the Source-Code i can 
use. I got the Extension this way:

int loc = X509_get_ext_by_NID(certificate, NID_subject_directory_attributes, 
-1);
X509_EXTENSION *ex = X509_get_ext(certificate, loc);

But how can i get then all the data, which means all the OIDs and Values to the 
OIDs? The ASN.1 Structure is:

SubjectDirectoryAttributes ::= Attributes

Attributes ::= SEQUENCE SIZE (1..MAX) OF Attribute

Attribute ::= SEQUENCE
{
type AttributeType
values SET OF AttributeValue
}

AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY DEFINED BY AttributeType

I found out that i get a custom extension with: X509_EXTENSION_get_object(ex) 
and that the OpenSSL-Type X509_NAME_ENTRY is the equvivalent to the 
ASN.1-Structure Attribute resp. AttributeTypeAndValue. So i tried to cast the 
result of X509_EXTENSION_get_data(ex) to a STACK_OF(X509_NAME_ENTRY) and to 
X509_NAME. But X509_NAME is the same as STACK_OF(X509_NAME_ENTRY).

Then i tried to get the number of attributes by calling the 
sk_X509_NAME_ENTRY_num() function on the STACK_OF(X509_NAME_ENTRY) resp. 
X509_NAME.entries, but i got not the right number. I expect to get the number 3 
or 4 (don't know the exactly internal counting - but the example cert contains 
4 Attributes, so the output should be 3 or 4 depending if the counting will 
start at 0 or 1). But instead of 3 or 4 i got a much larger number like 
34335029 and this number is different every time i run the code. So i think 
there is a problem with the casting or i did not choose the right Data-Type(s).

I'm using OpenSSL 1.0.2j.

So what's wrong and how can i fix it? - Thanks in advice!

Here a short excerpt of my code:
X509_EXTENSION *ex = 

STACK_OF(X509_NAME_ENTRY) *st = (STACK_OF(X509_NAME_ENTRY)*) 
X509_EXTENSION_get_data(ex);
printf(sk_X509_NAME_ENTRY_num(st));

// or alternative

X509_Name *name = (X509_Name*) X509_EXTENSION_get_data(ex);
printf(sk_X509_NAME_ENTRY_num(name.entries));

Here i append the certificate if you need it. It's from the RFC specification:

-BEGIN CERTIFICATE-
MIIDEDCCAnmgAwIBAgIESZYC0jANBgkqhkiG9w0BAQUFADBIMQswCQYDVQQGEwJE
RTE5MDcGA1UECgwwR01EIC0gRm9yc2NodW5nc3plbnRydW0gSW5mb3JtYXRpb25z
dGVjaG5payBHbWJIMB4XDTA0MDIwMTEwMDAwMFoXDTA4MDIwMTEwMDAwMFowZTEL
MAkGA1UEBhMCREUxNzA1BgNVBAoMLkdNRCBGb3JzY2h1bmdzemVudHJ1bSBJbmZv
cm1hdGlvbnN0ZWNobmlrIEdtYkgxHTAMBgNVBCoMBVBldHJhMA0GA1UEBAwGQmFy
emluMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDc50zVodVa6wHPXswg88P8
p4fPy1caIaqKIK1d/wFRMN5yTl7T+VOS57sWxKcdDzGzqZJqjwjqAP3DqPK7AW3s
o7lBG6JZmiqMtlXG3+olv+3cc7WU+qDv5ZXGEqauW4x/DKGc7E/nq2BUZ2hLsjh9
Xy9+vbw+8KYE9rQEARdpJQIDAQABo4HpMIHmMGQGA1UdCQRdMFswEAYIKwYBBQUH
CQQxBBMCREUwDwYIKwYBBQUHCQMxAxMBRjAdBggrBgEFBQcJATERGA8xOTcxMTAx
NDEyMDAwMFowFwYIKwYBBQUHCQIxCwwJRGFybXN0YWR0MA4GA1UdDwEB/wQEAwIG
QDASBgNVHSAECzAJMAcGBSskCAEBMB8GA1UdIwQYMBaAFAABAgMEBQYHCAkKCwwN
Dg/+3LqYMDkGCCsGAQUFBwEDBC0wKzApBggrBgEFBQcLAjAdMBuBGW11bmljaXBh
bGl0eUBkYXJtc3RhZHQuZGUwDQYJKoZIhvcNAQEFBQADgYEAj4yAu7LYa3X04h+C
7+DyD2xViJCm5zEYg1m5x4znHJIMZsYAU/vJJIJQkPKVsIgm6vP/H1kXyAu0g2Ep
z+VWPnhZK1uw+ay1KRXw8rw2mR8hQ2Ug6QZHYdky2HH3H/69rWSPp888G8CW8RLU
uIKzn+GhapCuGoC4qWdlGLWqfpc=
-END CERTIFICATE-



Von: Matthias Ballreich <matthias.ballre...@outlook.de>
Gesendet: Sonntag, 30. April 2017 13:44:48
An: openssl-users@openssl.org
Betreff: C++ How to parse Subject Directory Attributes Extension?


Hi there,


can anyone tell me how to parse a the Subject Directory Attribute Extension of 
a X509-Certificate in C++ with OpenSSL? I don't found any documentation or 
piece of code in the Github Repo of OpenSSL.


I read the Extension this way:

int loc = X509_get_ext_by_NID(cert, NID_subject_directory_attributes, -1);
X509_EXTENSION *ex = X509_get_ext(cert, loc);

But i stuck on how to continue and get the TypeValue-Stuff.
Would be very helpful if someone can help me.

thanks and best regards
Matthias

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

[openssl-users] C++ How to parse Subject Directory Attributes Extension?

[Matthias Ballreich]

Hi there,


can anyone tell me how to parse a the Subject Directory Attribute Extension of 
a X509-Certificate in C++ with OpenSSL? I don't found any documentation or 
piece of code in the Github Repo of OpenSSL.


I read the Extension this way:

int loc = X509_get_ext_by_NID(cert, NID_subject_directory_attributes, -1);
X509_EXTENSION *ex = X509_get_ext(cert, loc);

But i stuck on how to continue and get the TypeValue-Stuff.
Would be very helpful if someone can help me.

thanks and best regards
Matthias

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

Re: [openssl-users] Escaped Issuer/Subject

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of c.hol...@ades.at
> Sent: Wednesday, April 12, 2017 00:47
> 
> I thought about escaping regarding DN itself (LDAP DN).

It's an X.400 DN. LDAP is a protocol and an API; there's no necessary 
relationship between X.509 certificates and LDAP.

More importantly, escaping is an aspect of interpretation, not source. If you 
need an X.400 DN escaped in, say, an LDAP context such as a value in a search 
filter, that's a requirement of LDAP, and the transformation is determined by 
LDAP. It is not a property of the "DN itself". Escaping a DN for a particular 
context is no different from escaping any other string for that context.

Your conceptual model is wrong, and that is a Bad Thing, particularly with 
escaping. Having the wrong conceptual model when escaping data leads to 
difficult-to-find errors and security vulnerabilities.

Rich has mentioned -nameopt and its implementing code, which may serve as a 
guide. But they're unlikely to precisely meet your requirements, whatever they 
actually are.

Michael Wojcik 
Distinguished Engineer, Micro Focus 


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

Re: [openssl-users] Escaped Issuer/Subject

[Salz, Rich via openssl-users]

> I thought about escaping regarding DN itself (LDAP DN).

Look up the -nameopt flag in, say, x509.pod  Then if you need C code, trace 
through what apps/x509.c does.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Escaped Issuer/Subject

[c.hol...@ades.at]

I thought about escaping regarding DN itself (LDAP DN).

https://www.ietf.org/rfc/rfc4514.txt

https://www.ibm.com/support/knowledgecenter/en/ssw_i5_54/rzahy/rzahyunderdn.htm

https://msdn.microsoft.com/en-us/library/aa366101%28v=vs.85%29.aspx

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