Re: [openssl-users] big endian vs little endian

2016-12-18 Thread Jeffrey Walton 
On Sun, Dec 18, 2016 at 5:09 PM, Viktor Dukhovni
 wrote:
>
>> On Dec 18, 2016, at 2:55 PM, Walter H. via openssl-users 
>>  wrote:
>>
>> encrypt
>> openssl enc -e -in file -out encryptfile -aes-256-gcm
>
> GCM is not supported with "openssl enc(1)".  Use a CBC cipher
> instead.

+1. This was late to be documented, but its available at
(https://www.openssl.org/docs/man1.0.2/apps/enc.html):

"The enc program does not support authenticated
encryption modes like CCM and GCM. The utility
does not store or retrieve the authentication tag."

Maybe the encrypt program should throw an error rather than producing
incorrect results without a warning.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] big endian vs little endian

2016-12-18 Thread Jeremy Farrell 

On 18/12/2016 16:21, sahorwitz wrote:

I am obviosly a newbie and missing something. How then do I encrypt the file
on one machine (little endian), transmit it to another machine (big endian)
and decrypt it there?


What problem are you actually seeing? In what way does the decryption 
fail on the destination machine? Please include the commands you are 
using in the problem scenario, and any messages put out by the commands. 
The endianness of the machines isn't relevant.


--
J. J. Farrell
Not speaking for Oracle

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

Re: [openssl-users] big endian vs little endian

2016-12-18 Thread Viktor Dukhovni 

> On Dec 18, 2016, at 2:55 PM, Walter H. via openssl-users 
>  wrote:
> 
> encrypt
> openssl enc -e -in file -out encryptfile -aes-256-gcm

GCM is not supported with "openssl enc(1)".  Use a CBC cipher
instead.

-- 
Viktor.

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

Re: [openssl-users] Problem with certificate check when it does not match CN

2016-12-18 Thread Viktor Dukhovni 

> On Dec 18, 2016, at 4:52 PM, Brice André  wrote:
> 
> I know that the current certificate is the old one, but this
> is because my service is in production.
> 
> I tested new certificate this evening to limit the number of
> impacted clients. And as it did not worked, i reinstalled
> previous certificate waiting a solution for the new one.
> 
> If it may help, i can install the new cerrificate on a
> test site.

Either that, or post a problem report that contains detailed
technical information, rather than a hand-waving story.

What version of OpenSSL are you using?  What O/S platform?
What certificate stores did you configure in your OpenSSL
client.  Which pertinent certificates (post these) did you
ensure are contained in that store.

What certificate chain is returned by the server?
Post the output of:

   $ (sleep 2; exit) |
openssl s_client -showcerts -connect : 2>&1 |
openssl crl2pkcs7 -nocrl -certfile /dev/stdin |
openssl pkcs7 -print_certs | tee chain.pem

Copy the trusted roots into a file named trusted.pem, then
make sure the server's chain validates:

   $ openssl verify -trusted trusted.pem -untrusted chain.pem chain.pem

(post the output...).  [ By the way, your problem is not a bug in DNS
subjectAltName processing in OpenSSL.  Either your server configuration
or client code is in error, if you present sufficient detail, it will
be possible to help you determine which. ]

-- 
Viktor.

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

Re: [openssl-users] Problem with certificate check when it does not match CN

2016-12-18 Thread Brice André 
Dear Viktor,

Thanks for your answer.

I Know that the current certificate is the old one, but this is because my
service is in production.

I tested new certificate this evening to limit the number of impacted
clients. And as it did not worked, i reinstalled previous certificate
waiting a solution for the new one.

If it may help, i can installe new cerrificate on a test site.

Regards,
Brice


Le dim. 18 déc. 2016 à 22:26, Viktor Dukhovni 
a écrit :

