Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

2018-01-19 Thread Viktor Dukhovni 


> On Jan 19, 2018, at 10:09 PM, Frank Migge  wrote:
> 
> >> Object 04: X509v3 Extended Key Usage: TLS Web Server Authentication
> 
> This is were I would check first. 
> 
> I am not fully sure, but believe that Extended Key Usage should *not* be 
> there.

Indeed the intermediate CA should either not have an extendedKeyUsage, or that
keyUsage should include the desired "purpose".  The handling of the purpose of
intermediate certificates was made more uniform in OpenSSL 1.1.0 (whether the
certificate is from the cert store or the remote peer is no longer material).
This and related changes can affect whether a chain is still valid with 1.1.0
and beyond.

-- 
Viktor.

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

Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

2018-01-19 Thread Frank Migge 
I got it wrong. The failing cert from your log is actually the
intermediate, which has five extensions:

>> Object 00: X509v3 Subject Key Identifier:
58:A4:EB:D9:DD:CE:A2:99:72:3B:E1:20:19:1D:40:C1:F9:D5:C2:28
>> Object 01: X509v3 Authority Key Identifier:
keyid:E2:E9:20:42:29:83:C4:77:8C:87:AB:FA:4B:A1:A9:C4:CE:00:BD:39
>> Object 02: X509v3 Basic Constraints: CA:TRUE, pathlen:0
>> Object 03: X509v3 Key Usage: Digital Signature, Certificate Sign, CRL
Sign
>> Object 04: X509v3 Extended Key Usage: TLS Web Server Authentication

This is were I would check first.

I am not fully sure, but believe that Extended Key Usage should *not* be
there.

Frank

> Frank Migge 
> Saturday, January 20, 2018 11:29 AM
> Hi Robert,
>
>>> error 26 : unsupported certificate purpose
>
> It seems the cert gets declined because of a problem with cert
> extensions. "keyUsage" or "extendedKeyUsage" are typical candidates. In
> your case, the leaf certificate "CAPF-91d43ef6" has two extensions:
>
> Object 00: X509v3 Key Usage
>   Digital Signature, Key Encipherment
>
> Object 01: X509v3 Extended Key Usage
>   TLS Web Server Authentication, TLS Web Client Authentication, IPSec End 
> System
>
> I would check if an extension is now missing/newly required, or no
> longer recognized. Try check for differences in the openssl.cnf and
> freeradius config files between the old Debian system and the new one.
>
> Some EAP TLS guides (incl. Cisco) also list extensions "nonRepudiation" and 
> "dataEncipherment", but this is just a guess since you mentioned it works on 
> the old system.
>
>>> I have some problems with new Cisco CAPF certs
>
> What is the authenticating device? Cisco IP phone?
>
> Cheers,
> Frank
> Gladewitz, Robert via openssl-users 
> Friday, January 19, 2018 11:12 PM
>
> Dear OpenSSL Team,
>
>  
>
> I have some problems with new Cisco CAPF certs and freeradius tls
> authentification. The point is, that freeradius users see the problem
> on openssl implemtiation.
>
>  
>
> 
>
> (69) eap_tls: Continuing EAP-TLS
>
> (69) eap_tls: Peer indicated complete TLS record size will be 1432 bytes
>
> (69) eap_tls: Got complete TLS record (1432 bytes)
>
> (69) eap_tls: [eaptls verify] = length included
>
> (69) eap_tls: TLS_accept: SSLv3/TLS write server done
>
> (69) eap_tls: <<< recv TLS 1.0 Handshake [length 03c2], Certificate
>
> (69) eap_tls: Creating attributes from certificate OIDs
>
> (69) eap_tls:   TLS-Cert-Serial := "1009"
>
> (69) eap_tls:   TLS-Cert-Expiration := "38025719Z"
>
> (69) eap_tls:   TLS-Cert-Subject := "/C=DE/ST=Sachsen/L=Leipzig/O=DBFZ
> Deutsches Biomasseforschungszentrum gGmbH/OU=IT/CN=CAPF-91d43ef6"
>
> (69) eap_tls:   TLS-Cert-Issuer := "/C=DE/ST=Sachsen/L=Leipzig/O=DBFZ
> Deutsches Biomasseforschungszentrum gemeinnuetzige GmbH/OU=IT/CN=DBFZ
> CA INTERN ROOT/emailAddress=supp...@dbfz.de
> "
>
> (69) eap_tls:   TLS-Cert-Common-Name := "CAPF-91d43ef6"
>
> (69) eap_tls:   ERROR: SSL says error 26 : unsupported certificate purpose
>
> (69) eap_tls: >>> send TLS 1.0 Alert [length 0002], fatal
> unsupported_certificate
>
> (69) eap_tls: ERROR: TLS Alert write:fatal:unsupported certificate
>
> tls: TLS_accept: Error in error
>
> (69) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read):
> error:1417C086:SSL routines:tls_process_client_certificate:certificate
> verify failed
>
> (69) eap_tls: ERROR: System call (I/O) error (-1)
>
> (69) eap_tls: ERROR: TLS receive handshake failed during operation
>
> (69) eap_tls: ERROR: [eaptls process] = fail 
>
> 
>
>  
>
> This means, that the check of ca certificate is failed. So, bu I do
> not see, why. If i check the certificate by command openssl –verify,
> all sems to be right.
>
> # openssl verify -verbose -CAfile
> /etc/freeradius/3.0/certs.8021x.ciscophone/cacert.capf.pem
> SEP64A0E714844E-L1.pem
>
> # SEP64A0E714844E-L1.pem: OK
>
>  
>
>  
>
> The openssl version is Debian based 1.1.0g-2. But the same error is
> happening on 1.1.0f also.
>
>  
>
> Older freeradius version 2 on Debian 8/openssl 1.0.1t-1+deb8u7 working
> fine without this problem (by using the same certificates)
>
>  
>
> The ca certificate are signed by an intern ca. Can anyone see the error??
>
>  
>
> Robert
>
>  
>
>  
>
>  
>

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

