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 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

[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

[openssl-users] (no subject)

[russellbell]

>From russellb...@gmail.com Fri Feb 17 09:50:52 MST 2017
to:  openssl-users-requ...@openssl.org
subject:  set digest

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

Re: [openssl-users] (no subject)

[Jeffrey Walton]

On Fri, Aug 26, 2016 at 6:56 PM, Juliano Souza  wrote:
> I just found it.
>
> Hope to help someone with same requirement.
>
> http://www.cafesoft.com/products/cams/ps/docs32/admin/ConfiguringApache2ForSSLTLSMutualAuthentication.html
>

There's also Origin Bound Certificates (OCB),
http://www.czeskis.com/research/pubs/tls-obc.pdf. They are like
"tear-off" personal certificates. A user generates one on the fly for
an origin/site, and then uses it when needed. Its not signed by an
authority, so its like the user equivalent to a server's self signed
certificate.

The appealing thing with them is they effectively stop the MitM games
played by many user agents. Not surprisingly, the browser have mostly
rejected them because in their security model, interception is a valid
use case.

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

Re: [openssl-users] (no subject)

[Juliano Souza]

I just found it.

Hope to help someone with same requirement.

http://www.cafesoft.com/products/cams/ps/docs32/admin/ConfiguringApache2ForSSLTLSMutualAuthentication.html

2016-08-26 17:16 GMT-03:00 Juliano Souza :

> Hi!
>
>
>
> In order to authenticate users without user and password, I’d like to
> generate users .p12 .pfx certificates to install on their browsers and
> identify them by CN.
>
>
>
> Is there any howto or tutorial explaining some of...
>
>
>
> 1-Generate my own CA
>
> 2-Generate users .p12 / .pfx certs ?
>
> 3-In apache how to verify client certificate, if some user try to connect
> my URL without this p12/pfx, access is denied.
>
>
>
> Is there a lot of documentation (googling), but very old or incomplete.
>
>
>
> My set is ; centos 7.2 | Apache 2.4.6 | openssl 1.0.1e-fips
>
>
>
> Thank you and best regards,
>
> --
> Juliano Souza
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>


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

[openssl-users] (no subject)

[Juliano Souza]

Hi!



In order to authenticate users without user and password, I’d like to
generate users .p12 .pfx certificates to install on their browsers and
identify them by CN.



Is there any howto or tutorial explaining some of...



1-Generate my own CA

2-Generate users .p12 / .pfx certs ?

3-In apache how to verify client certificate, if some user try to connect
my URL without this p12/pfx, access is denied.



Is there a lot of documentation (googling), but very old or incomplete.



My set is ; centos 7.2 | Apache 2.4.6 | openssl 1.0.1e-fips



Thank you and best regards,

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

[openssl-users] (no subject)

[Prabhat Puroshottam]

We are using session resumption with openssl, and to support that we are 
storing sessions in a file.

On the server side the allowed TLS version can be configured and server admin 
can change it. It can

be changed for example to allow only TLS 1.2. The problem is that if the client 
has SSL session

stored on the disk from a previous connection which has different TLS version 
than what server

expects as per the changed configuration, server drops the connection 
immediately.


My question is, is it possible for Openssl server to recover from such a 
scenario, by starting a full

handshake? Right now server drops the connection because of protocol mismatch.

Because if that is not the case the only other option left for us is to 
reconnect again if server rejects

connection.


Thanks,

Prabhat

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

Re: [openssl-users] X509 subject key identifier

[Ken Goldman]

This (of course) worked.  I have three further questions.

1 - Am I correct that "data" points to the internal structure, and so 
"skid" should not be freed until I'm done with "data"?


2 - For my education, I thought that d2i calls converted from DER to 
openssl internal format.  Yet, the input "subject" is an X509*, the 
internal format.


3 - Are these calls documented?  They're not in my usual starting point

https://www.openssl.org/docs/man1.0.1/crypto/

nor are they on the X509 page.

On 9/22/2015 1:25 AM, Viktor Dukhovni wrote:

On Mon, Sep 21, 2015 at 06:29:02PM -0400, Ken Goldman wrote:


How can I programmatically get the Subject Key Identifier as a byte array
from an X509 certificate.


Unless I'm mistaken:

 size_t len;
 unsigned char *data;
 ASN1_OCTET_STRING *skid;

 skid = X509_get_ext_d2i(subject, NID_subject_key_identifier, NULL, NULL);
 len = ASN1_STRING_length(skid);
 data = ASN1_STRING_data(skid);

 ... Take unspeakable liberties with "data" and "len" ...

 ASN1_OCTET_STRING_free(skid);




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

Re: [openssl-users] X509 subject key identifier

[Viktor Dukhovni]

On Tue, Sep 22, 2015 at 09:22:09AM -0400, Ken Goldman wrote:

> 1 - Am I correct that "data" points to the internal structure, and so "skid"
> should not be freed until I'm done with "data"?

Correct.  The "data" element is part of the ASN1_STRING (of type
ASN1_OCTET_STRING).

> 2 - For my education, I thought that d2i calls converted from DER to openssl
> internal format.  Yet, the input "subject" is an X509*, the internal format.

While the certificate object is already decoded, its extensions are not,
they are stored in DER form, and you need to extract them via suitable
decoding routines.

> 3 - Are these calls documented?  They're not in my usual starting point
> 
> https://www.openssl.org/docs/man1.0.1/crypto/
> 
> nor are they on the X509 page.

Sadly, they're not.  Please open a ticket that requests these be
documented.  There's a tiny example in

doc/HOWTO/proxy_certificates.txt

but it does not amount to documentation of the interface.
If you're really feeling generous, write the document.
The underlying interface is in crypto/x509v3/v3_lib.c:

/*-
 * Get critical flag and decoded version of extension from a NID.
 * The "idx" variable returns the last found extension and can
 * be used to retrieve multiple extensions of the same NID.
 * However multiple extensions with the same NID is usually
 * due to a badly encoded certificate so if idx is NULL we
 * choke if multiple extensions exist.
 * The "crit" variable is set to the critical value.
 * The return value is the decoded extension or NULL on
 * error. The actual error can have several different causes,
 * the value of *crit reflects the cause:
 * >= 0, extension found but not decoded (reflects critical value).
 * -1 extension not found.
 * -2 extension occurs more than once.
 */

void *X509V3_get_d2i(STACK_OF(X509_EXTENSION) *x, int nid, int *crit,
 int *idx)

Only certain "standard" extensions have default "d2i" methods.  The list
is in:

static const X509V3_EXT_METHOD *standard_exts[]

in the same file, but some legacy NetScape extensions are
defined in crypto/x509v3/v3_ia5.c:

const X509V3_EXT_METHOD v3_ns_ia5_list[]

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

Re: [openssl-users] X509 subject key identifier

[Viktor Dukhovni]

On Mon, Sep 21, 2015 at 06:29:02PM -0400, Ken Goldman wrote:

> How can I programmatically get the Subject Key Identifier as a byte array
> from an X509 certificate.

Unless I'm mistaken:

size_t len;
unsigned char *data;
ASN1_OCTET_STRING *skid;

skid = X509_get_ext_d2i(subject, NID_subject_key_identifier, NULL, NULL);
len = ASN1_STRING_length(skid);
data = ASN1_STRING_data(skid);

... Take unspeakable liberties with "data" and "len" ...

ASN1_OCTET_STRING_free(skid);

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

[openssl-users] X509 subject key identifier

[Ken Goldman]

How can I programmatically get the Subject Key Identifier as a byte 
array from an X509 certificate.


(Just to show that I tried before posting)

I would like the output as a byte array, not text, so tracing the 
X509_print_fp() gave clues but not an answer.


I have the general sense that it's within x509->cert_info_extensions, 
and that I use NID_subject_key_identifier to extract an extension from 
the stack.  Then I perhaps get the ASN1 object from the extension and 
from there the value.


Any leads?

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

[openssl-users] (no subject)

[ROBERTO Y MARIBEL]

WHAT

ROBERTO Y MARIBEL
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] (no subject)

[Sørebø Linda]

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