>
>
> > On Dec 18, 2016, at 3:05 PM, Brice André  wrote:
>
> >
>
> > I developped the service a few years ago and got wildcard certificates
> from Startcom. Due to the recent probems with startcom, I migrated my
> certificates to COMODO. I also tried to rationalise the number of
> certificates, and I think several of my problems come from here.
>
>
>
> Your problem is an incomplete migration.  The certificate
>
> presented by www.online-rdv.be on port 443 is the StartCom
>
> certificate you intended to replace.
>
>
>
> > For a dedicate web service, I use a server located at
> https://www.online-rdv.be/v1/ With my previous certificate, CN of
> certificate was a wildcard certificate : *.online-rdv.be. Everything
> worked fine.
>
>
>
> See below for the presented chain:
>
>
>
> Certificate:
>
> Data:
>
> Version: 3 (0x2)
>
> Serial Number: 2304556835693556 (0x82ffb738e63f4)
>
> Signature Algorithm: sha256WithRSAEncryption
>
> Issuer: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate
> Signing, CN=StartCom Class 2 Primary Intermediate Server CA
>
> Validity
>
> Not Before: Oct 14 10:40:52 2015 GMT
>
> Not After : Oct 14 15:54:25 2017 GMT
>
> Subject: C=BE, ST=Hainaut, L=Couillet, O=Brice Andr\xE9, CN=*.
> online-rdv.be/emailAddress=hostmas...@online-rdv.be
>
> Subject Public Key Info:
>
> Public Key Algorithm: rsaEncryption
>
> Public-Key: (2048 bit)
>
> Modulus:
>
> 00:c7:15:56:aa:b7:13:50:b6:30:af:aa:53:00:d1:
>
> 34:ae:d7:c9:62:95:80:f7:70:93:d1:13:16:04:bd:
>
> 70:ac:fa:b0:74:0d:ce:c2:1c:e6:96:d0:cd:5d:4d:
>
> 59:e7:bb:1d:34:7e:05:b3:60:96:aa:fa:88:4d:75:
>
> 61:52:59:f5:ae:58:86:7d:7a:5d:93:c1:f8:dc:be:
>
> 86:25:c1:d4:63:60:eb:1d:ab:8a:da:a4:4d:4a:17:
>
> 40:ef:02:55:57:2b:53:42:0e:ac:21:7c:13:6c:c4:
>
> ed:72:ba:99:8a:63:b3:02:c9:3f:ff:36:d6:a2:81:
>
> 95:38:32:ec:ae:c7:fe:75:54:17:82:b5:16:c9:ae:
>
> c5:46:05:28:b5:c3:24:76:65:60:dd:21:15:c7:28:
>
> b8:ec:a5:d2:15:bf:5d:58:e3:cb:ef:ca:9a:09:54:
>
> 31:f1:4d:b7:ae:89:dd:60:a7:8f:1c:d7:06:8d:91:
>
> ab:9f:68:36:fa:e9:ba:9c:ff:64:c1:58:9b:d7:de:
>
> df:b9:ac:bd:e0:05:08:d1:fb:a1:02:08:01:11:bf:
>
> fc:9c:73:7b:b7:7d:ec:0f:0c:bf:73:8b:fc:6e:b1:
>
> 56:dd:ca:58:00:d8:80:53:8e:f0:ff:72:70:ae:14:
>
> ad:0c:0e:ae:23:9c:1a:a2:dd:11:41:6e:8d:87:f5:
>
> 6a:35
>
> Exponent: 65537 (0x10001)
>
> X509v3 extensions:
>
> X509v3 Basic Constraints:
>
> CA:FALSE
>
> X509v3 Key Usage:
>
> Digital Signature, Key Encipherment, Key Agreement
>
> X509v3 Extended Key Usage:
>
> TLS Web Client Authentication, TLS Web Server
> Authentication
>
> X509v3 Subject Key Identifier:
>
> E5:7E:1E:3D:4C:C1:71:36:3A:FE:F8:D3:E7:E2:5F:A1:7D:8B:42:A3
>
> X509v3 Authority Key Identifier:
>
>
> keyid:11:DB:23:45:FD:54:CC:6A:71:6F:84:8A:03:D7:BE:F7:01:2F:26:86
>
>
>
> X509v3 Subject Alternative Name:
>
> DNS:*.online-rdv.be, DNS:online-rdv.be, DNS:online-rdv.biz,
> DNS:*.online-rdv.biz, DNS:online-rdv.com, DNS:*.online-rdv.com, DNS:
> online-rdv.eu, DNS:*.online-rdv.eu, DNS:online-rdv.info, DNS:*.
> online-rdv.info, DNS:online-rdv.net, DNS:*.online-rdv.net, DNS:
> online-rdv.org, DNS:*.online-rdv.org, DNS:rdv-doc.be, DNS:*.rdv-doc.be,
> DNS:doc-rdv.be, DNS:*.doc-rdv.be
>
> X509v3 Certificate Policies:
>
> Policy: 2.23.140.1.2.2
>
> Policy: 1.3.6.1.4.1.23223.1.2.3
>
>   CPS: http://www.startssl.com/policy.pdf
>
>   User Notice:
>
> Organization: StartCom Certification Authority
>
> Number: 1
>
> Explicit Text: This certificate was issued according
> to the Class 2 Validation requirements of the StartCom CA policy, reliance
> only for the intended purpose in compliance of the relying party
> obligations.
>
>
>
> X509v3 CRL Distribution Points:
>
>
>
> Full Name:
>
>