Re: [openssl-users] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

2018-01-19 Thread Frank Migge 
Hi Robert,

>> error 26 : unsupported certificate purpose

It seems the cert gets declined because of a problem with cert
extensions. "keyUsage" or "extendedKeyUsage" are typical candidates. In
your case, the leaf certificate "CAPF-91d43ef6" has two extensions:

Object 00: X509v3 Key Usage
  Digital Signature, Key Encipherment

Object 01: X509v3 Extended Key Usage
  TLS Web Server Authentication, TLS Web Client Authentication, IPSec End System

I would check if an extension is now missing/newly required, or no
longer recognized. Try check for differences in the openssl.cnf and
freeradius config files between the old Debian system and the new one.

Some EAP TLS guides (incl. Cisco) also list extensions "nonRepudiation" and 
"dataEncipherment", but this is just a guess since you mentioned it works on 
the old system.

>> I have some problems with new Cisco CAPF certs

What is the authenticating device? Cisco IP phone?

Cheers,
Frank

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

[openssl-users] Blog post; changing in email, crypto policy, etc

2018-01-19 Thread Salz, Rich via openssl-users 
There’s a new blog post at 
https://www.openssl.org/blog/blog/2018/01/18/f2f-london/

It contains some important policy changes we decided at our meeting last month. 
 This includes:
- Closing the openssl-dev mailing list; use GitHub for issues
- New mailing list openssl-project for project discussions
- New policy for accepting crypto algorithms, formats, and protocols.
- .. several others

Please read the posting; the changes described in it affect everyone who uses 
OpenSSL.  Thanks for your interest, and all your efforts to help improve the 
project!



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

Re: [openssl-users] tls handshake fail using cipher ECDHE-ECDSA-AES256-GCM-SHA384

2018-01-19 Thread Pravesh Rai 
Following link might give you, some clue about the problem:

https://stackoverflow.com/questions/30446431/wrong-cipher-suite-or-no-connection-with-openssl-server

Regards,
PR

On Fri, Jan 12, 2018 at 9:27 PM, johan persson 
wrote:

> I have problem doing handshake using "ECDHE-ECDSA-AES256-GCM-SHA384"
> cipher.
> OpenSSL 1.0.2h
>
> This is how I generate test certificates.
> openssl ecparam -out /data/ca.key -name secp256k1 -genkey
> openssl req -x509 -new -key /data/ca.key -out /data/ca.pem -outform PEM
> -days 3650 -subj '/C=SE/ST=S/L=M/O=V/CN=SERVER
> openssl ecparam -out /data/server.key -name secp256k1 -genkey
> openssl req -new -nodes -key /data/server.key -outform pem -out
> /data/server.req -subj '/C=SE/ST=S/L=M/O=V/CN=SERVER'
> openssl ecparam -out /data/client.key -name secp256k1 -genkey
> openssl req -new -nodes -key /data/client.key -outform pem -out
> /data/client.req -subj '/C=SE/ST=S/L=M/O=V/CN=CLIENT'
> openssl ca -batch -keyfile /data/ca.key -cert /data/ca.pem -in
> /data/server.req -out /data/server.pem -outdir /data/
> openssl ca -batch -keyfile /data/ca.key -cert /data/ca.pem -in
> /data/client.req -out /data/client.pem -outdir /data/
>
>
> Running the following test:
> openssl s_server -accept 1 -cert server.pem -key server.key -CAfile
> ca.pem -debug -tlsextdebug
> openssl s_client -connect localhost:1 -cert client.pem -key client.key
> -CAfile ca.pem -tls1_2
>
> I get a handshake working ok with the cipher I want
> "ECDHE-ECDSA-AES256-GCM-SHA384", perfect!:
>
>
> Now, using my own tls server I only get "ECDH-ECDSA-AES256-GCM-SHA384" to
> work. I cannot use "ECDHE-ECDSA-AES256-GCM-SHA384" which I want.
> Anyone knows what I'm missing from the following setup?:
>
> #define VOC_TLS_CIPHERS "ECDHE-ECDSA-AES256-GCM-SHA384" << NOT WORKING
> //#define VOC_TLS_CIPHERS "ECDH-ECDSA-AES256-GCM-SHA384" << WORKING
>
> // Init for OpenSSL
> SSL_library_init();
> OpenSSL_add_all_algorithms();
> SSL_load_error_strings();
>
> ctx_ = SSL_CTX_new(TLSv1_2_server_method());
> if (ctx_ == NULL)
> {
>LOG(LOG_WARN, "Tls: %s: Failed to create TLS context", __FUNCTION__);
>return RET_FAIL;
> }
>
> (Load Ca cert, server and server private key)
>
> if (SSL_CTX_set_ecdh_auto(ctx_, 1)) {
>LOG(LOG_WARN, "Tls: %s: Failed to set ECDH auto pick", __FUNCTION__);
>return RET_FAIL;
> }
>
> if (!SSL_CTX_set_cipher_list(ctx_, VOC_TLS_CIPHERS)) {
> LOG(LOG_WARN, "Tls: %s: Failed to set cipher list: %s\n",
> __FUNCTION__, VOC_TLS_CIPHERS);
> return RET_FAIL;
> }
>
> ssl_ = SSL_new(ctx_);
>
> error on server side:
> 
> Server has 1 from 0xb475ef98:
> 0xb6daa440:ECDHE-ECDSA-AES256-GCM-SHA384
> Client sent 1 from 0xb3502308:
> 0xb6daa440:ECDHE-ECDSA-AES256-GCM-SHA384
> rt=0 rte=0 dht=0 ecdht=0 re=0 ree=0 rs=0 ds=0 dhr=0 dhd=0
> 0:[0080:0040:0140:00D4]0xb6daa440:ECDHE-ECDS
> A-AES256-GCM-SHA384
> 2958031164:error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared
> cipher:s3_srvr.c:1417:
>
> --
> 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] TLS Error in FreeRadius - eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed

2018-01-19 Thread Gladewitz, Robert via openssl-users 
Dear OpenSSL Team,

 

I have some problems with new Cisco CAPF certs and freeradius tls
authentification. The point is, that freeradius users see the problem on
openssl implemtiation. 

 



(69) eap_tls: Continuing EAP-TLS

(69) eap_tls: Peer indicated complete TLS record size will be 1432 bytes

(69) eap_tls: Got complete TLS record (1432 bytes)

(69) eap_tls: [eaptls verify] = length included

(69) eap_tls: TLS_accept: SSLv3/TLS write server done

(69) eap_tls: <<< recv TLS 1.0 Handshake [length 03c2], Certificate

(69) eap_tls: Creating attributes from certificate OIDs

(69) eap_tls:   TLS-Cert-Serial := "1009"

(69) eap_tls:   TLS-Cert-Expiration := "38025719Z"

(69) eap_tls:   TLS-Cert-Subject := "/C=DE/ST=Sachsen/L=Leipzig/O=DBFZ
Deutsches Biomasseforschungszentrum gGmbH/OU=IT/CN=CAPF-91d43ef6"

(69) eap_tls:   TLS-Cert-Issuer := "/C=DE/ST=Sachsen/L=Leipzig/O=DBFZ
Deutsches Biomasseforschungszentrum gemeinnuetzige GmbH/OU=IT/CN=DBFZ CA
INTERN ROOT/emailAddress=supp...@dbfz.de
 "

(69) eap_tls:   TLS-Cert-Common-Name := "CAPF-91d43ef6"