Re: [openssl-users] Problem with certificate check when it does not match CN

2016-12-18 Thread Viktor Dukhovni 

> On Dec 18, 2016, at 3:05 PM, Brice André  wrote:
> 
> I developped the service a few years ago and got wildcard certificates from 
> Startcom. Due to the recent probems with startcom, I migrated my certificates 
> to COMODO. I also tried to rationalise the number of certificates, and I 
> think several of my problems come from here.

Your problem is an incomplete migration.  The certificate
presented by www.online-rdv.be on port 443 is the StartCom
certificate you intended to replace.

> For a dedicate web service, I use a server located at 
> https://www.online-rdv.be/v1/ With my previous certificate, CN of 
> certificate was a wildcard certificate : *.online-rdv.be. Everything worked 
> fine.

See below for the presented chain:

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2304556835693556 (0x82ffb738e63f4)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, 
CN=StartCom Class 2 Primary Intermediate Server CA
Validity
Not Before: Oct 14 10:40:52 2015 GMT
Not After : Oct 14 15:54:25 2017 GMT
Subject: C=BE, ST=Hainaut, L=Couillet, O=Brice Andr\xE9, 
CN=*.online-rdv.be/emailAddress=hostmas...@online-rdv.be
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c7:15:56:aa:b7:13:50:b6:30:af:aa:53:00:d1:
34:ae:d7:c9:62:95:80:f7:70:93:d1:13:16:04:bd:
70:ac:fa:b0:74:0d:ce:c2:1c:e6:96:d0:cd:5d:4d:
59:e7:bb:1d:34:7e:05:b3:60:96:aa:fa:88:4d:75:
61:52:59:f5:ae:58:86:7d:7a:5d:93:c1:f8:dc:be:
86:25:c1:d4:63:60:eb:1d:ab:8a:da:a4:4d:4a:17:
40:ef:02:55:57:2b:53:42:0e:ac:21:7c:13:6c:c4:
ed:72:ba:99:8a:63:b3:02:c9:3f:ff:36:d6:a2:81:
95:38:32:ec:ae:c7:fe:75:54:17:82:b5:16:c9:ae:
c5:46:05:28:b5:c3:24:76:65:60:dd:21:15:c7:28:
b8:ec:a5:d2:15:bf:5d:58:e3:cb:ef:ca:9a:09:54:
31:f1:4d:b7:ae:89:dd:60:a7:8f:1c:d7:06:8d:91:
ab:9f:68:36:fa:e9:ba:9c:ff:64:c1:58:9b:d7:de:
df:b9:ac:bd:e0:05:08:d1:fb:a1:02:08:01:11:bf:
fc:9c:73:7b:b7:7d:ec:0f:0c:bf:73:8b:fc:6e:b1:
56:dd:ca:58:00:d8:80:53:8e:f0:ff:72:70:ae:14:
ad:0c:0e:ae:23:9c:1a:a2:dd:11:41:6e:8d:87:f5:
6a:35
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: 
CA:FALSE
X509v3 Key Usage: 
Digital Signature, Key Encipherment, Key Agreement
X509v3 Extended Key Usage: 
TLS Web Client Authentication, TLS Web Server Authentication
X509v3 Subject Key Identifier: 
E5:7E:1E:3D:4C:C1:71:36:3A:FE:F8:D3:E7:E2:5F:A1:7D:8B:42:A3
X509v3 Authority Key Identifier: 

keyid:11:DB:23:45:FD:54:CC:6A:71:6F:84:8A:03:D7:BE:F7:01:2F:26:86

X509v3 Subject Alternative Name: 
DNS:*.online-rdv.be, DNS:online-rdv.be, DNS:online-rdv.biz, 
DNS:*.online-rdv.biz, DNS:online-rdv.com, DNS:*.online-rdv.com, 
DNS:online-rdv.eu, DNS:*.online-rdv.eu, DNS:online-rdv.info, 
DNS:*.online-rdv.info, DNS:online-rdv.net, DNS:*.online-rdv.net, 
DNS:online-rdv.org, DNS:*.online-rdv.org, DNS:rdv-doc.be, DNS:*.rdv-doc.be, 
DNS:doc-rdv.be, DNS:*.doc-rdv.be
X509v3 Certificate Policies: 
Policy: 2.23.140.1.2.2
Policy: 1.3.6.1.4.1.23223.1.2.3
  CPS: http://www.startssl.com/policy.pdf
  User Notice:
Organization: StartCom Certification Authority
Number: 1
Explicit Text: This certificate was issued according to the 
Class 2 Validation requirements of the StartCom CA policy, reliance only for 
the intended purpose in compliance of the relying party obligations.

X509v3 CRL Distribution Points: 

Full Name:
  URI:http://crl.startssl.com/crt2-crl.crl

Authority Information Access: 
OCSP - URI:http://ocsp.startssl.com/sub/class2/server/ca
CA Issuers - 
URI:http://aia.startssl.com/certs/sub.class2.server.ca.crt

X509v3 Issuer Alternative Name: 
URI:http://www.startssl.com/
Signature Algorithm: sha256WithRSAEncryption
 a9:f2:f6:ea:a8:57:bc:1b:11:51:05:eb:b8:b5:55:0f:96:e6:
 08:73:ef:67:92:bf:aa:b0:54:32:48:3e:61:91:73:dd:2d:fd:
 2a:e7:2b:57:81:a5:a5:46:17:5b:2d:9a:62:f3:fa:43:11:ba:
 48:0f:47:65:19:ca:2b:82:dd:0f:e7:da:2d:1c:99:55:b6:86:
 93:b7:58:31:d3:a9:1a:34:ae:b8:5f:65:29:a0:0a:22:49:0f:

Re: [openssl-users] big endian vs little endian

2016-12-18 Thread Walter H. via openssl-users 

On 18.12.2016 17:21, sahorwitz wrote:

I am obviosly a newbie and missing something. How then do I encrypt the file
on one machine (little endian), transmit it to another machine (big endian)
and decrypt it there?




similar to this:

encrypt
openssl enc -e -in file -out encryptfile -aes-256-gcm

decrypt
openssl enc -d -in encryptfile -out file -aes-256-gcm

can someone explain why I get the following output

enter aes-256-gcm decryption password:
bad decrypt

but the file is correctly decrypted

I'm using latest openssl rpm package from CentOS 6





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

Re: [openssl-users] big endian vs little endian

2016-12-18 Thread Ken Goldman 

On 12/18/2016 11:21 AM, sahorwitz wrote:

I am obviously a newbie and missing something. How then do I encrypt the file
on one machine (little endian), transmit it to another machine (big endian)
and decrypt it there?


Why do you think endian'ness is an issue?



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