(69) eap_tls:   ERROR: SSL says error 26 : unsupported certificate purpose

(69) eap_tls: >>> send TLS 1.0 Alert [length 0002], fatal
unsupported_certificate

(69) eap_tls: ERROR: TLS Alert write:fatal:unsupported certificate

tls: TLS_accept: Error in error

(69) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read): error:1417C086:SSL
routines:tls_process_client_certificate:certificate verify failed

(69) eap_tls: ERROR: System call (I/O) error (-1)

(69) eap_tls: ERROR: TLS receive handshake failed during operation

(69) eap_tls: ERROR: [eaptls process] = fail 



 

This means, that the check of ca certificate is failed. So, bu I do not see,
why. If i check the certificate by command openssl -verify, all sems to be
right. 

# openssl verify -verbose -CAfile
/etc/freeradius/3.0/certs.8021x.ciscophone/cacert.capf.pem
SEP64A0E714844E-L1.pem 

# SEP64A0E714844E-L1.pem: OK

 

 

The openssl version is Debian based 1.1.0g-2. But the same error is
happening on 1.1.0f also. 

 

Older freeradius version 2 on Debian 8/openssl 1.0.1t-1+deb8u7 working fine
without this problem (by using the same certificates)

 

The ca certificate are signed by an intern ca. Can anyone see the error??

 

Robert

 

 

 



cacert.capf.pem
Description: cacert.capf.pem


SEP64A0E714844E-L1.pem
Description: SEP64A0E714844E-L1.pem


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

[openssl-users] Revoke certificate and append to existing crl file

2018-01-19 Thread neel patel 
Hi,

I am using openssl C API.

I have created openssl certificates so i have .crt and .key file. If I want
to append those certificates in existing certificate revocation list then
how can we do that ? I have tried with below code.


#include 

#include 

#include 

#include 


#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 

#include 


#define DB_NUMBER   6

#define DB_name 5

#define DB_serial   3

#define DB_rev_date 2


static X509* load_cert(const char* usercert)

{

/* read usercert from file */

X509* x = NULL;

BIO* bio = BIO_new(BIO_s_file());

assert(bio != NULL);

assert(BIO_read_filename(bio, usercert) > 0);

x = PEM_read_bio_X509_AUX(bio, NULL, NULL, NULL);

BIO_free(bio);

assert(x != NULL);


return x;

}


int main()

{

int i;

ASN1_UTCTIME* tm = NULL;

char* rev_str = NULL;

BIGNUM* bn = NULL;

char* row[DB_NUMBER];


for (i = 0; i < DB_NUMBER; i++)

row[i] = NULL;


X509* x = load_cert("../client.crt");


row[DB_name] = X509_NAME_oneline(X509_get_subject_name(x), NULL, 0);

bn = ASN1_INTEGER_to_BN(X509_get_serialNumber(x), NULL);

assert(bn != NULL);

if (BN_is_zero(bn))

row[DB_serial] = BUF_strdup("00");

else

row[DB_serial] = BN_bn2hex(bn);


BN_free(bn);


printf("Serial Number is: %s\n", row[DB_serial]);



printf(" Now Updating CRL file with expired client certificates
\n");



char   *crl_file_path = "../root_mod.crl";

FILE   *fp_crl_file = NULL;

X509_CRL *x_crl = NULL;

BIGNUM* serial = NULL;


/* Get the CA crl */

fp_crl_file = fopen(crl_file_path, "r");

if (!fp_crl_file)

{

printf(" Error while opening CRL file \n");

exit(1);

}


x_crl = PEM_read_X509_CRL(fp_crl_file, NULL, NULL, NULL);

if (!x_crl)

{

printf(" Error while reading X509 CRL file \n");

exit(1);

}


fclose(fp_crl_file);


X509_REVOKED* r = X509_REVOKED_new();

assert(r != NULL);


assert(BN_hex2bn(&serial, row[DB_serial]) > 0);


ASN1_INTEGER* tmpser = BN_to_ASN1_INTEGER(serial, NULL);

BN_free(serial);

serial = NULL;

assert(tmpser != NULL);

i = X509_REVOKED_set_serialNumber(r, tmpser);


ASN1_INTEGER_free(tmpser);

X509_CRL_add0_revoked(x_crl, r);


return 0;

}


Is is possible to add revoked certificate serial number to CRL file ? OR Do
I need to regenerate the CRL file from list of revoked certificate serial
numbers ( e.g. index.txt ).

Let us know your thoughts.

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