[openssl-users] Problem with certificate check when it does not match CN

2016-12-18 Thread Brice André 
Dear all,

I use a gsoap application for which I write the server (php/apache) and
client (gsoap and openssl). As I am pretty sure my problem comes from
openssl and not gsoap, I am asking my question here.

I developped the service a few years ago and got wildcard certificates from
Startcom. Due to the recent probems with startcom, I migrated my
certificates to COMODO. I also tried to rationalise the number of
certificates, and I think several of my problems come from here.

For a dedicate web service, I use a server located at
https://www.online-rdv.be/v1/ With my previous certificate, CN of
certificate was a wildcard certificate : *.online-rdv.be. Everything worked
fine.

But now, my new certificate is common for all my web sites. So, the CN is
www.ams-solutions.be and, in the list of alternate names, I have an entry *.
online-rdv.be.

>From this point, all gsoap connections fail from SSL checks. If checked the
certificate bundle provided to my gsoap client application and it contains
root certificate, as well as intermediate certificates.

This same soap server is directly used by the website and all browsers I
checked do not encounter the problem.

So, my best guess is that the way I configure openssl with gsoap is not
correct and does not allow validating a web site if it does not match the
CN certificate field.

I do no special configuration (nearly all default parameters). In fact, the
only ssl configuration I perform is the following :

  soap_ssl_init();
   soap_ssl_client_context(service.soap,
   SOAP_SSL_DEFAULT,
   NULL,
   NULL,
   cert_path.GetCString(),
   NULL,
   NULL);


where cert_path points to a file with root and intermediate certificates.

Any suggestion on how to solve my problem ?

Regards,

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

Re: [openssl-users] big endian vs little endian

2016-12-18 Thread sahorwitz 
I am obviosly a newbie and missing something. How then do I encrypt the file
on one machine (little endian), transmit it to another machine (big endian)
and decrypt it there?



--
View this message in context: 
http://openssl.6102.n7.nabble.com/big-endian-vs-little-endian-tp69372p69377.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Error code 554184855 on PKCS7_sign_add_signer?

2016-12-18 Thread Anibal F. Martinez Cortina 
Hello everyone, I've been reading smime.c and trying to work my way up from
a command that does work.
However, I've reached this stage, and I get an error code I don-t know how
to diagnose.
The source is this(BEWARE: very little error handling, this is just a first
informed attempt at the problem):

X509 * certificado = NULL;

FILE * archivoCertificado = NULL;

archivoCertificado = fopen("cert.crt","rb");

if (!archivoCertificado) {

qDebug() << "Fallo abrir el archivo del certificado";

return;

}

PEM_read_X509(archivoCertificado,,NULL,NULL);

if (!certificado) {

qDebug() << "Fallo al generar la estructura X509";

return;

}

FILE* archivoLlave = NULL;

archivoLlave = fopen("key.key","rb");

EVP_PKEY * llave;

PEM_read_PrivateKey(archivoLlave,,NULL,NULL);

if (!llave) {

qDebug() << "Fallo la lectura de la llave";

return;

}

BIO * datos = NULL;

FILE * fDatos = NULL;

fDatos = fopen("Prueba.xml","rb");

if (!fDatos) {

qDebug() << "Fallo la apertura del archivo de prueba.";

return;

}

datos = BIO_new_fp(fDatos,NULL);

if (!datos) {

qDebug() << "Error al leer el archivo de prueba.xml";

return;

}

PKCS7 *estructura = NULL;

if (!PKCS7_sign_add_signer(estructura,certificado,llave,NULL,0)) {

qDebug() << "PKCS7_sign_add_signer fallo:" << ERR_get_error();

return;

}

estructura = PKCS7_sign(certificado,llave,NULL,datos,PKCS7_TEXT);

if (!estructura) {

qDebug() << "Fallo la creacion de la estructura.";

return;

}


Failure comes at PKCS7_sign_add_signer..
Sorry for the main language used in the code, let me know if its of best
practices to keep it to english or if it wouldn't be a real issue for the
time being.

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