Re: Unable to load self-signed certificate

[radiatejava]

Actually the error is:

533:error:02001002:system library:fopen:No such file or
directory:bss_file.c:175:fopen('/opt/ssl-v1.02u/ssl/cert.pem','r')
533:error:2006D080:BIO routines:BIO_new_file:no such
file:bss_file.c:182: 533:error:0B084002:x509 certificate
routines:X509_load_cert_crl_file:system lib:by_file.c:254:
533:error:0B065068:x509 certificate routines:BY_FILE_CTRL:loading
defaults:by_file.c:112:

as we are having 2 different versions of ssl on the system.
Is there anything we need to do if we have 2 different versions? I am
building my app pointing libs and includes to /opt/ssl-v1.02u

Thanks

On Wed, Jul 27, 2022 at 8:14 AM radiatejava  wrote:
>
> Hello experts
> I used to load a self-signed cert using a program like below:
>
> X509_STORE_set_verify_cb_func(lCertCtx, UserCert_cb_check_cert);
> lLookup = X509_STORE_add_lookup(lCertCtx, X509_LOOKUP_file());
> error = X509_LOOKUP_load_file(lLookup, NULL, X509_FILETYPE_DEFAULT);
>
> It was all working great till I was on openssl 1.0.2k.
> We have shifted to openssl 1.0.2u and now the call
> X509_LOOKUP_load_file(..) for self-siged cert is not working. Somehow
> it seems to be looking for a default CA certificate. This is the error
> I get:
>
> 533:error:02001002:system library:fopen:No such file or
> directory:bss_file.c:175:fopen('/usr/lib/ssl/cert.pem','r')
> 533:error:2006D080:BIO routines:BIO_new_file:no such
> file:bss_file.c:182: 533:error:0B084002:x509 certificate
> routines:X509_load_cert_crl_file:system lib:by_file.c:254:
> 533:error:0B065068:x509 certificate routines:BY_FILE_CTRL:loading
> defaults:by_file.c:112:
>
> I do not have any /usr/lib/ssl/cert.pem file on my system. I am on ubuntu 
> 20.04.
>
> Appreciate your help!
> -Satish

Unable to load self-signed certificate

[radiatejava]

Hello experts
I used to load a self-signed cert using a program like below:

X509_STORE_set_verify_cb_func(lCertCtx, UserCert_cb_check_cert);
lLookup = X509_STORE_add_lookup(lCertCtx, X509_LOOKUP_file());
error = X509_LOOKUP_load_file(lLookup, NULL, X509_FILETYPE_DEFAULT);

It was all working great till I was on openssl 1.0.2k.
We have shifted to openssl 1.0.2u and now the call
X509_LOOKUP_load_file(..) for self-siged cert is not working. Somehow
it seems to be looking for a default CA certificate. This is the error
I get:

533:error:02001002:system library:fopen:No such file or
directory:bss_file.c:175:fopen('/usr/lib/ssl/cert.pem','r')
533:error:2006D080:BIO routines:BIO_new_file:no such
file:bss_file.c:182: 533:error:0B084002:x509 certificate
routines:X509_load_cert_crl_file:system lib:by_file.c:254:
533:error:0B065068:x509 certificate routines:BY_FILE_CTRL:loading
defaults:by_file.c:112:

I do not have any /usr/lib/ssl/cert.pem file on my system. I am on ubuntu 20.04.

Appreciate your help!
-Satish

Re: facing issue in sha512 self - signed certificate

[Mark Hack]

You will need to be a lot more specific - this works fine

openssl s_client -connect localhost:443 | openssl x509 -noout -text
Can't use SSL_get_servername
depth=0 C = US, ST = TX, L = Somewhere, O = MarkHack, OU = Test, CN =
fakeserver.com
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = TX, L = Somewhere, O = MarkHack, OU = Test, CN =
fakeserver.com
verify return:1
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
5d:72:e6:0c:24:3f:97:7f:66:09:f6:a5:f7:f8:96:95:ed:cb:26:59
Signature Algorithm: sha512WithRSAEncryption
Issuer: C = US, ST = TX, L = Somewhere, O = MarkHack, OU = Test, CN =
fakeserver.com
Validity
Not Before: Apr 22 14:22:50 2021 GMT
Not After : Apr 22 14:22:50 2022 GMT
Subject: C = US, ST = TX, L = Somewhere, O = MarkHack, OU = Test, CN =
fakeserver.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (4096 bit)
Modulus:
00:b8:c0:72:0e:81:ec:49:fd:6d:06:c2:15:1c:a7:

cf:5c:cb
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier: 
7A:E4:80:D6:86:BF:03:BE:3C:16:C6:99:B7:66:BE:CE:52:F7:96:F2
X509v3 Authority Key Identifier: 
keyid:7A:E4:80:D6:86:BF:03:BE:3C:16:C6:99:B7:66:BE:CE:52:F7:96:F2

X509v3 Basic Constraints: critical
CA:TRUE
Signature Algorithm: sha512WithRSAEncryption
27:1e:c7:f4:7a:7e:43:39:1f:3d:8b:08:94:67:bf:9d:e9:38:

a5:fb:21:9c:d7:f5:28:67
On Thu, 2021-04-22 at 18:22 +0530, Vadivel P wrote:
> Hi All,
> 
> Looking for the same support of SHA512. Do we have sha512 support in
> any open source ? Please let me know.
> 
> Regards,
> Vadivel
> 
> On Mon, Apr 19, 2021, 13:15 preethi teekaraman <
> preethi.kav...@gmail.com> wrote:
> > Hi Openssl,
> > 
> > I'm creating sha512 self signed certificate for establishing
> > connection between client and server(nginx server). 
> > creating separate key, cert for server and root cert for client. 
> > below is the link i followed for cert creation: 
> > https://gist.github.com/fntlnz/cf14feb5a46b2eda428e000157447309
> > 
> > Issue faced : 
> > There's no connection established and we cross-checked error log in
> > server no error observed. 
> > 
> > Openssl version : OpenSSL 1.0.1f 6 Jan 2014
> > 
> > 
> > nginx version: nginx/1.4.6 (Ubuntu)
> > 
> > 
> > OS version 
> > 
> > 
> > No LSB modules are available.
> > 
> > 
> > Distributor ID:Ubuntu
> > 
> > 
> > Description:   
> > Ubuntu 14.04.5 LTS
> > 
> > 
> > Release:  
> > 14.04
> > 
> > 
> > Codename:trusty
> > 
> > is there any link or commands to follow while creating cert for
> > sha512. ?
> > 
> > Regards,
> > Preethi Teekaraman.

Re: facing issue in sha512 self - signed certificate

[Vadivel P]

Hi All,

Looking for the same support of SHA512. Do we have sha512 support in any
open source ? Please let me know.

Regards,
Vadivel

On Mon, Apr 19, 2021, 13:15 preethi teekaraman 
wrote:

> Hi Openssl,
>
> I'm creating sha512 self signed certificate for establishing connection
> between client and server(nginx server).
> creating separate key, cert for server and root cert for client.
> below is the link i followed for cert creation:
> https://gist.github.com/fntlnz/cf14feb5a46b2eda428e000157447309
>
> Issue faced :
> There's no connection established and we cross-checked error log in server
> no error observed.
>
> Openssl version : OpenSSL 1.0.1f 6 Jan 2014
>
> nginx version: nginx/1.4.6 (Ubuntu)
>
> OS version
>
> No LSB modules are available.
>
> Distributor ID:Ubuntu
>
> Description:Ubuntu 14.04.5 LTS
>
> Release:   14.04
>
> Codename:trusty
>
>
> is there any link or commands to follow while creating cert for sha512. ?
>
>
> Regards,
>
> Preethi Teekaraman.
>

facing issue in sha512 self - signed certificate

[preethi teekaraman]

Hi Openssl,

I'm creating sha512 self signed certificate for establishing connection
between client and server(nginx server).
creating separate key, cert for server and root cert for client.
below is the link i followed for cert creation:
https://gist.github.com/fntlnz/cf14feb5a46b2eda428e000157447309

Issue faced :
There's no connection established and we cross-checked error log in server
no error observed.

Openssl version : OpenSSL 1.0.1f 6 Jan 2014

nginx version: nginx/1.4.6 (Ubuntu)

OS version

No LSB modules are available.

Distributor ID:Ubuntu

Description:Ubuntu 14.04.5 LTS

Release:   14.04

Codename:trusty


is there any link or commands to follow while creating cert for sha512. ?


Regards,

Preethi Teekaraman.

Re: How to establish a connection with self signed certificate

[Dmitry Belyavsky]

Hello,

As you control both the server keypair and client, I'd suggest you to use
the openssl s_server/s_client application to debug the connection.

On Sun, Mar 28, 2021 at 9:41 AM preethi teekaraman 
wrote:

> Hi
>
> I'm using latest version 1.1.1i 8 Dec 2020 openssl version to create self
> signed certificate with sha256 algorithm.
>
> I tried loading the certs in device and in server side. The client sends
> "hello packet" to server and server refused to connect with an error "
> alert internal error ". The handshake failing between server (nginx load
> balancer) and client with latest openssl certificate.
>
> Any idea to resolve this?
>


-- 
SY, Dmitry Belyavsky

How to establish a connection with self signed certificate

[preethi teekaraman]

Hi

I'm using latest version 1.1.1i 8 Dec 2020 openssl version to create self
signed certificate with sha256 algorithm.

I tried loading the certs in device and in server side. The client sends
"hello packet" to server and server refused to connect with an error "
alert internal error ". The handshake failing between server (nginx load
balancer) and client with latest openssl certificate.

Any idea to resolve this?

Re: [openssl-users] [Newsletter] Re: self-signed certificate won't work in my app but works with s_client

[Salz, Rich]

> A Wireshark trace reveals that the client shuts  down the handshake 
> connection with the reason ‘Unknown CA’.

> So if the client knows that the cert is self-signed as indicated by the debug 
> logs, why would it issue the above reason for failure when it doesn’t need to 
> know the CA?

You still have to add the CA to your local trust store.

Otherwise, you'd blindly accept *every* self-signed certificate, right?
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [Newsletter] Re: self-signed certificate won't work in my app but works with s_client

[Carl Heyendal]

Thanks Matthew.

However the problem seems to be occurring before the processing of the return 
codes you mentioned.

The problem occurs from a bad return value from:
if(SSL_connect(ssl) <= 0)
int_error("Error connecting SSL object");

A Wireshark trace reveals that the client shuts  down the handshake connection 
with the reason ‘Unknown CA’.

So if the client knows that the cert is self-signed as indicated by the debug 
logs, why would it issue the above reason for failure when it doesn’t need to 
know the CA?

Carl



From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Matthew Donald
Sent: July-01-16 12:09 AM
To: openssl-users@openssl.org
Subject: [Newsletter] Re: [openssl-users] self-signed certificate won't work in 
my app but works with s_client

"error 18:self signed certificate" is the expected result if you are validating 
a self-signed cert.

In certificate verification, the code needs to check for X509_V_OK, 
X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT and  
X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY.

X509_V_OK is a normal cert verification and the connection can proceed.  
X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY indicates that an otherwise valid 
cert has been processed, but the issuer is unknown.  
X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT indicates that a self-signed cert was 
read.  Any other return value is a fatal error (signature failure etc).

Matthew


On 1 July 2016 at 05:34, Carl Heyendal 
mailto:cheyen...@fortinet.com>> wrote:
I am working with the example apps in the "Networking Security with OpenSSL" 
book and up until now have been able to get client/server examples 1,2,3 to 
work. But now I'm trying to connect to an in-house tool but I'm getting the 
error "error 18:self signed certificate". Despite this error when I run my app 
(essentially client3), when I use s_client with the very same credentials...it 
works.

I suspect that it has something to do with the ssl/tls api combination that I 
use in my 'client3' app.

Here's the command and output for s_client that connects to the in-house tool 
which works:

> openssl s_client -connect 192.168.1.99:16001<http://192.168.1.99:16001> 
-CAfile ../_security/SipInspector/certificate.pem -key ../_security/client.pem
  Enter pass phrase for ../_security/client.pem:
  CONNECTED(0003)
  depth=0 C = CA, ST = Ontario, L = Ottawa, O = SIP Inspector Ltd, OU   =   
  Development, CN = 192.168.1.99
  verify return:1
  ---
  Certificate chain
   0 s:/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
 i:/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
  ---
  Server certificate
  -BEGIN CERTIFICATE-
  MIIFxTCCA62gAwIBAgIJALKQ3J5SEyjPMA0GCSqGSIb3DQEBCwUAMHkxCzAJBgNV
  BAYTAkNBMRAwDgYDVQQIDAdPbnRhcmlvMQ8wDQYDVQQHDAZPdHRhd2ExGjAYBgNV
(snip)
  pt/q5/gKqRFbjyL0LDNz49vaSUYvbu3mgF2480Or4X+GPwemwdxJaF1pQw4C1WaF
  RyfVjDrLNhTvv+zKCbEPyrjXCweNVRVcp8lZ8R0HmXwfgevlCNz/GQo=
  -END CERTIFICATE-
  subject=/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
  issuer=/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
  ---
  No client certificate CA names sent
  ---
  SSL handshake has read 2309 bytes and written 509 bytes
  ---
  New, TLSv1/SSLv3, Cipher is ECDHE-RSA-DES-CBC3-SHA
  Server public key is 4096 bit
  Secure Renegotiation IS supported
  Compression: NONE
  Expansion: NONE
  SSL-Session:
  Protocol  : TLSv1.2
  Cipher: ECDHE-RSA-DES-CBC3-SHA
  Session-ID:   
5755C781D91CF3177DF624EA3599EE430DAB4790F325FAD9378FEAE7731C4497
  Session-ID-ctx:
  Master-Key: 
D149008E43E29D658D29418C9F770B3D6018B1D7CA2F493027B0AC7C3BA8E53B572B68C371153568B8988A1E5F351839
  Key-Arg   : None
  PSK identity: None
  PSK identity hint: None
  SRP username: None
  Start Time: 1465239425
  Timeout   : 300 (sec)
  Verify return code: 0 (ok)
   ---


Here's the command and output when I run my app that tries to connect to the 
same in-house tool which fails:

> ./client3 192.168.1.99
Enter PEM pass phrase:
connecting to 192.168.1.99:16001<http://192.168.1.99:16001>
 -Error with certificate at depth: 0
   issuer   = /C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector Ltd/OU=Development  
 /CN=192.168.1.99
   subject  = /C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
   err 18:self signed certificate
 ** client3.c:94 Error connecting SSL object
139788992993088:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:1180:
>

Here are the api's I call in the my app that utilize the same

Re: [openssl-users] self-signed certificate won't work in my app but works with s_client

[Matthew Donald]

"error 18:self signed certificate" is the expected result if you are
validating a self-signed cert.

In certificate verification, the code needs to check for X509_V_OK,
X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT
and  X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY.

X509_V_OK is a normal cert verification and the connection can
proceed.  X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY
indicates that an otherwise valid cert has been processed, but the issuer
is unknown.  X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT indicates that a
self-signed cert was read.  Any other return value is a fatal error
(signature failure etc).

Matthew


On 1 July 2016 at 05:34, Carl Heyendal  wrote:

> I am working with the example apps in the "Networking Security with
> OpenSSL" book and up until now have been able to get client/server examples
> 1,2,3 to work. But now I'm trying to connect to an in-house tool but I'm
> getting the error "error 18:self signed certificate". Despite this error
> when I run my app (essentially client3), when I use s_client with the very
> same credentials...it works.
>
> I suspect that it has something to do with the ssl/tls api combination
> that I use in my 'client3' app.
>
> Here's the command and output for s_client that connects to the in-house
> tool which works:
>
> > openssl s_client -connect 192.168.1.99:16001 -CAfile
> ../_security/SipInspector/certificate.pem -key ../_security/client.pem
>   Enter pass phrase for ../_security/client.pem:
>   CONNECTED(0003)
>   depth=0 C = CA, ST = Ontario, L = Ottawa, O = SIP Inspector Ltd, OU
>  = Development, CN = 192.168.1.99
>   verify return:1
>   ---
>   Certificate chain
>0 s:/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector
> Ltd/OU=Development/CN=192.168.1.99
>  i:/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector
> Ltd/OU=Development/CN=192.168.1.99
>   ---
>   Server certificate
>   -BEGIN CERTIFICATE-
>   MIIFxTCCA62gAwIBAgIJALKQ3J5SEyjPMA0GCSqGSIb3DQEBCwUAMHkxCzAJBgNV
>   BAYTAkNBMRAwDgYDVQQIDAdPbnRhcmlvMQ8wDQYDVQQHDAZPdHRhd2ExGjAYBgNV
> (snip)
>   pt/q5/gKqRFbjyL0LDNz49vaSUYvbu3mgF2480Or4X+GPwemwdxJaF1pQw4C1WaF
>   RyfVjDrLNhTvv+zKCbEPyrjXCweNVRVcp8lZ8R0HmXwfgevlCNz/GQo=
>   -END CERTIFICATE-
>   subject=/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector
> Ltd/OU=Development/CN=192.168.1.99
>   issuer=/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector
> Ltd/OU=Development/CN=192.168.1.99
>   ---
>   No client certificate CA names sent
>   ---
>   SSL handshake has read 2309 bytes and written 509 bytes
>   ---
>   New, TLSv1/SSLv3, Cipher is ECDHE-RSA-DES-CBC3-SHA
>   Server public key is 4096 bit
>   Secure Renegotiation IS supported
>   Compression: NONE
>   Expansion: NONE
>   SSL-Session:
>   Protocol  : TLSv1.2
>   Cipher: ECDHE-RSA-DES-CBC3-SHA
>   Session-ID:
>  5755C781D91CF3177DF624EA3599EE430DAB4790F325FAD9378FEAE7731C4497
>   Session-ID-ctx:
>   Master-Key:
> D149008E43E29D658D29418C9F770B3D6018B1D7CA2F493027B0AC7C3BA8E53B572B68C371153568B8988A1E5F351839
>   Key-Arg   : None
>   PSK identity: None
>   PSK identity hint: None
>   SRP username: None
>   Start Time: 1465239425
>   Timeout   : 300 (sec)
>   Verify return code: 0 (ok)
>---
>
>
> Here's the command and output when I run my app that tries to connect to
> the same in-house tool which fails:
>
> > ./client3 192.168.1.99
> Enter PEM pass phrase:
> connecting to 192.168.1.99:16001
>  -Error with certificate at depth: 0
>issuer   = /C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector
> Ltd/OU=Development   /CN=192.168.1.99
>subject  = /C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector
> Ltd/OU=Development/CN=192.168.1.99
>err 18:self signed certificate
>  ** client3.c:94 Error connecting SSL object
> 139788992993088:error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
> failed:s3_clnt.c:1180:
> >
>
> Here are the api's I call in the my app that utilize the same credentials
> used by the s_client command:
>
>  SSL_CTX_new(SSLv23_method());
>  SSL_CTX_load_verify_locations(ctx,
> "../_security/SipInspector/certificate.pem", NULL)
>  SSL_CTX_use_PrivateKey_file(ctx, "../_security/client.pem",
> SSL_FILETYPE_PEM)
>  SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback);
>  SSL_CTX_set_verify_depth(ctx, 4);
>  SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2);
>
> And also I used the openssl verify command to double chec

[openssl-users] self-signed certificate won't work in my app but works with s_client

[Carl Heyendal]

I am working with the example apps in the "Networking Security with OpenSSL" 
book and up until now have been able to get client/server examples 1,2,3 to 
work. But now I'm trying to connect to an in-house tool but I'm getting the 
error "error 18:self signed certificate". Despite this error when I run my app 
(essentially client3), when I use s_client with the very same credentials...it 
works.

I suspect that it has something to do with the ssl/tls api combination that I 
use in my 'client3' app.

Here's the command and output for s_client that connects to the in-house tool 
which works:

> openssl s_client -connect 192.168.1.99:16001 -CAfile 
../_security/SipInspector/certificate.pem -key ../_security/client.pem
  Enter pass phrase for ../_security/client.pem:
  CONNECTED(0003)
  depth=0 C = CA, ST = Ontario, L = Ottawa, O = SIP Inspector Ltd, OU   =   
  Development, CN = 192.168.1.99
  verify return:1
  ---
  Certificate chain
   0 s:/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
 i:/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
  ---
  Server certificate
  -BEGIN CERTIFICATE-
  MIIFxTCCA62gAwIBAgIJALKQ3J5SEyjPMA0GCSqGSIb3DQEBCwUAMHkxCzAJBgNV
  BAYTAkNBMRAwDgYDVQQIDAdPbnRhcmlvMQ8wDQYDVQQHDAZPdHRhd2ExGjAYBgNV
(snip)
  pt/q5/gKqRFbjyL0LDNz49vaSUYvbu3mgF2480Or4X+GPwemwdxJaF1pQw4C1WaF
  RyfVjDrLNhTvv+zKCbEPyrjXCweNVRVcp8lZ8R0HmXwfgevlCNz/GQo=
  -END CERTIFICATE-
  subject=/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
  issuer=/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
  ---
  No client certificate CA names sent
  ---
  SSL handshake has read 2309 bytes and written 509 bytes
  ---
  New, TLSv1/SSLv3, Cipher is ECDHE-RSA-DES-CBC3-SHA
  Server public key is 4096 bit
  Secure Renegotiation IS supported
  Compression: NONE
  Expansion: NONE
  SSL-Session:
  Protocol  : TLSv1.2
  Cipher: ECDHE-RSA-DES-CBC3-SHA
  Session-ID:   
5755C781D91CF3177DF624EA3599EE430DAB4790F325FAD9378FEAE7731C4497
  Session-ID-ctx: 
  Master-Key: 
D149008E43E29D658D29418C9F770B3D6018B1D7CA2F493027B0AC7C3BA8E53B572B68C371153568B8988A1E5F351839
  Key-Arg   : None
  PSK identity: None
  PSK identity hint: None
  SRP username: None
  Start Time: 1465239425
  Timeout   : 300 (sec)
  Verify return code: 0 (ok)
   ---


Here's the command and output when I run my app that tries to connect to the 
same in-house tool which fails:

> ./client3 192.168.1.99
Enter PEM pass phrase:
connecting to 192.168.1.99:16001
 -Error with certificate at depth: 0
   issuer   = /C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector Ltd/OU=Development  
 /CN=192.168.1.99
   subject  = /C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
   err 18:self signed certificate
 ** client3.c:94 Error connecting SSL object
139788992993088:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:1180:
> 

Here are the api's I call in the my app that utilize the same credentials used 
by the s_client command:

 SSL_CTX_new(SSLv23_method());
 SSL_CTX_load_verify_locations(ctx, 
"../_security/SipInspector/certificate.pem", NULL)
 SSL_CTX_use_PrivateKey_file(ctx, "../_security/client.pem", SSL_FILETYPE_PEM)
 SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback);
 SSL_CTX_set_verify_depth(ctx, 4);
 SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2);

And also I used the openssl verify command to double check the certificate 
against itself (not sure if this really does anything).

Any help would be appreciated.



Carl Heyendal | Software Developer 
1826 Robertson Road | Ottawa, ON K2H 5Z6 | CANADA
Office: +1 613-725-2980 x149





***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are 
hereby notified that any review, use, disclosure, dissemination, distribution 
or copying of this message and any attachments is strictly prohibited. If you 
have received this email in error, please immediately notify the sender and 
destroy this e-mail and any attachments and all copies, whether electronic or 
printed. Please also note that any views, opinions, conclusions or commitments 
expressed in this message are those of the individual sender and do not 
necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are 
not binding on Fortinet and only a writing manually signed by Fortinet's 
General Counsel can be a binding commitm

RE: Error 18: self signed certificate

[Mark Currie]

Thank you for your advice. SSL_CTX_get_cert_store() was the right clue and
X509_STORE_add_cert() did the trick.

> -Original Message-
> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Dave Thompson
> Sent: 19 November 2013 00:07
> To: openssl-users@openssl.org
> Subject: RE: Error 18: self signed certificate
> 
> > From: owner-openssl-users On Behalf Of Mark Currie
> > Sent: Monday, November 18, 2013 03:24
> 
> > I also managed to get self-signed certs to work like this but does
> > anyone know how to use self-signed certs in a RAM-only environment
> > i.e. no disk available?
> >
> Your OS or C runtime might provide a RAM filesystem in which case you can
> use that, assuming you have the cert(s) to put in it. Otherwise as I said
> earlier, build SSL_CTX cert_store by hand, ditto.
> 
> Both these assume you have some permanent storage, maybe FLASH or even
> ROM. Presumably the program comes from somewhere secure, so at worst
> you can embed the cert data in your program, either as plain C data or as
> something like a 'resource' in Windows or MacOS.
> 
> > > -Original Message-
> > > From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> > > us...@openssl.org] On Behalf Of Manoj
> > > Sent: 18 November 2013 10:09
> > > To: openssl-users@openssl.org
> > > Subject: Re: Error 18: self signed certificate
> > >
> > > Thanks Guys for the help, I got it working by loading the location
> > > using
> > API
> > > SSL_CTX_load_verify_locations(). The location where I have the
> certificate
> > > available.
> > >
> > > I have another question related to certification verification itself.
> > > Can by any mean, I verify a peer certificate(self signed) without
> > > having
> > it in
> > > the trust-store?
> > >  or
> > > Let me put in other words , Server application verifiying clients
> > > with
> > each
> > > client having its own self signed certificate, Does the server
> > > require
> any
> > prior
> > > information about certificates (i.e. having them as part of cert
> > > trust
> > store)?
> > >
> For OpenSSL to do the verification it must have cert in truststore, yes.
> (To be exact it must have the root; for selfsigned the root is the cert.)
> 
> You can override or replace OpenSSL's verification using the callback(s),
but
> what will you use instead? There's nothing in a selfsigned cert by itself
> (without a truststore) that can't be faked. Instead of full certs you
could
> configure the peer=client publickey values and accept any cert using that
> value -- assuming handshake succeeds through Finished which also proves
> client possession of the privatekey.
> That's what ssh does, with a shortcut for configuration on first use.
> You could configure hashes of the publickeys -- even with MD5 and probably
> SHA1 broken for collision AFAIK there's no 2nd-preimage.
> You could configure hashes of the certs -- ditto -- although that would
make
> it harder to debug cases where a client created multiple certs for the
same
> key -- perhaps one by mistake and a corrected one -- and one of you has
the
> wrong one.
> 
> If you have more than a few authenticated clients, it is usually easier to
issue
> them certs under a CA -- either your own ad-hoc CA, which can be done with
> OpenSSL, or a 'real' public or organization CA -- and the server then only
> needs that one cert. Note if you use a CA that issues EE certs under an
> intermediate or "chain" cert -- which (all?) public ones do now --
according to
> standard the client should be configured to send the chain certs. However
> OpenSSL relier will fill in missing chain certs from its truststore, so it
may be
> easier to just configure them once on the server.
> 
> > > Or
> > > Is there any way possible of getting peer certificate without having
> > > set
> > the
> > > SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback);
> > >
> For *server* to get *client* cert, you must set SSL_VERIFY_PEER. It's your
> choice whether to use a callback or not (you can set it null). For
> *some* clients you may also need to call _set_client_CA_list to tell the
client
> which cert you want when it has more than one, but for simple OpenSSL
> clients they just use the one (per kx) configured cert&key without
checking if
> it matches the server request.
> 
> For *client* to get *server* cert you don't actua

RE: Error 18: self signed certificate

[Dave Thompson]

> From: owner-openssl-users On Behalf Of Mark Currie
> Sent: Monday, November 18, 2013 03:24

> I also managed to get self-signed certs to work like this but does anyone
> know how to use self-signed certs in a RAM-only environment i.e. no disk
> available?
> 
Your OS or C runtime might provide a RAM filesystem in which case you can 
use that, assuming you have the cert(s) to put in it. Otherwise as I said 
earlier, build SSL_CTX cert_store by hand, ditto.

Both these assume you have some permanent storage, maybe FLASH 
or even ROM. Presumably the program comes from somewhere secure,
so at worst you can embed the cert data in your program, either as plain C 
data or as something like a 'resource' in Windows or MacOS. 

> > -Original Message-
> > From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> > us...@openssl.org] On Behalf Of Manoj
> > Sent: 18 November 2013 10:09
> > To: openssl-users@openssl.org
> > Subject: Re: Error 18: self signed certificate
> >
> > Thanks Guys for the help, I got it working by loading the location using
> API
> > SSL_CTX_load_verify_locations(). The location where I have the
certificate
> > available.
> >
> > I have another question related to certification verification itself.
> > Can by any mean, I verify a peer certificate(self signed) without having
> it in
> > the trust-store?
> >  or
> > Let me put in other words , Server application verifiying clients with
> each
> > client having its own self signed certificate, Does the server require
any
> prior
> > information about certificates (i.e. having them as part of cert trust
> store)?
> >
For OpenSSL to do the verification it must have cert in truststore, yes.
(To be exact it must have the root; for selfsigned the root is the cert.)

You can override or replace OpenSSL's verification using the callback(s),
but what will you use instead? There's nothing in a selfsigned cert by 
itself (without a truststore) that can't be faked. Instead of full certs 
you could configure the peer=client publickey values and accept 
any cert using that value -- assuming handshake succeeds through 
Finished which also proves client possession of the privatekey.
That's what ssh does, with a shortcut for configuration on first use.
You could configure hashes of the publickeys -- even with MD5 and 
probably SHA1 broken for collision AFAIK there's no 2nd-preimage.
You could configure hashes of the certs -- ditto -- although that 
would make it harder to debug cases where a client created multiple 
certs for the same key -- perhaps one by mistake and a corrected one -- 
and one of you has the wrong one.

If you have more than a few authenticated clients, it is usually easier 
to issue them certs under a CA -- either your own ad-hoc CA, which 
can be done with OpenSSL, or a 'real' public or organization CA -- 
and the server then only needs that one cert. Note if you use 
a CA that issues EE certs under an intermediate or "chain" cert -- 
which (all?) public ones do now -- according to standard the client 
should be configured to send the chain certs. However OpenSSL 
relier will fill in missing chain certs from its truststore, so it may be 
easier to just configure them once on the server.

> > Or
> > Is there any way possible of getting peer certificate without having set
> the
> > SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback);
> >
For *server* to get *client* cert, you must set SSL_VERIFY_PEER. It's 
your choice whether to use a callback or not (you can set it null). For 
*some* clients you may also need to call _set_client_CA_list to tell 
the client which cert you want when it has more than one, but for 
simple OpenSSL clients they just use the one (per kx) configured 
cert&key without checking if it matches the server request.

For *client* to get *server* cert you don't actually have to do anything;
if handshake selects a suite that uses certs, you get the cert, period. 
If it selects a suite that doesn't use certs (either noncert auth like
Kerberos,
or no authentication at all) you never get a cert no matter what you set.



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Error 18: self signed certificate

[Mark Currie]

Hi

I also managed to get self-signed certs to work like this but does anyone
know how to use self-signed certs in a RAM-only environment i.e. no disk
available?

> -Original Message-
> From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
> us...@openssl.org] On Behalf Of Manoj
> Sent: 18 November 2013 10:09
> To: openssl-users@openssl.org
> Subject: Re: Error 18: self signed certificate
> 
> Thanks Guys for the help, I got it working by loading the location using
API
> SSL_CTX_load_verify_locations(). The location where I have the certificate
> available.
> 
> I have another question related to certification verification itself.
> Can by any mean, I verify a peer certificate(self signed) without having
it in
> the trust-store?
>  or
> Let me put in other words , Server application verifiying clients with
each
> client having its own self signed certificate, Does the server require any
prior
> information about certificates (i.e. having them as part of cert trust
store)?
> 
> Or
> Is there any way possible of getting peer certificate without having set
the
> SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback);
> 
> Regards
> Manoj
> 
> 
> 
> --
> View this message in context: http://openssl.6102.n7.nabble.com/Error-18-
> self-signed-certificate-tp47361p47388.html
> Sent from the OpenSSL - User mailing list archive at Nabble.com.
> __
> 
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager   majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Error 18: self signed certificate

[Manoj]

Thanks Guys for the help, I got it working by loading the location using API
SSL_CTX_load_verify_locations(). The location where I have the certificate
available.

I have another question related to certification verification itself.
Can by any mean, I verify a peer certificate(self signed) without having it
in the trust-store? 
 or 
Let me put in other words , Server application verifiying clients with each
client having its own self signed certificate, Does the server require any
prior information about certificates (i.e. having them as part of cert trust
store)? 

Or 
Is there any way possible of getting peer certificate without having set the
SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback);

Regards
Manoj



--
View this message in context: 
http://openssl.6102.n7.nabble.com/Error-18-self-signed-certificate-tp47361p47388.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Error 18: self signed certificate

[Elluru, Krishna]

HI Manoj
if you check the documentation, it shows
18 X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT: self signed certificatethe
passed certificate is self signed and the same certificate cannot be found
in the list of trusted certificates.

corresponding code can be found in x509_vfy.c, where you need to add the
ceritificate to trusted list.

if (ctx->check_issued(ctx, x, x))
{
/* we have a self signed certificate */
if (sk_X509_num(ctx->chain) == 1)
{
/* We have a single self signed certificate: see if
 * we can find it in the store. We must have an exact
 * match to avoid possible impersonation.
 */
ok = ctx->get_issuer(&xtmp, ctx, x);
if ((ok <= 0) || X509_cmp(x, xtmp))
{

ctx->error=X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT; >> this is the
error you are getting.
ctx->current_cert=x;
ctx->error_depth=i-1;
if (ok == 1) X509_free(xtmp);
bad_chain = 1;
ok=cb(0,ctx);
if (!ok) goto end;
}
else 
{
/* We have a match: replace certificate with 
store version
 * so we get any trust settings.
 */
X509_free(x);
x = xtmp;
(void)sk_X509_set(ctx->chain, i - 1, x);
ctx->last_untrusted=0;
}
}

Thanks
Krishna Mohan.

From:  Manoj 
Reply-To:  "openssl-users@openssl.org" 
Date:  Friday, 15 November 2013 2:27 PM
To:  "openssl-users@openssl.org" 
Subject:  Error 18: self signed certificate


self signed certificate
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Error 18: self signed certificate

[Dave Thompson]

> From: owner-openssl-users On Behalf Of Martin Hecht
> Sent: Friday, November 15, 2013 12:28

> Maybe there are some means to add the certificate to "trusted
> certificates", maybe it is sufficient  to copy it somewhere, where your
> openssl looks for trusted certificates (in Linux it is usually
> /etc/ssl/certs/, in Windows I'm not sure, probably some folder below
> programs\openssl or so).
> 
But only if your app calls SSL_CTX_default_verify_paths (it's not 
automatic default for a custom app, as it is for commandline).
If you have commandline from the same build (as you should) 
'openssl version -d' (or -a) tells you where the the default is.

Alternatively you can put the truststore files anywhere you like 
and call SSL_CTX_set_verify_locations. This can be useful if you 
want different trust rules for different applications or users, 
but extra work and opportunity for mistakes if you don't.
Or if you don't have the certs in files at all, you can hand-build 
SSL_CTX_get/set_cert_store , but that's more work.
Apparently there will be more extensive APIs in 1.0.2.

> If it doesn't work with self-signed certifcates at all, the openssl ca
> command would be a simple option to generate a few certificates signed
> by the self-signed one. You would put the self-signed certificate into
> the trusted certificates folder on the client and the server and use two
> other certificates in the API on the client and the server respectively.
> 
OpenSSL relier (client) definitely does support selfsigned cert if it's in
the 
truststore. It is more flexible and often convenient to use one selfsigned 
root to issue other certs, but it's not necessary. Also a nit: 'ca' is the
original 
and arguably better way to issue child certs, but for some time 'x509 -req'
is also capable of doing so with some limitations.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Error 18: self signed certificate

[Walter H.]

Windows has its own System wide certificate store;

look at  certmgr.msc

keep in mind, that some applications have their own store
e.g.  Mozilla ThunderBird, Mozilla FireFox
and some other can use this system wide certificate store
e.g. Adobe Reader/Pro/Std

Walter

On 15.11.2013 09:57, Manoj wrote:
Hi, I am trying to create a client/server application on windows 7, 
where I have used self signed certificate at server side as well as at 
client side. I used SSL_CTX_use_certificate_file and then 
SSL_CTX_use_PrivateKey_file API to load the certificate and key. When 
there is a SSL_connect() call from client, the handshaking fails with 
the error stating Error 18: self signed certificate. So I want help 
related to- how to use and verify self signed certificate. The 
certificate are generated by using following command openssl req -x509 
-nodes -days 1059 -newkey rsa:2048 -keyout testkey.pem -out 
testcert.pem -config pathtoconfig\openssl.cnf Regards Manoj
View this message in context: Error 18: self signed certificate 
<http://openssl.6102.n7.nabble.com/Error-18-self-signed-certificate-tp47361.html>
Sent from the OpenSSL - User mailing list archive 
<http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html> at Nabble.com.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Error 18: self signed certificate

[Martin Hecht]

Hi Manoj,

I don't know this API, but I believe it complains about the fact that
the certificate is self-signed.

Maybe there are some means to add the certificate to "trusted
certificates", maybe it is sufficient  to copy it somewhere, where your
openssl looks for trusted certificates (in Linux it is usually
/etc/ssl/certs/, in Windows I'm not sure, probably some folder below
programs\openssl or so).

If it doesn't work with self-signed certifcates at all, the openssl ca
command would be a simple option to generate a few certificates signed
by the self-signed one. You would put the self-signed certificate into
the trusted certificates folder on the client and the server and use two
other certificates in the API on the client and the server respectively.

best regards,
Martin

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Error 18: self signed certificate

[Manoj]

Hi, I am trying to create a client/server application on windows 7, where I
have used self signed certificate at server side as well as at client side.
I used SSL_CTX_use_certificate_file and then SSL_CTX_use_PrivateKey_file API
to load the certificate and key.When there is a SSL_connect() call from
client, the handshaking fails with the error statingError 18: self signed
certificate. So I want help related to- how to use and verify self signed
certificate.The certificate are generated by using following commandopenssl
req -x509 -nodes -days 1059 -newkey rsa:2048 -keyout testkey.pem -out
testcert.pem -config pathtoconfig\openssl.cnfRegardsManoj



--
View this message in context: 
http://openssl.6102.n7.nabble.com/Error-18-self-signed-certificate-tp47361.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

Re: Verifying self-signed certificate

[Martin Hecht]

Hi Manoj,

if you want to generate just one selfsigned
certificate, this would be the easiest:

# generate key and self signed cert with one command
openssl req -x509 -nodes -days 3650 \
 -subj '/C=DE/ST=some-state/L=somewhere/CN=example.com' \
 -newkey rsa:1024 -keyout key.pem -out cert.pem

# verify it "against itself"
openssl verify -CAfile cert.pem cert.pem

Is this what you are looking for? However,
if you want to use the demoCA built-in with
openssl (which is a strange approach for generating
selfsigned certificates) it would look like this:

# first generate a key
openssl genrsa -out key.pem 2048

# generate a request with this key
openssl req -new -key key.pem \
 -subj '/C=DE/ST=some-state/L=somewhere/O=Test/CN=example.com' \
 -out req.pem

# create the directory structures needed (see your openssl.cnf)
mkdir -p ./demoCA/newcerts
touch ./demoCA/index.txt
echo 00 > ./demoCA/serial

# issue a selfsigned certificate
openssl ca -in req.pem -keyfile key.pem -selfsign -out file.pem

# verify it
openssl verify -CAfile file.pem file.pem

# or you could have a look at the one which ends up in the
# directory where newly issued certificates are stored
openssl verify -CAfile file.pem demoCA/newcerts/00.pem

# look at the file in text form, just to complete the list
# of widely used commands :-)
openssl x509 -in file.pem -noout -text

PS: I have tested this with OpenSSL 0.9.8k in Ubuntu 10.04 LTS

best regards,
Martin

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Verifying self-signed certificate

[Manoj]

Hi,

Can you post the complete command to generate the self signed certificate ,
the case where the verification worked for you?

Thanks



--
View this message in context: 
http://openssl.6102.n7.nabble.com/Verifying-self-signed-certificate-tp18922p47362.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

verifying signature of self-signed certificate

[Dimitrios Apostolou]

Hello list,

given that I know in advance the remote end's RSA public key, and that the 
remote end is responding to my TLS handshake with a self-signed 
certificate signed by his private RSA key, then what is the proper way of 
verifying that nobody has tampered with the connection?


What I am currently doing is twofold:

1. compare the stored key with the one received via
   X509_get_pubkey(SSL_get_peer_certificate())
2. Verify that it was indeed signed by the remote peer:
   X509_verify(received_cert, received_pubkey)


Thanks in advance,
Dimitris

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Self-Signed Certificate Verification failure

[isshed]

Thanks Dave for the response.


On Wed, May 15, 2013 at 11:29 PM, Dave Thompson wrote:

> >From: owner-openssl-us...@openssl.org On Behalf Of isshed
> >Sent: Wednesday, 15 May, 2013 08:25
>
> >I have a self-signed certificate installed on a server with
> >the following extensions fields.
> >Key Usage:Digital Signature, Key Encipherment (a0)
> >Basic Constraints :   Subject Type=End Entity, Path Length Constraint=None
> >Enhanced Key Usage: Server Authentication (1.3.6.1.5.5.7.3.1),
> >Client Authentication (1.3.6.1.5.5.7.3.2)
>
> >Now when my client tries to make a TLS connection with this server.
> >The client sends Client Hello and then the server responds with
> >Server Hello(which has the above self-signed certificate).
>
> Nit: the server sends a series of records; the record that contains
> the cert is not the ServerHello record. But the server does send
> the configured cert, which is the important point.
>

>>>ISSHED>> Yes I agree that the server is sending series of
records(certificate is one of them). This is not important for me. for me
Important point is what should be the key usage content.

>
> >I installed this self-signed certificate with on my client.
> >My client is not able to verify the certificate and is terminating
> >the TLS connection with Alert message(Unknown CA).
> >My client is using openssl version "OpenSSL 1.0.1e".
>
> As explained in "Self-signed certificates and keyUsage extension"
> recently (5/10-11) OpenSSL validation requires that an "issuing"
> cert have keyusage including CertSign (or omitted = all usage) --
> and that includes a self-issued aka self-signed cert.
>


> >>>ISSHED>> So you mean to say that the Self-signed Root Certificate
> should either does not contain this "Key Usage Extension" or if it contains
> it should have keyCertSign field set. then only the public key will be
> used to verify the certificate? Am i correct ?



Thanks

>
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager   majord...@openssl.org
>

RE: Self-Signed Certificate Verification failure

[Dave Thompson]

>From: owner-openssl-us...@openssl.org On Behalf Of isshed
>Sent: Wednesday, 15 May, 2013 08:25

>I have a self-signed certificate installed on a server with 
>the following extensions fields.
>Key Usage:Digital Signature, Key Encipherment (a0)
>Basic Constraints :   Subject Type=End Entity, Path Length Constraint=None
>Enhanced Key Usage: Server Authentication (1.3.6.1.5.5.7.3.1), 
>Client Authentication (1.3.6.1.5.5.7.3.2)

>Now when my client tries to make a TLS connection with this server. 
>The client sends Client Hello and then the server responds with 
>Server Hello(which has the above self-signed certificate). 

Nit: the server sends a series of records; the record that contains 
the cert is not the ServerHello record. But the server does send 
the configured cert, which is the important point.

>I installed this self-signed certificate with on my client. 
>My client is not able to verify the certificate and is terminating 
>the TLS connection with Alert message(Unknown CA).
>My client is using openssl version "OpenSSL 1.0.1e".

As explained in "Self-signed certificates and keyUsage extension" 
recently (5/10-11) OpenSSL validation requires that an "issuing" 
cert have keyusage including CertSign (or omitted = all usage) -- 
and that includes a self-issued aka self-signed cert. 

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Self-Signed Certificate Verification failure

[isshed]

Hi all,

I have a self-signed certificate installed on a server with the following
extensions fields.

=
Key Usage:Digital Signature, Key Encipherment (a0)
--
Basic Constraints :   Subject Type=End Entity, Path Length Constraint=None
--
Enhanced Key Usage: Server Authentication (1.3.6.1.5.5.7.3.1), Client
Authentication (1.3.6.1.5.5.7.3.2)
=

Now when my client tries to make a TLS connection with this server. The
client sends Client Hello and then the server responds with Server
Hello(which has the above self-signed certificate). I installed this
self-signed certificate with on my client. My client is not able to verify
the certificate and is terminating the TLS connection with Alert
message(Unknown CA).

Could any one please let me know why client is not able to verify the
certificate? My client is using openssl version "OpenSSL 1.0.1e".


Thanks,

RE: Automating self signed certificate creation

[Dave Thompson]

> From: owner-openssl-us...@openssl.org On Behalf Of Mauricio Tavares
> Sent: Friday, 02 November, 2012 16:53

> On Fri, Nov 2, 2012 at 4:23 PM, Ken Goldman 
>  wrote:
> > I create a self signed certificate using
> >
> >> openssl req -new -x509 -key ... -out ... -days ...
> >
> > It then prompts for the country, state, locality, etc.
> >
> > Is there a way to enter that data on the command line or in 
> a configuration
> > file to avoid the prompts?  I tried -config and a 
> configuration file, but
> > that seems to just change the defaults.  It still prompts.

>   Try something like:
> 
> -subj "/C=US/ST=Florida/L=Waldo/O=Mythical Mad Monkeys, 
> GmbH./OU=IT/CN=$FQDN"
> 
> as an argument to your openssl statement.

as described in the manpage for req; or put prompt=no 
and values *instead of* prompts in the config file 
as described further down in the same manpage.

Note: it doesn't make clear that if you use a config 
file with prompt=no and values, you can't override with 
commandline -subj. -subj only overrides prompt=yes.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Automating self signed certificate creation

[Felipe Gasper]

On 2.11.12 3:23 PM, Ken Goldman wrote:

I create a self signed certificate using

 > openssl req -new -x509 -key ... -out ... -days ...

It then prompts for the country, state, locality, etc.

Is there a way to enter that data on the command line or in a
configuration file to avoid the prompts?  I tried -config and a
configuration file, but that seems to just change the defaults.  It
still prompts.


Yes: pass in the -subj parameter. Backslash-escape foreslashes and 
backslashes.


-F
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Automating self signed certificate creation

[Mauricio Tavares]

On Fri, Nov 2, 2012 at 4:23 PM, Ken Goldman  wrote:
> I create a self signed certificate using
>
>> openssl req -new -x509 -key ... -out ... -days ...
>
> It then prompts for the country, state, locality, etc.
>
> Is there a way to enter that data on the command line or in a configuration
> file to avoid the prompts?  I tried -config and a configuration file, but
> that seems to just change the defaults.  It still prompts.
>
> Rationale:
>
> I can script it and avoid user errors.
> I can automate changing the values for regression testing.
>
  Try something like:

-subj "/C=US/ST=Florida/L=Waldo/O=Mythical Mad Monkeys, GmbH./OU=IT/CN=$FQDN"

as an argument to your openssl statement.

> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Automating self signed certificate creation

[Ken Goldman]

I create a self signed certificate using

> openssl req -new -x509 -key ... -out ... -days ...

It then prompts for the country, state, locality, etc.

Is there a way to enter that data on the command line or in a 
configuration file to avoid the prompts?  I tried -config and a 
configuration file, but that seems to just change the defaults.  It 
still prompts.


Rationale:

I can script it and avoid user errors.
I can automate changing the values for regression testing.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: exception when using Self Signed Certificate

[Dave Thompson]

>From: owner-openssl-us...@openssl.org On Behalf Of Mithun Kumar
>Sent: Thursday, 04 October, 2012 14:31

>I have a self signed certificate created and i have loaded that 
>into a trust store of the client. I have also configured the Server 
>with that self signed certificate. So when i try to establish 
>connection i get the  exception in following code

>v3_purp.c

>else if(ku_reject(issuer, KU_KEY_CERT_SIGN))
>return X509_V_ERR_KEYUSAGE_NO_CERTSIGN;   //Exception thrown here

Aside: C doesn't "throw" exceptions as some other languages do 
(including C++). This is really "returned", or at most "raised".
But that doesn't affect your point.

>Any inputs why client is throwing X509_V_ERR_KEYUSAGE_NO_CERTSIGN
exception?

Because the cert has a KeyUsage extension that excludes certSign. 
OpenSSL requires issuer certs to have certSign -- and treats a 
selfsigned cert as issuing itself, which is somewhat debatable.

>Here my server is Microsoft SQL Server , Client uses openssl. Also this 
>issue occurs only when i create a self signed certificate using IIS
server!!!

You create with IIS but use in SQLserver? On the (one) IIS-manager 
I have access to (but don't normally use) "create self-signed cert..." 
creates KU keyEncrypt,dataEncrypt and EKU serverAuth -- which 
violates RFC 5280 as I read it but hey that's Microsoft for you. 
(And per RFC 5246 it allows only plain RSA not DHE-RSA or ECDHE-RSA, 
but plain RSA is widely supported, probably widest.)

Options:

- create (or get created) a key + selfsigned cert with KU having 
certSign in addition to keyEncrypt (and preferably digSign), 
or KU omitted (then relier must default to allow-all-usage).
This is easy to do with openssl 'req -new -x509'.

- use a CA-issued cert, where the CA's root and issued certs have 
desired or omitted KU. A real CA already does this, and one you 
create with openssl ('ca' or just 'x509 -req') easily can.



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Self-signed certificate

[Curt Sampson]

On 2012-09-24 20:55 + (Mon), Nou Dadoun wrote:

> Quick question: is there a simple openssl api call which will tell me
> if an x509 certificate is self-signed? ... N

Will simply comparing the issuer and the subject DNs in the cert do what
you need? Or do you need to check validity, the AuthorityKeyIdentifier
extension, and suchlike?

Also, you'll get more replies if you post a fresh message to the list
when you have a fresh question, rather than replying to a mesasge deep
in an unrelated topic chain that people might be ignoring.

cjs
-- 
Curt Sampson  +81 90 7737 2974

It is easier to write an incorrect program than understand a correct one.
--Alan Perlis, Epigrams on Programming (#7)
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Self-signed certificate

[Nou Dadoun]

Quick question: is there a simple openssl api call which will tell me if an 
x509 certificate is self-signed?  ... N

---
Nou Dadoun
ndad...@teradici.com
604-628-1215 

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: CA for IIS-issued self-signed certificate?

[Dave Thompson]

> From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills
> Sent: Tuesday, 14 August, 2012 08:09

> > if your self-signed cert has a KeyUsage extension that does 
> > not include certSign, 
> > OpenSSL skips it for chain-building, resulting in verify 20.
> 
> Looks like the latter to me. Please look below and tell me if 
> you don't
> agree. If so, I fear it is unsolvable, but it does not really 
> matter as the
> Kiwi is just for testing and if I know why it is failing that 
> is almost as
> good as it succeeding. 

> Certificate:

> X509v3 extensions:
> X509v3 Key Usage:
> Key Encipherment, Data Encipherment

Yes, that's KeyUsage without certSign. Since problem-understood 
is sufficient for you in this situation, fine.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: CA for IIS-issued self-signed certificate?

[Charles Mills]

Dave -

Thanks much!

> If the filename can't be opened SSL_CTX_load_verify_locations returns
false. Your code does check for that, I hope.

Good to know. Thanks. (Sometime APIs just "stash" a name somewhere for use
later.) Yes, I check every return code and put out a good error message if
the call fails.

> the Windows *API* has no problem with space in filename (unlike some
Windows *UIs*).

Like, say, VBA, or at least the MS-Word fields.

> And it actually accepts either slash or backslash separator

Right, I knew that, but I should remember it with MS-Word (which I use a lot
for documentation). Not having to escape \ would be a small step forward.
Thanks.

> Make sure ... the Subject and Issuer names are *exactly* the same

> if your self-signed cert has a KeyUsage extension that does not include
certSign, 
> OpenSSL skips it for chain-building, resulting in verify 20.

Looks like the latter to me. Please look below and tell me if you don't
agree. If so, I fear it is unsolvable, but it does not really matter as the
Kiwi is just for testing and if I know why it is failing that is almost as
good as it succeeding. I can bypass the verify failure and use it to test
everything else. My own client and server with a more conventional cert and
CA setup is verifying.

Here is a little of the s_client output:

depth=0 /CN=KiwiServer
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /CN=KiwiServer
verify error:num=21:unable to verify the first certificate
verify return:1

And here is the certificate -text

Certificate:
Data:
Version: 3 (0x2)
Serial Number:
62:72:81:ef:1c:37:e2:9b:4f:ce:08:bb:a6:bf:82:03
Signature Algorithm: sha1WithRSAEncryption
Issuer: CN=KiwiServer
Validity
Not Before: Jul 27 21:05:20 2012 GMT
Not After : Jul 27 00:00:00 2013 GMT
Subject: CN=KiwiServer
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):

Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage:
Key Encipherment, Data Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
Signature Algorithm: sha1WithRSAEncryption

-END CERTIFICATE-

Charles

-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson
Sent: Monday, August 13, 2012 7:09 PM
To: openssl-users@openssl.org
Subject: RE: CA for IIS-issued self-signed certificate?

> From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills
> Sent: Saturday, 11 August, 2012 08:57

> I wondered if perhaps there were path or filename specification 
> problems (need to escape backslashes? a problem with embedded spaces?) 
> but I eliminated all of those variables -- put the certificate with a 
> "simple"
> name in the current path.
> 
If the filename can't be opened SSL_CTX_load_verify_locations returns false.
Your code does check for that, I hope.

FWIW, the Windows *API* has no problem with space in filename (unlike some
Windows *UIs*). And it actually accepts either slash or backslash separator
(and sometimes slash is more convenient). 

> What do I look for? How do I get more granularity than "unable to get 
> local issuer certificate"?
> 
Top-level cut: do you get the same error (verify 20) with s_client?
If so, the problem is either the cert or the truststore, and you're
confident of the truststore. Make sure the description as self-signed (or at
least self-issued) is correct, i.e. the Subject and Issuer names are
*exactly* the same. If s_client works, the problem is almost certainly (say
99.9%) in your code.

This reminds me of one possibility that came up with someone else a few
weeks ago: if your self-signed cert has a KeyUsage extension that does not
include certSign, OpenSSL skips it for chain-building, resulting in verify
20. If you look at the cert with the usual Windows tools (inetcpl,
CryptExtOpenCER, mmc) you should be able to see if KeyUsage is present and
if so what is in it, or you can use commandline openssl x509 -text.

If neither of the above, you probably do need to debug, but:

> I'm using a pre-built Windows distribution of OpenSSL 1.0.1c. 
> It will take
> some re-arrangement to be able to trace into OpenSSL.
> 
That's unfortunate.

> 64-bit Windows, if that matters.
> 
It shouldn't, but if there's a bug somewhere, it might.



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Mana

RE: CA for IIS-issued self-signed certificate?

[Dave Thompson]

> From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills
> Sent: Saturday, 11 August, 2012 08:57

> I wondered if perhaps there were path or filename 
> specification problems
> (need to escape backslashes? a problem with embedded spaces?) but I
> eliminated all of those variables -- put the certificate with 
> a "simple"
> name in the current path.
> 
If the filename can't be opened SSL_CTX_load_verify_locations 
returns false. Your code does check for that, I hope.

FWIW, the Windows *API* has no problem with space in filename 
(unlike some Windows *UIs*). And it actually accepts either slash 
or backslash separator (and sometimes slash is more convenient). 

> What do I look for? How do I get more granularity than 
> "unable to get local
> issuer certificate"?
> 
Top-level cut: do you get the same error (verify 20) with s_client?
If so, the problem is either the cert or the truststore, and you're 
confident of the truststore. Make sure the description as self-signed 
(or at least self-issued) is correct, i.e. the Subject and Issuer 
names are *exactly* the same. If s_client works, the problem is 
almost certainly (say 99.9%) in your code.

This reminds me of one possibility that came up with someone else 
a few weeks ago: if your self-signed cert has a KeyUsage extension 
that does not include certSign, OpenSSL skips it for chain-building, 
resulting in verify 20. If you look at the cert with the usual 
Windows tools (inetcpl, CryptExtOpenCER, mmc) you should be able 
to see if KeyUsage is present and if so what is in it, or you can 
use commandline openssl x509 -text.

If neither of the above, you probably do need to debug, but:

> I'm using a pre-built Windows distribution of OpenSSL 1.0.1c. 
> It will take
> some re-arrangement to be able to trace into OpenSSL.
> 
That's unfortunate.

> 64-bit Windows, if that matters.
> 
It shouldn't, but if there's a bug somewhere, it might.



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: CA for IIS-issued self-signed certificate?

[Charles Mills]

I wondered if perhaps there were path or filename specification problems
(need to escape backslashes? a problem with embedded spaces?) but I
eliminated all of those variables -- put the certificate with a "simple"
name in the current path.

What do I look for? How do I get more granularity than "unable to get local
issuer certificate"?

I'm using a pre-built Windows distribution of OpenSSL 1.0.1c. It will take
some re-arrangement to be able to trace into OpenSSL.

64-bit Windows, if that matters.

Charles
-Original Message-
From: Charles Mills [mailto:charl...@mcn.org] 
Sent: Friday, August 10, 2012 8:54 PM
To: 'openssl-users@openssl.org'
Subject: RE: CA for IIS-issued self-signed certificate?

> If you ... subsequently call set_default_verify_paths, the later call
overrides and
> (only) the default file and/or directory are used.

Thanks. I wondered about that. I commented it out though and still get
exactly the same result.

I also added a certificate verify callback. I come through there and get

  err 20:unable to get local issuer certificate

Charles


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: CA for IIS-issued self-signed certificate?

[Charles Mills]

> If you ... subsequently call set_default_verify_paths, the later call
overrides and
> (only) the default file and/or directory are used.

Thanks. I wondered about that. I commented it out though and still get
exactly the same result.

I also added a certificate verify callback. I come through there and get

  err 20:unable to get local issuer certificate

Charles


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: CA for IIS-issued self-signed certificate?

[Dave Thompson]

> From: owner-openssl-us...@openssl.org On Behalf Of CharlesTSR
> Sent: Friday, 10 August, 2012 16:48

> Please bear with me; I'm a real SSL newbie. I am attempting 
> to develop my
> first SSL program, an SSL/TLS client that will communicate 
> with a commercial
> SSL server product (Kiwi Server) that is running on a VM on 
> my system. 
> 
> Kiwi *only* accepts IIS-issued certificates. I issued a 
> certificate using
> IIS 7.5 Manager "Issue Self-Signed Certificate." Windows 7 says "This
> certificate is OK." 
> 
> My client follows the general scheme of the client in Chapter 5 of the
> O'Reilly OpenSSL book. I know am getting the certificate back 
> correctly from
> the server because the FQDN in the certificate is correct. 
> 
> But if I turn on SSL_CTX_set_verify(SslCtx, SSL_VERIFY_PEER, 
> NULL) in my
> client then SSL_connect(SslObj) fails with 8140:error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
> failed:.\ssl\s3_clnt.c:1166: 
> 
> In my context setup I am doing 
> SSL_CTX_load_verify_locations(SslCtx, "path
> of IIS certficate in PEM format", NULL) and
> SSL_CTX_set_default_verify_paths(SslCtx) with no error. 
> Obviously that is
> incorrect or insufficient. 
> 
If you call load_verify_locations and subsequently call 
set_default_verify_paths, the later call overrides and 
(only) the default file and/or directory are used. 
If you don't have the server selfsigned cert there -- 
and for Windows, depending on the build, the default(s) 
may not even exist or be writable -- nothing will verify.

Use just load_verify_locations.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

CA for IIS-issued self-signed certificate?

[CharlesTSR]

[Incorrectly initially posted in dev.]

Please bear with me; I'm a real SSL newbie. I am attempting to develop my
first SSL program, an SSL/TLS client that will communicate with a commercial
SSL server product (Kiwi Server) that is running on a VM on my system. 

Kiwi *only* accepts IIS-issued certificates. I issued a certificate using
IIS 7.5 Manager "Issue Self-Signed Certificate." Windows 7 says "This
certificate is OK." 

My client follows the general scheme of the client in Chapter 5 of the
O'Reilly OpenSSL book. I know am getting the certificate back correctly from
the server because the FQDN in the certificate is correct. 

But if I turn on SSL_CTX_set_verify(SslCtx, SSL_VERIFY_PEER, NULL) in my
client then SSL_connect(SslObj) fails with 8140:error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
failed:.\ssl\s3_clnt.c:1166: 

In my context setup I am doing SSL_CTX_load_verify_locations(SslCtx, "path
of IIS certficate in PEM format", NULL) and
SSL_CTX_set_default_verify_paths(SslCtx) with no error. Obviously that is
incorrect or insufficient. 

Can anyone point me at what I should be doing differently? Thanks much,

-- 
View this message in context: 
http://old.nabble.com/CA-for-IIS-issued-self-signed-certificate--tp34283820p34283820.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: [openssl-users] Weird not-so-self-signed certificate

[Dave Thompson]

> From: owner-openssl-us...@openssl.org On Behalf Of Erwann Abalea
> Sent: Monday, 06 August, 2012 08:06

> The given certificate is correctly self-signed, you can 
> manually check 
> it by extracting the signature block and playing with "openssl rsautl 
> ...", "dd ... | openssl dgst -sha1", etc.
> 
> It fails the validation path check probably because it's not 
> declared as 
> a CA. There's some ongoing work on IETF about DANE certificates and 
> clarifications on RFC5280 about self-signed EE certificates. The 
> presented certificate is certainly such a DANE one.
> 
Specifically, as I responded Friday to a post from Harald Latzko 
"RE: TLS server/client with self-signed certificate" : 
OpenSSL won't verify a self-signed cert *or* a "real" CA cert 
if it has KeyUsage that excludes certSign, as this one does. 

It's not clear to me whether a self-signed cert used only for 
an entity, not to issue other certs, *should* have BC.CA:true, 
but current OpenSSL definitely doesn't require it. (I've 
tested BC.CA:false KU:includes.certSign and OpenSSL works.)

> Le 06/08/2012 13:04, Johannes Bauer a écrit :

> > -BEGIN CERTIFICATE-
> > MIIC8TCCAdmgAwIBAgIQNmL4pIUXFpRBUK7QhJR/JjANBgkqhkiG9w0BAQUFADAg
> > MR4wHAYDVQQDExVXTVN2Yy1XSU4tRUVCSExDODFHSjgwHhcNMTAxMjIzMjAzOTU0
> > WhcNMjAxMjIwMjAzOTU0WjAgMR4wHAYDVQQDExVXTVN2Yy1XSU4tRUVCSExDODFH
> > SjgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD6CNzdS+lWquEQndmY
> > R1XY6cEqeMSB6YVSxXFAARRsdLQceCIpZbD5CijYklx874gOokTwSzZ7EJ6QSPUL
> > jItM5PRlkeh0twrVEU5UTeqybAnVEciL5oVy6EPm4niYweAJrf5QCtPcORtt2Kjs
> > xYAX2Ltl7mjvi+QM+XwDX0LKWyIjpYTZXB/5XRnpzUuBw3pDx+z4fWk8SFqN4Ptb
> > /7fZSoxI6VeuTvrgS4aMyjsPylPnpXVAFYOcxketS0D1F9m0z5t3eD3hXesgbCHS
> > svy0gACF3qvarJiE6MVDaJ/tlX408G9V3gEHpCCrk+yL5FiT/dtr7tNlWMt+o9D4
> > 5/kNAgMBAAGjJzAlMBMGA1UdJQQMMAoGCCsGAQUFBwMBMA4GA1UdDwQHAwUAsAAA
> > ADANBgkqhkiG9w0BAQUFAAOCAQEAYvuUspk2lHiP3IM4maY2DOH0UfSsldyqOICP
> > ue3xmqNnkhN7QBe8GIcsKt3fiozC7L+zcxdIY6L7WgGx1+aK8f3AKl/FojPegMhC
> > WsgNy5WsR+jLUduclZDGf4qXxo9Vs1qXeP4qYZOa1rtqiBfFaQsxs4+XyFHdaB8N
> > HzviKd8NSeCn+ZfUTKYlErUAL+qtLaQQTqVvBVnwR9yT74izZ48f0mX8zHYMFJIk
> > mokioFqzl2ZVF98JBLSy6sNTZfO+eg98g3uDVRwq9JyvsWp1OJ94BvoXFZX7ETDM
> > Z53Hp5s3YUNRptlIvzre/foKg4MZB8BNUsEUdgaGOeoXho7jDA==
> > -END CERTIFICATE-
> >
> > It's seemingly self-signed, but then again -- not. When I 
> call openssl:
> >
> > $ openssl verify -CApath /dev/null -CAfile weird.crt weird.crt
> > weird.crt: /CN=WMSvc-WIN-EEBHLC81GJ8
> > error 20 at 0 depth lookup:unable to get local issuer certificate
> >
> > Interestingly the lookup fails at depth 0 (!). If a parent 
> certificate
> > were missing, I'd expect a lookup fail at depth 1.
> >
It's lookup of the issuer of the cert at 0 that failed. Because 
the lookup failed (after being attempted by mistake), to OpenSSL 
there is NO cert at depth 1 in this chain, only a "hole".

> > When I create a self-signed certificate:
> >
> > $ openssl req -new -x509 -nodes -out foobar.crt
> >
> > And check it then: [OK]

By default req -new -x509 does no extensions. Use a config 
file and x509_extensions or -extensions section that includes 
KeyUsage as above and you can recreate the problem.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl-users] Weird not-so-self-signed certificate

[Erwann Abalea]

Bonjour,

The given certificate is correctly self-signed, you can manually check 
it by extracting the signature block and playing with "openssl rsautl 
...", "dd ... | openssl dgst -sha1", etc.


It fails the validation path check probably because it's not declared as 
a CA. There's some ongoing work on IETF about DANE certificates and 
clarifications on RFC5280 about self-signed EE certificates. The 
presented certificate is certainly such a DANE one.


--
Erwann ABALEA
-
pastacircopyge: quelqu'un qui a vraiment beaucoup de chance

Le 06/08/2012 13:04, Johannes Bauer a écrit :

Hi list,

I'm quite puzzled and hope somebody can help me. I'm handling a large
number of certificates and for generating testcases for the software I
employ, I wrote a small script that downloaded web server certificates
en bulk and then processed them, to check for irregularities.

My software barfed on a certain certificate, which is this one:

-BEGIN CERTIFICATE-
MIIC8TCCAdmgAwIBAgIQNmL4pIUXFpRBUK7QhJR/JjANBgkqhkiG9w0BAQUFADAg
MR4wHAYDVQQDExVXTVN2Yy1XSU4tRUVCSExDODFHSjgwHhcNMTAxMjIzMjAzOTU0
WhcNMjAxMjIwMjAzOTU0WjAgMR4wHAYDVQQDExVXTVN2Yy1XSU4tRUVCSExDODFH
SjgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD6CNzdS+lWquEQndmY
R1XY6cEqeMSB6YVSxXFAARRsdLQceCIpZbD5CijYklx874gOokTwSzZ7EJ6QSPUL
jItM5PRlkeh0twrVEU5UTeqybAnVEciL5oVy6EPm4niYweAJrf5QCtPcORtt2Kjs
xYAX2Ltl7mjvi+QM+XwDX0LKWyIjpYTZXB/5XRnpzUuBw3pDx+z4fWk8SFqN4Ptb
/7fZSoxI6VeuTvrgS4aMyjsPylPnpXVAFYOcxketS0D1F9m0z5t3eD3hXesgbCHS
svy0gACF3qvarJiE6MVDaJ/tlX408G9V3gEHpCCrk+yL5FiT/dtr7tNlWMt+o9D4
5/kNAgMBAAGjJzAlMBMGA1UdJQQMMAoGCCsGAQUFBwMBMA4GA1UdDwQHAwUAsAAA
ADANBgkqhkiG9w0BAQUFAAOCAQEAYvuUspk2lHiP3IM4maY2DOH0UfSsldyqOICP
ue3xmqNnkhN7QBe8GIcsKt3fiozC7L+zcxdIY6L7WgGx1+aK8f3AKl/FojPegMhC
WsgNy5WsR+jLUduclZDGf4qXxo9Vs1qXeP4qYZOa1rtqiBfFaQsxs4+XyFHdaB8N
HzviKd8NSeCn+ZfUTKYlErUAL+qtLaQQTqVvBVnwR9yT74izZ48f0mX8zHYMFJIk
mokioFqzl2ZVF98JBLSy6sNTZfO+eg98g3uDVRwq9JyvsWp1OJ94BvoXFZX7ETDM
Z53Hp5s3YUNRptlIvzre/foKg4MZB8BNUsEUdgaGOeoXho7jDA==
-END CERTIFICATE-

It's seemingly self-signed, but then again -- not. When I call openssl:

$ openssl verify -CApath /dev/null -CAfile weird.crt weird.crt
weird.crt: /CN=WMSvc-WIN-EEBHLC81GJ8
error 20 at 0 depth lookup:unable to get local issuer certificate

Interestingly the lookup fails at depth 0 (!). If a parent certificate
were missing, I'd expect a lookup fail at depth 1.

When I create a self-signed certificate:

$ openssl req -new -x509 -nodes -out foobar.crt

And check it then:

$ openssl verify -CApath /dev/null -CAfile foobar.crt foobar.crt
foobar.crt: OK

I'm puzzled and before jumping to conclusions wanted to ask you first
what you think of that.

Best regards,
Johannes
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Weird not-so-self-signed certificate

[Johannes Bauer]

Hi list,

I'm quite puzzled and hope somebody can help me. I'm handling a large
number of certificates and for generating testcases for the software I
employ, I wrote a small script that downloaded web server certificates
en bulk and then processed them, to check for irregularities.

My software barfed on a certain certificate, which is this one:

-BEGIN CERTIFICATE-
MIIC8TCCAdmgAwIBAgIQNmL4pIUXFpRBUK7QhJR/JjANBgkqhkiG9w0BAQUFADAg
MR4wHAYDVQQDExVXTVN2Yy1XSU4tRUVCSExDODFHSjgwHhcNMTAxMjIzMjAzOTU0
WhcNMjAxMjIwMjAzOTU0WjAgMR4wHAYDVQQDExVXTVN2Yy1XSU4tRUVCSExDODFH
SjgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD6CNzdS+lWquEQndmY
R1XY6cEqeMSB6YVSxXFAARRsdLQceCIpZbD5CijYklx874gOokTwSzZ7EJ6QSPUL
jItM5PRlkeh0twrVEU5UTeqybAnVEciL5oVy6EPm4niYweAJrf5QCtPcORtt2Kjs
xYAX2Ltl7mjvi+QM+XwDX0LKWyIjpYTZXB/5XRnpzUuBw3pDx+z4fWk8SFqN4Ptb
/7fZSoxI6VeuTvrgS4aMyjsPylPnpXVAFYOcxketS0D1F9m0z5t3eD3hXesgbCHS
svy0gACF3qvarJiE6MVDaJ/tlX408G9V3gEHpCCrk+yL5FiT/dtr7tNlWMt+o9D4
5/kNAgMBAAGjJzAlMBMGA1UdJQQMMAoGCCsGAQUFBwMBMA4GA1UdDwQHAwUAsAAA
ADANBgkqhkiG9w0BAQUFAAOCAQEAYvuUspk2lHiP3IM4maY2DOH0UfSsldyqOICP
ue3xmqNnkhN7QBe8GIcsKt3fiozC7L+zcxdIY6L7WgGx1+aK8f3AKl/FojPegMhC
WsgNy5WsR+jLUduclZDGf4qXxo9Vs1qXeP4qYZOa1rtqiBfFaQsxs4+XyFHdaB8N
HzviKd8NSeCn+ZfUTKYlErUAL+qtLaQQTqVvBVnwR9yT74izZ48f0mX8zHYMFJIk
mokioFqzl2ZVF98JBLSy6sNTZfO+eg98g3uDVRwq9JyvsWp1OJ94BvoXFZX7ETDM
Z53Hp5s3YUNRptlIvzre/foKg4MZB8BNUsEUdgaGOeoXho7jDA==
-END CERTIFICATE-

It's seemingly self-signed, but then again -- not. When I call openssl:

$ openssl verify -CApath /dev/null -CAfile weird.crt weird.crt
weird.crt: /CN=WMSvc-WIN-EEBHLC81GJ8
error 20 at 0 depth lookup:unable to get local issuer certificate

Interestingly the lookup fails at depth 0 (!). If a parent certificate
were missing, I'd expect a lookup fail at depth 1.

When I create a self-signed certificate:

$ openssl req -new -x509 -nodes -out foobar.crt

And check it then:

$ openssl verify -CApath /dev/null -CAfile foobar.crt foobar.crt
foobar.crt: OK

I'm puzzled and before jumping to conclusions wanted to ask you first
what you think of that.

Best regards,
Johannes
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: TLS server/client with self-signed certificate

[Dave Thompson]

> From: owner-openssl-us...@openssl.org On Behalf Of Harald Latzko
> Sent: Friday, 03 August, 2012 03:02

> Am 03.08.2012 um 03:55 schrieb Dave Thompson:

> Yes, the hash link (.0) exists and after the first 
> connect failed, I double-checked the linked openSSL version 
> against the commandline tool version. 

Good. 

(original problem in app was)
> >> certificate verify error 20: unable to get local issuer 
> certificate: 
> >> A connect via "openssl s_client" also fails with  verify error 21>
> > 
> > You show only the last part (resulting SSL-Session).
> > I got as the first thing (except DN trimmed for posting):
> > CONNECTED(0003)
> > depth=0 emailAddress = deiningermichae...@johndeere.com, ... 
> > verify error:num=20:unable to get local issuer certificate
> > verify return:1
> > depth=0 emailAddress = deiningermichae...@johndeere.com, ...
> > verify error:num=21:unable to verify the first certificate
> > verify return:1
> > 
> > Note that you get error=20 first, and only after s_client overrides 
> > (which your app presumably doesn't) then you get error=21.

> You're right, my apps doesn't override error 20 
> (X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY) because it's 
> seen critically as a security hole if it would allow the 
> client connect to an unknown communication partner. It this 
> is not an usual security practice, please let me know (my app 
> is designed to be "as-secure-as-possible").
> 
Yes, to be safe your app should treat this as an error.
I was pointing out s_client first gets the *same* error (20), 
and later gets a different error (21) only because it overrides, 
because s_client was designed mostly as a manual test&debug tool.
I.e. the error is 20 not 21. I put the cert in a file 
and did commandline verify, and that also says error 20.
So I debugged that, and it sort of isn't 20; see below.

> > Error=20 means it didn't find the cert in the truststore. 
> > As above, check it is in the directory with the correct hash.
> See above: it's the case actually.
> > 
> > Errors in cert attributes (like BC) give other error codes.
> Are there any more errors? I can't see any. Another point to 

There are lots of other errors possible from X509_verify_cert.
See X509_V_ERR_* in x509_vfy.h. 

> be examined could be if the self-signed certificate isn't 
> really self-signed, but signd with a key whose certificate's 
> subject is just equally the same value, but whose private key 
> is a different that the one used for generating the 
> self-signed certificate itself (say: if there's a mistake in 
> self-signing, and something evil happened during the creation 
> of the self-signed certificate, another instance signed the 
> certificate which uses the same subject). Possible?
> 
If a supposedly selfsigned cert wasn't actually signed by its 
own key, yes that would be bad. But this specific cert is okay:
sha1 of the TBS portion (SEQUENCE starting at 4) 
is fa1e7834c1abf2d21cd453810ca0af941e861595 and 
rsautl -verify of the signature starting at 776 
using the pubkey in the body is 
 - 30 21 30 09 06 05 2b 0e-03 02 1a 05 00 04 14 fa   0!0...+.
0010 - 1e 78 34 c1 ab f2 d2 1c-d4 53 81 0c a0 af 94 1e   .x4..S..
0020 - 86 15 95  ...
which matches. (It's SEQUENCE of AlgId plus OCTETSTRING hash.)

> >> Is my assumption correct that the "CA"-flag must be set to "true" 
> >> in order to work as a self-signed server certificate? I don't want 
> >> to change my verify_callback function just in order to get it work 
> >> (which could be easy). Conformity should be the first goal.
> > No. CA:true, and (usually) KeyUsage:certSign, are required 
> > IF a cert (often, but not necessarily, selfsigned) is used 
> > to issue *other* (child) certs. 

I was only half-right. OpenSSL X509_check_issued is called to 
check *both* self-issued and parent-issued, and (always) requires 
that KeyUsage contain certSign or be absent. But this cert 
has KeyUsage without certSign. _check_issued actually returns 
a specific error code 32 _NO_CERTSIGN, but that gets swallowed 
by the chain-build logic and returns as 20 UNABLE*GET*LOCAL

> My assumption of a chain of trust is that the end of a trust 
> chain is reached (=a server or client certificate is seen as 
> valid and secure) if the whole chain of certificates ends in 
> an entifiy where subject=issuer and CA:true (and 
> mathematically verification of the signed certificate is 
> true). In the past, this was a perfectly explainable 
> environment for all issues about certificate chains and 
> trust. How is then trus

Re: TLS server/client with self-signed certificate

[Harald Latzko]

Hello Jakob,

Am 03.08.2012 um 09:52 schrieb Jakob Bohm:

>> My assumption of a chain of trust is that the end of a trust chain is 
>> reached (=a server or client certificate is seen as valid and secure) if the 
>> whole chain of certificates ends in an entifiy where subject=issuer and 
>> CA:true (and mathematically verification of the signed certificate is true). 
>> In the past, this was a perfectly explainable environment for all issues 
>> about certificate chains and trust. How is then trust handled (if the above 
>> mentioned method for linking trust via subject hash is used) for self-signed 
>> certificate in general?
>> This rule is no longer entirely true.
> 
> The new rule is to stop when reaching a cert in your local trusted
> or banned list, self-signed or otherwise, and to not check if the
> self-signature (if any) is valid.
Thank you for your information update, this is a very useful information for me.
May I ask if my understanding of your words are correct: if a self-signed 
certificate is being found in the certificate chain (which is normally the case 
instantly), the validation stops as seen in the technical tests with the given 
error? Is there a programmable way to allow single self-signed certificates 
(like using the trust mechanism) without "opening" security for *all* 
self-signed certificates (so the administrator of the system may import one 
special, but decline to use others)?

Regards,
Harald__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: TLS server/client with self-signed certificate

[Jakob Bohm]

On 8/3/2012 9:02 AM, Harald Latzko wrote:

Hello Dave,

Am 03.08.2012 um 03:55 schrieb Dave Thompson:

> Aside: it's a good thing you gave the server, because Outlook
> (which we use) blocks *.cer. I wish it didn't, but it does.
I've reached this "great" functionality last week, too. There's a 
possibility to allow filename extensions ins outlook, so you might add 
"cer" (or was it ".cer"?) as allowed extension by adding a registry 
key named "Level1Remove"  (type string) to
   HKEY_CURRENT_USER/Software/Microsoft/Office here>/Outlook/Security (Outlook 2002)


It's a comma-seperated list of allowed attachements which will be 
allowed to be displayed and downloaded in Outlook.


>> The server certificate is trusted in a directory where trusted
> certificates
>> reside. In my application, a connect try ends with the following error:
> Is the server cert in the directory named by tls_root_certpath
> *with a hashlink (or hashname)*? For the correct major version
> of OpenSSL? (hashes for 1.0.0+ are different from 0.9.8)
Yes, the hash link (.0) exists and after the first connect 
failed, I double-checked the linked openSSL version against the 
commandline tool version. I also added an unneeded link named the old 
hashing method (parameter "-subject_hash_old" for openssl commandline 
tool). Since I've got a bunch of working connection via various CAs, I 
assume this mechanism works normally.


>> certificate verify error 20: unable to get local issuer 
certificate: 
>> My opinion is that the self-signed certificate has the X509v3 basic 
constraint

>> CA flag set to "false": 
>
>> A connect via "openssl s_client" also fails with error 21>

>
> You show only the last part (resulting SSL-Session).
> I got as the first thing (except DN trimmed for posting):
> CONNECTED(0003)
> depth=0 emailAddress = deiningermichae...@johndeere.com, ...
> verify error:num=20:unable to get local issuer certificate
> verify return:1
> depth=0 emailAddress = deiningermichae...@johndeere.com, ...
> verify error:num=21:unable to verify the first certificate
> verify return:1
>
> Note that you get error=20 first, and only after s_client overrides
> (which your app presumably doesn't) then you get error=21.
You're right, my apps doesn't override error 20 
(X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY) because it's seen 
critically as a security hole if it would allow the client connect to 
an unknown communication partner. It this is not an usual security 
practice, please let me know (my app is designed to be 
"as-secure-as-possible").


> Error=20 means it didn't find the cert in the truststore.
> As above, check it is in the directory with the correct hash.
See above: it's the case actually.
>
> Errors in cert attributes (like BC) give other error codes.
Are there any more errors? I can't see any. Another point to be 
examined could be if the self-signed certificate isn't really 
self-signed, but signd with a key whose certificate's subject is just 
equally the same value, but whose private key is a different that the 
one used for generating the self-signed certificate itself (say: if 
there's a mistake in self-signing, and something evil happened during 
the creation of the self-signed certificate, another instance signed 
the certificate which uses the same subject). Possible?


>> Is my assumption correct that the "CA"-flag must be set to "true"
>> in order to work as a self-signed server certificate? I don't want
>> to change my verify_callback function just in order to get it work
>> (which could be easy). Conformity should be the first goal.
> No. CA:true, and (usually) KeyUsage:certSign, are required
> IF a cert (often, but not necessarily, selfsigned) is used
> to issue *other* (child) certs.
My assumption of a chain of trust is that the end of a trust chain is 
reached (=a server or client certificate is seen as valid and secure) 
if the whole chain of certificates ends in an entifiy where 
subject=issuer and CA:true (and mathematically verification of the 
signed certificate is true). In the past, this was a perfectly 
explainable environment for all issues about certificate chains and 
trust. How is then trust handled (if the above mentioned method for 
linking trust via subject hash is used) for self-signed certificate in 
general?



This rule is no longer entirely true.

The new rule is to stop when reaching a cert in your local trusted
or banned list, self-signed or otherwise, and to not check if the
self-signature (if any) is valid.

This is because of the following real world issues:

1. Some CAs are available both as self-signed and as cross-signed
by another CA (which you may or may

Re: TLS server/client with self-signed certificate

[Harald Latzko]

Hello Dave,

Am 03.08.2012 um 03:55 schrieb Dave Thompson:

> Aside: it's a good thing you gave the server, because Outlook 
> (which we use) blocks *.cer. I wish it didn't, but it does.
I've reached this "great" functionality last week, too. There's a possibility 
to allow filename extensions ins outlook, so you might add "cer" (or was it 
".cer"?) as allowed extension by adding a registry key named "Level1Remove"  
(type string) to 
  HKEY_CURRENT_USER/Software/Microsoft/Office /Outlook/Security (Outlook 2002)

It's a comma-seperated list of allowed attachements which will be allowed to be 
displayed and downloaded in Outlook.

>> The server certificate is trusted in a directory where trusted
> certificates 
>> reside. In my application, a connect try ends with the following error:
> Is the server cert in the directory named by tls_root_certpath 
> *with a hashlink (or hashname)*? For the correct major version 
> of OpenSSL? (hashes for 1.0.0+ are different from 0.9.8)
Yes, the hash link (.0) exists and after the first connect failed, I 
double-checked the linked openSSL version against the commandline tool version. 
I also added an unneeded link named the old hashing method (parameter 
"-subject_hash_old" for openssl commandline tool). Since I've got a bunch of 
working connection via various CAs, I assume this mechanism works normally.

>> certificate verify error 20: unable to get local issuer certificate: 
>> My opinion is that the self-signed certificate has the X509v3 basic 
>> constraint 
>> CA flag set to "false": 
> 
>> A connect via "openssl s_client" also fails with 
> 
> You show only the last part (resulting SSL-Session).
> I got as the first thing (except DN trimmed for posting):
> CONNECTED(0003)
> depth=0 emailAddress = deiningermichae...@johndeere.com, ... 
> verify error:num=20:unable to get local issuer certificate
> verify return:1
> depth=0 emailAddress = deiningermichae...@johndeere.com, ...
> verify error:num=21:unable to verify the first certificate
> verify return:1
> 
> Note that you get error=20 first, and only after s_client overrides 
> (which your app presumably doesn't) then you get error=21.
You're right, my apps doesn't override error 20 
(X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY) because it's seen critically as 
a security hole if it would allow the client connect to an unknown 
communication partner. It this is not an usual security practice, please let me 
know (my app is designed to be "as-secure-as-possible").

> Error=20 means it didn't find the cert in the truststore. 
> As above, check it is in the directory with the correct hash.
See above: it's the case actually.
> 
> Errors in cert attributes (like BC) give other error codes.
Are there any more errors? I can't see any. Another point to be examined could 
be if the self-signed certificate isn't really self-signed, but signd with a 
key whose certificate's subject is just equally the same value, but whose 
private key is a different that the one used for generating the self-signed 
certificate itself (say: if there's a mistake in self-signing, and something 
evil happened during the creation of the self-signed certificate, another 
instance signed the certificate which uses the same subject). Possible?

>> Is my assumption correct that the "CA"-flag must be set to "true" 
>> in order to work as a self-signed server certificate? I don't want 
>> to change my verify_callback function just in order to get it work 
>> (which could be easy). Conformity should be the first goal.
> No. CA:true, and (usually) KeyUsage:certSign, are required 
> IF a cert (often, but not necessarily, selfsigned) is used 
> to issue *other* (child) certs. 
My assumption of a chain of trust is that the end of a trust chain is reached 
(=a server or client certificate is seen as valid and secure) if the whole 
chain of certificates ends in an entifiy where subject=issuer and CA:true (and 
mathematically verification of the signed certificate is true). In the past, 
this was a perfectly explainable environment for all issues about certificate 
chains and trust. How is then trust handled (if the above mentioned method for 
linking trust via subject hash is used) for self-signed certificate in general?

Greetings,
Harald__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: TLS server/client with self-signed certificate

[Dave Thompson]

>From: owner-openssl-us...@openssl.org On Behalf Of Harald Latzko
>Sent: Thursday, 02 August, 2012 03:03

> self-signed certificate as attached to this mail (can be retrieved 
>from the TLS server 87.236.105.37:6619). My TLS client uses the 
>following options:
>SSL_CTX_load_verify_locations(ctx, NULL, tls_root_certpath)


Aside: it's a good thing you gave the server, because Outlook 
(which we use) blocks *.cer. I wish it didn't, but it does.

> The server certificate is trusted in a directory where trusted
certificates 
>reside. In my application, a connect try ends with the following error:

Is the server cert in the directory named by tls_root_certpath 
*with a hashlink (or hashname)*? For the correct major version 
of OpenSSL? (hashes for 1.0.0+ are different from 0.9.8)

>certificate verify error 20: unable to get local issuer certificate: 

>My opinion is that the self-signed certificate has the X509v3 basic
constraint 
>CA flag set to "false": 

>A connect via "openssl s_client" also fails with 

You show only the last part (resulting SSL-Session).
I got as the first thing (except DN trimmed for posting):
CONNECTED(0003)
depth=0 emailAddress = deiningermichae...@johndeere.com, ... 
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 emailAddress = deiningermichae...@johndeere.com, ...
verify error:num=21:unable to verify the first certificate
verify return:1

Note that you get error=20 first, and only after s_client overrides 
(which your app presumably doesn't) then you get error=21.

Error=20 means it didn't find the cert in the truststore. 
As above, check it is in the directory with the correct hash.

Errors in cert attributes (like BC) give other error codes.

>Is my assumption correct that the "CA"-flag must be set to "true" 
>in order to work as a self-signed server certificate? I don't want 
>to change my verify_callback function just in order to get it work 
>(which could be easy). Conformity should be the first goal.

No. CA:true, and (usually) KeyUsage:certSign, are required 
IF a cert (often, but not necessarily, selfsigned) is used 
to issue *other* (child) certs. 

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

TLS server/client with self-signed certificate

[Harald Latzko]

Hell,I've got a question regarding self-signed X509v3 certificates used in a TLS1.0 server/client environment. A communication partner uses a self-signed certificate as attached to this mail (can be retrieved from the TLS server 87.236.105.37:6619). My TLS client uses the following options:	SSL_CTX_load_verify_locations(ctx, NULL, tls_root_certpath)    SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT,  verify_callback);    SSL_CTX_set_verify_depth(ctx, 9);    SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_SINGLE_DH_USE | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_TICKET );The server certificate is trusted in a directory where trusted certificates reside. In my application, a connect try ends with the following error:certificate verify error 20: unable to get local issuer certificate: depth=0, subject: /emailAddress=deiningermichae...@johndeere.com/CN=jd_edi_gw.deere.com/OU=EDI/O=John Deere/L=Mannheim/ST=BW/C=DE, issuer: /emailAddress=deiningermichae...@johndeere.com/CN=jd_edi_gw.deere.com/OU=EDI/O=John Deere/L=Mannheim/ST=BW/C=DEMy opinion is that the self-signed certificate has the X509v3 basic constraint CA flag set to "false": (openssl x509 -in John_Deere_OFTP2_Prod_3.cer -noout -text)            X509v3 Basic Constraints: critical                CA:FALSEA connect via "openssl s_client" also fails with this message:openssl s_client -connect 87.236.105.37:6619 -tls1 -msg -debug -verify 9 -CApath /tmp/rootcerts/SSL-Session:    Protocol  : TLSv1    Cipher    : DHE-RSA-AES256-SHA    Session-ID: 501A2574C23B04543CC2CEAE6B930BB34B9A7A7A752213E32469399F77690FC8    Session-ID-ctx:     Master-Key: 72CE5564EC8B591BE7E7B9156610379E73177615F26FCDEE0B58D81AB3C301DED5B0B4AF7881489E9E4D4D654554B72C    Key-Arg   : None    Start Time: 1343890805    Timeout   : 7200 (sec)    Verify return code: 21 (unable to verify the first certificate)---Is my assumption correct that the "CA"-flag must be set to "true" in order to work as a self-signed server certificate? I don't want to change my verify_callback function just in order to get it work (which could be easy). Conformity should be the first goal.Regards,Harald

John_Deere_OFTP2_Prod_3.cer
Description: application/x509-ca-cert

RE: OpenSSL and apache2 wildcard self-signed certificate for nested subdomain

[Dave Thompson]

>   From: owner-openssl-us...@openssl.org On Behalf Of rey sebastien
>   Sent: Wednesday, 14 December, 2011 07:33

>   I have some problem with nested subdomain and wildcard openssl 
> certificate.. 
>   When i create the self signed certificate, i enter CN = 
> *.parisgeo.cnrs.fr, but it's seems it's impossible to connect on this site

> for example partage.parisgeo.cnrs.fr with this configuration ! Arg.

When you say "the" self-signed cert, which do you mean? For the 
procedure you show, only your (private) CA cert is selfsigned, 
the server=EE cert is NOT selfsigned. (It is signed by a key 
belonging to the same owner=you, but not *its own key*.)


>   I generate my certificate like this (CN = *.parisgeo.cnrs.fr) : 

>   openssl genrsa -des3 -out ca.key 2048
>   openssl req -new -x509 -days 3650 -key ca.key -out ca.crt
>   openssl req -newkey rsa:1024 -nodes -keyout parisgeo.cnrs.fr.key 
> -out parisgeo.cnrs.fr.csr
>   openssl x509 -req -days 3650 -in parisgeo.cnrs.fr.csr -CA ca.crt 
> -CAcreateserial  -CAkey ca.key -out parisgeo.cnrs.fr.crt


If you used the same DN, including CN=*.parisgeo.cnrs.fr, for both 
the CA and the server=EE, it won't work, and it looks like you did.

>   When i try to connect and test the certificate with openssl : 

>   root@:/etc/ssl# openssl s_client -connect
partage.parisgeo.cnrs.fr:443 
>   CONNECTED(0003)
>   depth=0 /C=FR/ST=IDF/L=PARIS/O=CNRS/CN=*.parisgeo.cnrs.fr
>   verify error:num=18:self signed certificate
>   verify return:1
>   depth=0 /C=FR/ST=IDF/L=PARIS/O=CNRS/CN=*.parisgeo.cnrs.fr
>   verify return:1
>   ---
>   Certificate chain
>0 s:/C=FR/ST=IDF/L=PARIS/O=CNRS/CN=*.parisgeo.cnrs.fr
>  i:/C=FR/ST=IDF/L=PARIS/O=CNRS/CN=*.parisgeo.cnrs.fr
>   ---


s_client thinks the issuer and subject names are identical.
If you want the server=EE cert signed/issued under a CA cert,
the server=EE name (subject) and the CA name (issuer) must be 
different. I prefer to make CN different, because that's what 
people mostly look at, but it's sufficient to make any field 
in DN different e.g. Org or OrgUnit.

>   The firefox error when i try to connect to the site is :

>   An error occurred during a connection to partage.parisgeo.cnrs.fr.
>   Peer's certificate has an invalid signature.
>   (Error code: sec_error_bad_signature)

OpenSSL signs correctly; assuming the certs weren't damaged, 
this probably means Firefox tried to verify using the EE key 
rather than the CA key because the name is ambiguous.

>   If you have any idea to help me resolving this problem .. 

Don't use the same name for the CA and the server.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL and apache2 wildcard self-signed certificate for nested subdomain

[Peter Sylvester]

On 12/14/2011 01:33 PM, rey sebastien wrote:


Hello users :)

I have some problem with nested subdomain and wildcard openssl certificate.. perhaps this is 
because the subdomain type is : site1.parisgeo.cnrs.fr, or site2.parisgeo.cnrs.fr, or other 
subdomain like .parisgeo.cnrs.fr


When i create the self signed certificate, i enter CN = *.parisgeo.cnrs.fr, but it's seems it's 
impossible to connect on this site for example partage.parisgeo.cnrs.fr with this configuration ! Arg.



your connexion works fine up to the point of certificate verification.

openssl s_client does not like self signed certs
any browser needs user action to disable warnings.

example  curl -k https://www.parisgeo.cnrs.fr  works because of -k

OpenSSL and apache2 wildcard self-signed certificate for nested subdomain

[rey sebastien]

Hello users :)

I have some problem with nested subdomain and wildcard openssl 
certificate.. perhaps this is because the subdomain type is : 
site1.parisgeo.cnrs.fr, or site2.parisgeo.cnrs.fr, or other subdomain 
like .parisgeo.cnrs.fr


When i create the self signed certificate, i enter CN = 
*.parisgeo.cnrs.fr, but it's seems it's impossible to connect on this 
site for example partage.parisgeo.cnrs.fr with this configuration ! Arg.


My virtualhost and my apache2 conf *work* with no wildcard cerficate, so 
the problem is not here i think :


The port.conf

|  NameVirtualHost *:443
 Listen 443
|

An example virtualhost i have :

|
  ServerName partage.parisgeo.cnrs.fr
  ServerAlias www.partage.parisgeo.cnrs.Fr

  DocumentRoot /var/www/owncloud


Options -Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
Allow from all


   SSLEngine on

   SSLCertificateFile/etc/ssl/parisgeo.cnrs.fr.crt
   SSLCertificateKeyFile /etc/ssl/parisgeo.cnrs.fr.key
   
|

I generate my certificate like this (CN = *.parisgeo.cnrs.fr) :

|openssl genrsa -des3 -out ca.key 2048
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt
openssl req -newkey rsa:1024 -nodes -keyout parisgeo.cnrs.fr.key -out 
parisgeo.cnrs.fr.csr

openssl x509 -req -days 3650 -in parisgeo.cnrs.fr.csr -CA ca.crt 
-CAcreateserial  -CAkey ca.key -out parisgeo.cnrs.fr.crt
|

The right for my generate key file :

|-rw-r--r-- 1 root root  1424 14 déc.  11:51 ca.crt
-rw-r--r-- 1 root root  1743 14 déc.  11:50 ca.key
-rw-r--r-- 1 root root17 14 déc.  12:13 ca.srl
-rw-r--r-- 1 root root   981 14 déc.  12:13 parisgeo.cnrs.fr.crt
-rw-r--r-- 1 root root   627 14 déc.  12:08 parisgeo.cnrs.fr.csr
-rw-r--r-- 1 root root   891 14 déc.  12:08 parisgeo.cnrs.fr.key
|

When i try to connect and test the certificate with openssl :

|root@:/etc/ssl# openssl s_client -connect partage.parisgeo.cnrs.fr:443
CONNECTED(0003)
depth=0 /C=FR/ST=IDF/L=PARIS/O=CNRS/CN=*.parisgeo.cnrs.fr
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=FR/ST=IDF/L=PARIS/O=CNRS/CN=*.parisgeo.cnrs.fr
verify return:1
---
Certificate chain
 0 s:/C=FR/ST=IDF/L=PARIS/O=CNRS/CN=*.parisgeo.cnrs.fr
   i:/C=FR/ST=IDF/L=PARIS/O=CNRS/CN=*.parisgeo.cnrs.fr
---
Server certificate
-BEGIN CERTIFICATE-
. blabla .
-BEGIN CERTIFICATE-
subject=/C=FR/ST=IDF/L=PARIS/O=CNRS/CN=*.parisgeo.cnrs.fr
issuer=/C=FR/ST=IDF/L=PARIS/O=CNRS/CN=*.parisgeo.cnrs.fr
---
No client certificate CA names sent
---
SSL handshake has read 1253 bytes and written 319 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1
Cipher: DHE-RSA-AES256-SHA
Session-ID: 7642C70A1E358CAA5901C060A26655DE3AF0BA683C9A598BA7C4B14FF108ADD7
Session-ID-ctx:
Master-Key: 65184165198498498484 6516511321584831181468469431688132138498
Key-Arg   : None
Start Time: 1323862629
Timeout   : 300 (sec)
Verify return code: 18 (self signed certificate)
---
closed
|

The firefox error when i try to connect to the site is :

|An error occurred during a connection to partage.parisgeo.cnrs.fr.
Peer's certificate has an invalid signature.
(Error code: sec_error_bad_signature)
|

If you have any idea to help me resolving this problem ..
Thanks a lot ! SR.

RE: Help neede Generating a V3 self-signed certificate from a CSR

[Dave Thompson]

>   From: owner-openssl-us...@openssl.org On Behalf Of Benoit Rouleau
>   Sent: Friday, 11 November, 2011 12:19

>   I have a problem. I am attempting to generate a self-signed 
> (for internal use) certificate with multiple SAN and all I can get 
> is a V1 certificate with no SAN at all. 
>   OpenSSL genrsa -out test.key 2048
>   OpenSSL req -new -key test.key -config test.cfg -out test.csr
>   OpenSSL x509 -req -days 3650 -signkey test.key -in test.csr -out
test.crt

x509 -req doesn't copy 'requested' extensions from the CSR 
to the cert. Options:

- don't put SAN in the req, use x509 -req -extensions [-extfile] 
to add it to the cert.

- don't bother with x509, use req -new -x509 -extensions [-config]
to create the selfsigned cert directly with (Subject &) SAN

- don't use selfsigned, put SAN in the req, use ca with 
copy_extensions=copy in its config file


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Help neede Generating a V3 self-signed certificate from a CSR

[Benoit Rouleau]

Hello there,

 

I have a problem. I am attempting to generate a self-signed (for internal
use) certificate with multiple SAN and all I can get is a V1 certificate
with no SAN at all. Any help would be greatly appreciated.

 

Here is the detail of my attempt:

 

# Generate a 2048 RSA key

OpenSSL genrsa -out test.key 2048

 

# Generate the certificate signature request

OpenSSL req -new -key test.key -config test.cfg -out test.csr

 

# Generate the self signed certificate

OpenSSL x509 -req -days 3650 -signkey test.key -in test.csr -out test.crt

 

Included are all the file created (Key, csr and crt).

 

Here is an output of the csr:

Certificate Request:

Data:

Version: 0 (0x0)

Subject: C=CA, ST=Ontario, L=Ottawa, O=Test, CN=Test.com

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

Public-Key: (2048 bit)

Modulus:

00:b0:4f:ec:f3:71:b6:d2:69:f9:4a:f4:8c:70:2c:

7e:62:91:74:9d:f7:ba:e0:d2:f4:5c:d7:99:2b:3d:

fe:4a:39:dd:58:5f:9d:f9:50:3e:a5:3e:55:ff:1b:

ef:9b:09:85:1e:a4:d2:bf:77:0e:b7:d6:86:fd:ef:

0a:c1:0d:d7:55:9c:94:79:f2:20:a2:f3:22:4a:f8:

01:20:43:14:f6:20:d7:52:43:ae:fd:27:a7:fa:b7:

45:03:cc:5a:19:50:32:ae:28:22:2a:94:f8:46:30:

33:76:4e:dd:23:06:d2:fc:a7:3b:4b:c7:11:57:fd:

85:bd:03:85:fa:fb:70:9a:e0:a2:61:d8:af:a6:14:

db:7e:3c:6b:ff:14:1f:a0:43:aa:1a:38:34:e9:08:

dc:cc:1f:4a:07:0b:68:83:f1:6c:3d:9d:d7:d3:c6:

d6:20:77:b7:aa:3a:fa:09:b5:61:f2:ae:f8:d5:b8:

88:76:97:6a:75:c6:0f:b1:c1:00:a5:90:d4:a8:11:

f8:6c:20:05:16:70:b1:48:dd:d2:27:39:21:e3:13:

a5:35:56:65:8b:8e:e6:6a:f2:21:4d:60:3c:28:1f:

8f:ff:f8:66:37:c9:f7:a6:dd:0a:e5:e1:bf:87:3a:

56:79:4e:fd:2e:c6:39:15:da:04:51:5f:e7:0a:3b:

1a:15

Exponent: 65537 (0x10001)

Attributes:

Requested Extensions:

X509v3 Subject Alternative Name:

DNS:test1.com, DNS:test2.com, DNS:test3.com, DNS:test4.com

Signature Algorithm: sha1WithRSAEncryption

25:26:42:e0:a2:36:33:b1:6e:fd:1c:a0:96:2b:b3:a9:b8:8d:

3f:c9:5e:4a:a8:49:c4:d6:3b:eb:79:e2:37:12:fe:18:4c:92:

2f:08:16:3c:31:a3:e6:37:82:b6:bd:21:81:99:57:f2:77:9b:

fe:78:f4:93:3e:fc:ce:fe:31:79:e0:0a:96:6e:f9:32:a6:68:

cf:a1:c6:b4:39:37:93:57:d8:93:1f:2e:8e:f1:3a:90:fd:b6:

b6:72:5d:bb:41:81:15:24:20:ed:7a:12:77:f7:0e:8b:18:11:

ce:e6:9b:e2:25:b0:52:a4:37:50:7f:6a:7a:37:71:e0:c5:05:

ca:45:76:54:54:72:58:6e:5b:94:0b:63:89:c6:89:a2:ee:58:

91:f8:e4:2a:25:89:52:4b:f0:32:d1:e8:5c:5b:d4:4b:3f:3b:

6d:55:81:b0:de:9c:9a:41:f3:15:e0:7f:21:ce:f4:3b:69:fd:

76:10:9f:19:86:03:a1:fc:bb:0b:13:0f:f1:48:15:12:3b:8d:

06:27:ff:51:c4:f5:b3:cd:21:08:24:70:06:87:ad:f8:9f:28:

53:84:a0:c8:6b:eb:21:b7:40:de:9f:15:10:c7:ea:0f:3b:5e:

d0:f1:e4:3b:af:c3:af:64:6c:c7:60:c4:62:d6:32:86:ce:26:

a1:26:b0:38

 

Thanks,

 

 

Benoit Rouleau

Senior Web/Software Developer

 

 

 

Re: OpenSSL FIPS module self signed certificate creation failed

[rockrider33]

Hello Dr.
Thanks for the solution. It worked out.

For others I am giving the steps:
1)create FIPS Object module.
2)download http://www.openssl.org/source/openssl-0.9.8r.tar.gz
3)untar and run following commands in order to build and install
   a)./config fips --with-fipslibdir=
   b)make
   c)make install
4) done. I tried to create certificate with the fips capable Openssl

Thanks
Prab(rock)


Dr. Stephen Henson wrote:
> 
> On Thu, Aug 25, 2011, rockrider33 wrote:
> 
>> 
>> Hi All,
>> 
>> I am new to linux and openssl stuff. 
>> 
>> I have tried to install OpenSSL (1.2.3 with fips)with FIPS module and
>> it's
>> successful. (built and installed)
>> 
>> For building:
>> i had used make and gcc version 4.3.4
>> 
>> I hope installation was successful and it created FIPS module and openssl
>> binary (usr/local/ssl/fips1-0/bin)
>> Note: my machine already installed with openssl 0.9.8h. I didnt uninstall
>> it.
>> 
>> what i tried is, 
>> 1.executed /usr/local/ssl/fips1-0/bin/openssl this binary and created
>> self
>> signed certificate "key" -successful
>> 2.Using same command, trying to create certificate signing request and it
>> failed with "Invalid instruction"
>> 3.I saw system logs, it had an entry
>> Aug 23 05:11:36 lglor248 kernel: [14103.238431] openssl[15942] trap
>> invalid
>> opcode ip:7fcb3cc886d0 sp:7fff7a02c9a8 error:0 in
>> libcrypto.so.0.9.8[7fcb3cb9+16a000]
>> 
>> I had some googling on this and found a relevant link:
>> http://forum.doom9.org/archive/index.php/t-125808.html
>> 
>> But i don't feel my gcc version would be causing this issue since that
>> post
>> was quite old and i have almost latest gcc.
>> 
>> It will be appreciated if any one helps me out on this..
>> 
>> NOTE: i used the openssl command which i created and never used existing
>> installation (old 0.9.8h).
>> 
> 
> The usual cause of this is if you attempt to use the version of OpenSSL
> that
> comes with the validated module: don't do that as it is old and newer
> versions
> of gcc do horrible things when you try to use it.
> 
> Instead use the validated tarball to build the module and then use the
> latest version of OpenSSL to link against the module, a so called "FIPS
> capable OpenSSL". Details in the user guide.
> 
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> __________
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager   majord...@openssl.org
> 
> 

-- 
View this message in context: 
http://old.nabble.com/OpenSSL-FIPS-module-self-signed-certificate-creation-failed-tp32333668p32354713.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: OpenSSL FIPS module self signed certificate creation failed

[Dr. Stephen Henson]

On Thu, Aug 25, 2011, rockrider33 wrote:

> 
> Hi All,
> 
> I am new to linux and openssl stuff. 
> 
> I have tried to install OpenSSL (1.2.3 with fips)with FIPS module and it's
> successful. (built and installed)
> 
> For building:
> i had used make and gcc version 4.3.4
> 
> I hope installation was successful and it created FIPS module and openssl
> binary (usr/local/ssl/fips1-0/bin)
> Note: my machine already installed with openssl 0.9.8h. I didnt uninstall
> it.
> 
> what i tried is, 
> 1.executed /usr/local/ssl/fips1-0/bin/openssl this binary and created self
> signed certificate "key" -successful
> 2.Using same command, trying to create certificate signing request and it
> failed with "Invalid instruction"
> 3.I saw system logs, it had an entry
> Aug 23 05:11:36 lglor248 kernel: [14103.238431] openssl[15942] trap invalid
> opcode ip:7fcb3cc886d0 sp:7fff7a02c9a8 error:0 in
> libcrypto.so.0.9.8[7fcb3cb9+16a000]
> 
> I had some googling on this and found a relevant link:
> http://forum.doom9.org/archive/index.php/t-125808.html
> 
> But i don't feel my gcc version would be causing this issue since that post
> was quite old and i have almost latest gcc.
> 
> It will be appreciated if any one helps me out on this..
> 
> NOTE: i used the openssl command which i created and never used existing
> installation (old 0.9.8h).
> 

The usual cause of this is if you attempt to use the version of OpenSSL that
comes with the validated module: don't do that as it is old and newer versions
of gcc do horrible things when you try to use it.

Instead use the validated tarball to build the module and then use the
latest version of OpenSSL to link against the module, a so called "FIPS
capable OpenSSL". Details in the user guide.

--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

OpenSSL FIPS module self signed certificate creation failed

[rockrider33]

Hi All,

I am new to linux and openssl stuff. 

I have tried to install OpenSSL (1.2.3 with fips)with FIPS module and it's
successful. (built and installed)

For building:
i had used make and gcc version 4.3.4

I hope installation was successful and it created FIPS module and openssl
binary (usr/local/ssl/fips1-0/bin)
Note: my machine already installed with openssl 0.9.8h. I didnt uninstall
it.

what i tried is, 
1.executed /usr/local/ssl/fips1-0/bin/openssl this binary and created self
signed certificate "key" -successful
2.Using same command, trying to create certificate signing request and it
failed with "Invalid instruction"
3.I saw system logs, it had an entry
Aug 23 05:11:36 lglor248 kernel: [14103.238431] openssl[15942] trap invalid
opcode ip:7fcb3cc886d0 sp:7fff7a02c9a8 error:0 in
libcrypto.so.0.9.8[7fcb3cb9+16a000]

I had some googling on this and found a relevant link:
http://forum.doom9.org/archive/index.php/t-125808.html

But i don't feel my gcc version would be causing this issue since that post
was quite old and i have almost latest gcc.

It will be appreciated if any one helps me out on this..

NOTE: i used the openssl command which i created and never used existing
installation (old 0.9.8h).

Thanks in advance
rock! 

-- 
View this message in context: 
http://old.nabble.com/OpenSSL-FIPS-module-self-signed-certificate-creation-failed-tp32333668p32333668.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Verifying self-signed certificate

[iruvopenssl]

On Tue, 30 Nov 2010 01:36:16 +0200 "Dr. Stephen Henson" 
 wrote:
>On Tue, Nov 30, 2010, iruvopen...@hushmail.com wrote:
>
>> On Mon, 29 Nov 2010 20:05:43 +0200 "Dr. Stephen Henson" 
>>  wrote:
>> Greetings!
>> 
>> I'm doing nothing funky:
>> $ openssl genrsa -des3 -out ca.key 4096
>> $ openssl req -new -x509 -days 365 -key ca.key -out ca.crt
>> $ openssl genrsa -des3 -out server.key 4096
>> $ openssl req -new -key server.key -out server.csr
>> $ openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -
>> set_serial 01 -out server.crt
>> 
>> Giving to every option (company name, etc.) the default value:
>> So for example, my server.crt's issuer line is:
>> Issuer: C=AU, ST=Some-State, O=Internet Widgits Pty Ltd
>> and my ca.crt's subject line is:
>> Subject: C=AU, ST=Some-State, O=Internet Widgits Pty Ltd
>> 
>
>Well that's one problem, if your certificates have the same issuer 
>and subject
>names then you'll end up with what looks like a self-signed 
>certificate. Try
>giving the server certificate different values from the CA.
>
>If there were any extensions in the server certificate that 
>wouldn't happen
>but the command you create the server certificate with doesn't 
>include any and
>ends up creating the deprecated V1 certificate format.
>
>Steve.
>--
>Dr Stephen N. Henson. OpenSSL project core developer.
>Commercial tech support now available see: http://www.openssl.org
>___
>___
>OpenSSL Project 
>http://www.openssl.org
>User Support Mailing Listopenssl-
>us...@openssl.org
>Automated List Manager   
>majord...@openssl.org

Heh, I didn't think of this :)

Thank you very much, it's now working!

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Verifying self-signed certificate

[aerowolf]

On Mon, Nov 29, 2010 at 3:36 PM, Dr. Stephen Henson  wrote:


If there were any extensions in the server certificate that wouldn't happen
but the command you create the server certificate with doesn't include any and
ends up creating the deprecated V1 certificate format.


Should this behavior be changed to create a V3 certificate with no extensions 
by default?  There isn't much call for the creation of V1 certs, and as this 
case shows the default behavior creates counterintuitive behavior.

-Kyle H

smime.p7s
Description: S/MIME Cryptographic Signature

Re: Verifying self-signed certificate

[Dr. Stephen Henson]

On Tue, Nov 30, 2010, iruvopen...@hushmail.com wrote:

> On Mon, 29 Nov 2010 20:05:43 +0200 "Dr. Stephen Henson" 
>  wrote:
> Greetings!
> 
> I'm doing nothing funky:
> $ openssl genrsa -des3 -out ca.key 4096
> $ openssl req -new -x509 -days 365 -key ca.key -out ca.crt
> $ openssl genrsa -des3 -out server.key 4096
> $ openssl req -new -key server.key -out server.csr
> $ openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -
> set_serial 01 -out server.crt
> 
> Giving to every option (company name, etc.) the default value:
> So for example, my server.crt's issuer line is:
> Issuer: C=AU, ST=Some-State, O=Internet Widgits Pty Ltd
> and my ca.crt's subject line is:
> Subject: C=AU, ST=Some-State, O=Internet Widgits Pty Ltd
> 

Well that's one problem, if your certificates have the same issuer and subject
names then you'll end up with what looks like a self-signed certificate. Try
giving the server certificate different values from the CA.

If there were any extensions in the server certificate that wouldn't happen
but the command you create the server certificate with doesn't include any and
ends up creating the deprecated V1 certificate format.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Verifying self-signed certificate

[iruvopenssl]

On Mon, 29 Nov 2010 20:05:43 +0200 "Dr. Stephen Henson" 
 wrote:
>On Mon, Nov 29, 2010, iruvopen...@hushmail.com wrote:
>
>> Greetings,
>> 
>> I guess this question must have been asked quite a lot over 
>here, 
>> but I couldn't find any traces of it
>> so I guess I'll repeat it.
>> 
>> I can't seem to be able to verify (using 'openssl verify') - 
>> without openssl spitting a 
>X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT - 
>> a server certificate that was signed with a custom-made CA even 
>> though I pass the CA certificate using the -CAfile switch. 
>> I've tried -purpose and also using -CApath instead of -CAfile 
>but 
>> to no avail.
>> 
>> Is this a feature, a bug or am I just doing it wrong?
>> 
>
>Impossible to tell without seeing the actual certificate and the 
>precise
>command line you use.
>
>Steve.
>--
>Dr Stephen N. Henson. OpenSSL project core developer.
>Commercial tech support now available see: http://www.openssl.org
>___
>___
>OpenSSL Project 
>http://www.openssl.org
>User Support Mailing Listopenssl-
>us...@openssl.org
>Automated List Manager   
>majord...@openssl.org

Greetings!

I'm doing nothing funky:
$ openssl genrsa -des3 -out ca.key 4096
$ openssl req -new -x509 -days 365 -key ca.key -out ca.crt
$ openssl genrsa -des3 -out server.key 4096
$ openssl req -new -key server.key -out server.csr
$ openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -
set_serial 01 -out server.crt

Giving to every option (company name, etc.) the default value:
So for example, my server.crt's issuer line is:
Issuer: C=AU, ST=Some-State, O=Internet Widgits Pty Ltd
and my ca.crt's subject line is:
Subject: C=AU, ST=Some-State, O=Internet Widgits Pty Ltd

I'm trying to verify them with something like that:
"
$ openssl verify -CAfile ca.crt server.crt 
server.crt: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
error 18 at 0 depth lookup:self signed certificate
OK
"
but like I said in my original post I've tried the -purpose
-CApath etc. switches as well.

Can you reproduce this?

Thank you very much for the reply!

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Verifying self-signed certificate

[Dr. Stephen Henson]

On Mon, Nov 29, 2010, iruvopen...@hushmail.com wrote:

> Greetings,
> 
> I guess this question must have been asked quite a lot over here, 
> but I couldn't find any traces of it
> so I guess I'll repeat it.
> 
> I can't seem to be able to verify (using 'openssl verify') - 
> without openssl spitting a X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT - 
> a server certificate that was signed with a custom-made CA even 
> though I pass the CA certificate using the -CAfile switch. 
> I've tried -purpose and also using -CApath instead of -CAfile but 
> to no avail.
> 
> Is this a feature, a bug or am I just doing it wrong?
> 

Impossible to tell without seeing the actual certificate and the precise
command line you use.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Verifying self-signed certificate

[iruvopenssl]

Greetings,

I guess this question must have been asked quite a lot over here, 
but I couldn't find any traces of it
so I guess I'll repeat it.

I can't seem to be able to verify (using 'openssl verify') - 
without openssl spitting a X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT - 
a server certificate that was signed with a custom-made CA even 
though I pass the CA certificate using the -CAfile switch. 
I've tried -purpose and also using -CApath instead of -CAfile but 
to no avail.

Is this a feature, a bug or am I just doing it wrong?

Shouldn't a self-signed certificate get verified when a user 
_manually_ also passes a certificate he considers trusted?

Also, is there any documentation on how SSL_CTX_set_cert_store() be 
used? It seems to me that it's the correct way to validate
a self-signed certificate through the OpenSSL API.

Many thanks!
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Verifying self-signed certificate

[iruvopenssl]

Greetings,

I guess this question must have been asked quite a lot over here, 
but I couldn't find any traces of it
so I guess I'll repeat it.

I can't seem to be able to verify (using 'openssl verify') - 
without openssl spitting a X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT - 
a server certificate that was signed with a custom-made CA even 
though I pass the CA certificate using the -CAfile switch. 
I've tried -purpose and also using -CApath instead of -CAfile but 
to no avail.

Is this a feature, a bug or am I just doing it wrong?

Shouldn't a self-signed certificate get verified when a user 
_manually_ also passes a certificate he considers trusted?

Also, is there any documentation on how SSL_CTX_set_cert_store() be 
used? It seems to me that it's the correct way to validate
a self-signed certificate through the OpenSSL API.

Many thanks!

PS: Sorry, if this reaches the mailing list multiple times, I 
screwed up a bit :)

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

creation of self-signed certificate fail

[klerfe [Bodegas]]

 Hi,

this is how i've been creating self signed certificates in the past for 
TLS in smtpd:


openssl req -days 3650 -nodes -new -x509 -keyout /etc/ssl/private/ca.key \
-out /etc/ssl/ca.crt

openssl req -days 3650 -nodes -new -keyout 
/etc/postfix/ssl/private/server.key \

-out /etc/postfix/ssl/private/server.csr

openssl x509 -req -days 3650 -in /etc/postfix/ssl/private/server.csr \
-out /etc/postfix/ssl/server.crt -CA /etc/ssl/ca.crt \
-CAkey /etc/ssl/private/ca.key -CAcreateserial


Now it doesn't work. Mail client says "bad signature", maillog says:

postfix/smtpd[1366]: warning: TLS library problem: 
1366:error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad 
certificate:/usr/src/lib/libssl/src/ssl/s3_pkt.c:1062:SSL a

lert number 42:

openssl verify -CAfile /etc/ssl/ca.crt /etc/postfix/ssl/server.crt says:

/etc/postfix/ssl/server.crt: 
/C=**/ST=*/L=*/O=*/OU=*/CN=***.***.**

error 18 at 0 depth lookup:self signed certificate
/C=**/ST=*/L=*/O=*/OU=*/CN=***.***.**
error 7 at 0 depth lookup:certificate signature failure
8629:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block 
type is not 01:/usr/src/lib/libssl/src/crypto/rsa/rsa_pk1.c:100:
8629:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check 
failed:/usr/src/lib/libssl/src/crypto/rsa/rsa_eay.c:719:
8629:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP 
lib:/usr/src/lib/libssl/src/crypto/asn1/a_verify.c:173:


This way of creating self signed certificates worked for me in the past, 
i've never had this kind of problem before. I found this problem 
recently, when i had to remake certificates because of common name (host 
name) change. Same problem in openbsd 4.7 and freebsd 8.1. Even more: 
just few days back i've upgraded freebsd from 8.0 to 8.1, then i've 
successfully created those certificates in the way described above. 
Everything went fine, except for misstyped Country Name in certificate. 
I've deleted all the files i just created, then made the new ones, but 
those were already corrupted. That is creating self signed certificates 
in this way works only very first time for me, after os upgrade or fresh 
install. All further attempts are failing. Anyone has a clue..?


Thanks in advance,

Paulie
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Problem with self-signed certificate on HP JetDirect Card...

[Andy Barnett]

Hi Folks,

This is my first "post" and I'm still "wet behind the ears" with this whole
certificate thing so please be gentle with me...

I'm trying to fix a security compliance issue on some of our networked
printers in the office, the problem seems to be due to the CN settings in
the default JetDirect certificate...

Having fixed other compliance using OpenSSL Certificates I thought I'd try
generating one for a printer - try being the operative word!

I've searched the archives and found the posts about JetDirect from 2003 but
can't get the solution to work for me!

Essentially, I did the following using one of the OpenSSL for Windows
compilations...

1. Generated a Private Key

openssl genrsa -des3 -out server.key 1024

2. Generated a CSR with the corrected CN through the JetDirect web interface

-BEGIN CERTIFICATE REQUEST-
MIIB2DCCAWoCAQIwgb0xHzAdBgNVBAMTFnRzcGNvbGFzZXIxLnRtYmMubG9jYWwx
EjAQBgNVBAcTCUtpbmdzaGlsbDENMAsGA1UECBMES2VudDELMAkGA1UEBhMCZ2Ix
LDAqBgNVBAoUI1RvbmJyaWRnZSAmIE1hbGxpbmcgQm9yb3VnaCBDb3VuY2lsMRUw
EwYDVQQLEwwwMDAxRTZBMjAxNjYxDzANBgNVBAsTBko2MDU3QTEUMBIGA1UECxML
SVQgU2VydmljZXMwczANBgkqhkiG9w0BAQEFAANiADBfAlgLgZKhfFA1BTSLqEgf
aUmavvzoQFcZ65jrpGvpTjfPbuEmaGsZ+87EifdkhtZnsqg5AyC2P6xDP3X4pdyT
7HgxFH/T58UBE5+w6pATyYWTLLK7H1/TppytAgMBAAGgMDAuBgkqhkiG9w0BCQ4x
ITAfMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w0BAQQF
AANZAAhGpCaTH7PjUFRq8+ECP/faAv5AFUD+n2SxS6pDlWhRSuFhJZVQzbcl0CNB
I8MV+wZdKmSd63rLy8Od9tsTVgkcm9VWZRzYk9CtxgEyPWLwn88t5qGlnzI=
-END CERTIFICATE REQUEST-

3. Removed the Passphrase from the key

copy server.key server.key.ori
openssl rsa -in server.key.ori -out server.key 

4. Added the following to my openssl.cfg file in the [usr_cert] section as
recommended in the 2003 posts

extendedKeyUsage = clientAuth, serverAuth

5. Generated my certificate

openssl x509 -req -days 3652 -in printer.csr -signkey server.key
-out printer.crt -extfile openssl.cfg -extensions usr_cert

Everything seems OK, "openssl x509 -in printer.crt -text -purpose" looks
good including the [usr_cert] stuff, but when I paste the content of the
.crt file on the printer I get the following: - "The certificate entered was
invalid. Please try again and be sure to include the entire certificate
correctly."

Is there some kind soul out there who can enlighten me as to what I'm
missing?

TIA!

Andy B.


 

__ Information from ESET NOD32 Antivirus, version of virus signature
database 5076 (20100430) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

verify error:num=18:self signed certificate--how to make a self singed ,dynamicly generate certificate to be trusted

[sara bai]

hi all , I created a certificate dynamicly in this way  (python-twisted
)

dn = ssl.DistinguishedName(commonName="test dn")
dn.inspect() # add by myself
keypair = ssl.KeyPair.generate()
req = keypair.certificateRequest(dn)

def verify(dn):
return True

serialno = 1110

isuser= ssl.DistinguishedName(commonName="test dn")  # isuser  ->dni
 The certificate is not trusted because it is self-signed.
certData = keypair.signCertificateRequest(isuser, req, verify, serialno)
  #The certificate is only valid for 'test dn'


cert = keypair.newCertificate(certData)

contextFactory = cert.options()

reactor.listenSSL(, EchoFactory(), contextFactory)


- test it  :openssl s_client -ssl3 -connect 127.0.0.1:

got this error  :
"
4204:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
failure:s3_pkt.c:1053:SSL alert number 40
4204:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake
failure:s3_pkt.c:530:   "


and  then i use tls1 method the error is like this :
"
...TLS 1.0 Handshake [length 0010], Finished...
...
verify error:num=18:self signed certificate "



is there any way to make a dynamicly generate certificate to be trusted ?
need help  thanks

Self-signed certificate chain for website

[Serge Fonville]

Hi,

I'm kinda new to OpenSSL so please be gentle.

I am currently in the process of setting up a certificate chain for an intranet

I want something like Thawte has
Fonville IT Root CA
Fonville IT CA
www.sergefonville.nl

I have searched far and wide, but could not find a definitive guide.
I have a couple of questions now:
Do I need a separate key for every certificate
what commands should I use
What specific settings do I need in openssl.cnf

I am running Windows Vista x64
My directory structure is as follows

C:\ProgramData\OpenSSL\Fonville IT CA
C:\Program Files\OpenSSL
C:\Program Files\Apache
C:\ProgramData\htdocs-secure

I attached the openssl.cnf I created and the batch file I used to
create the certificate
I know there are a lot of bugs in there, so all the help is greatly appreciated.

When I succeed, I will post back everything I have discovered, so
anyone else with a similar problem can use it

I probably forgot some important points. so please do point them out

Thanks a lot in advance!!!

Regards,

Serge Fonville
@echo off
md "C:\ProgramData\OpenSSL\Fonville IT CA"
cd /d "C:\ProgramData\OpenSSL\Fonville IT CA"
md root
cd root
type NUL > index.txt
echo 01 > serial
md certs private newcerts crl requests
cd ..
md intermediate
cd intermediate
type NUL > index.txt
echo 01 > serial
md certs private newcerts crl requests
cd ..
md certificates
cd certificates
md certs
cd ..
openssl req -out root\certs\cacert.pem -nodes -new -newkey rsa:4096 -keyout 
root\private\cakey.pem -sha1 -config openssl.cnf -x509 -days 3650 -extensions 
v3_ca
openssl req -out root\requests\cacert.csr -nodes -newkey rsa:4096 -keyout 
intermediate\private\cakey.pem -config openssl.cnf
openssl ca -extensions v3_ca -days 3650 -out intermediate\certs\cacert.pem -in 
root\requests\cacert.csr -config openssl.cnf -name CA_root
openssl req -new -out intermediate\requests\sergefonville.nl.csr -nodes -key 
intermediate\private\cakey.pem -config openssl.cnf
openssl ca -extensions v3_ca -days 365 -out 
certifcates\certs\sergefonville.nl.pem -in 
intermediate\requests\sergefonville.nl.csr -key intermediate\private\cakey.pem 
-config openssl.cnf -name CA_intermediate
type NUL > chain.pem
type root\certs\cacert.pem > chain.pem
type intermediate\certs\cacert.pem >> chain.pem
type certificates\certs\sergefonville.nl.pem >> chain.pem

openssl.cnf
Description: Binary data

RE: Trouble generating a self signed certificate

[Will Bickford]

The error message means what it says: it can not find privkey.pem.  When
generating a new certificate request, you will need to sign the request
with your private key, which needs to be generated first.

http://www.google.com/search?q=generate+rsa+private+key+openssl

--Will

-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of andrew.luke
Sent: Thursday, June 04, 2009 8:11 AM
To: openssl-users@openssl.org
Subject: Trouble generating a self signed certificate


I've been trying to generate a self signed certificate to get SSL
working on a very simple internal web server.  I'm using a windows
server 2003 box so I got the open SSL windows binaries from
http://www.slproweb.com/products/Win32OpenSSL.html.  Using a HOWTO I
found here
http://www.sitepoint.com/article/securing-apache-2-server-ssl/  I used
the following command to try and generate a cert:

openssl req -new -key domainname.com.key -x509 -out sslname.crt

I got an error on that one so I tried a command the openssl.org
documentation had:

openssl req -new -key privkey.pem -out cert.csr

Again I got an error like this:
Error opening Private Key privkey.pem
3924:error:02001002:system library:fopen:No such file or
directory:.\crypto\bio\bss_file.c:356:fopen
3924:error:20074002:BIO routines:FILE_CTRL:system
lib:.\crypto\bio\bss_file.c:358:
unable to load Private Key

Any idea what the problem is?
--
View this message in context:
http://www.nabble.com/Trouble-generating-a-self-signed-certificate-tp238
69634p23869634.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Trouble generating a self signed certificate

[Dave Thompson]

> From: owner-openssl-us...@openssl.org On Behalf Of andrew.luke
> Sent: Thursday, 04 June, 2009 09:11

> I've been trying to generate a self signed certificate to get 
> SSL working on a very simple internal web server.  I'm using 
> a windows server 2003 box so I got the open SSL windows 
> binaries from 
> http://www.slproweb.com/products/Win32OpenSSL.html.  Using a 
> HOWTO I found here 
> http://www.sitepoint.com/article/securing-apache-2-server-ssl/
>   I used the following command to try and generate a cert:
> 
> openssl req -new -key domainname.com.key -x509 -out sslname.crt
> 
> I got an error on that one so I tried a command the 
> openssl.org documentation had:
> 
> openssl req -new -key privkey.pem -out cert.csr
> 
Note this second way won't generate a cert; it will generate a CSR 
(Certificate Signing Request) which you can then turn into a cert.
That's also a valid approach, but slightly more complicated.

The combination of -new -x509 generates a selfsigned cert;
-new without -x509 generates a CSR. (No -new at all allows 
you to display, or manipulate, an already existing CSR.)

> Again I got an error like this:
> Error opening Private Key privkey.pem
> 3924:error:02001002:system library:fopen:No such file or 
> directory:.\crypto\bio\bss_file.c:356:fopen
> 3924:error:20074002:BIO routines:FILE_CTRL:system
> lib:.\crypto\bio\bss_file.c:358:
> unable to load Private Key
> 
> Any idea what the problem is?

Yeah, the privatekey file doesn't exist, as it says.

req -new [-x509] generates CSR-or-cert FOR AN EXISTING KEY.

If you want the req command to generate the key itself,
you also need -newkey parms and -keyout file, or use a config 
containing default_bits (RSA only) and default_keyfile.

If you want to generate the key separately with openssl, 
first use genrsa, or gendsa and optionally dsaparam.

If you want to use a key imported from elsewhere, describe 
in detail, but you're usually better off creating the cert 
or at least CSR in that elsewhere instead of openssl.



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Trouble generating a self signed certificate

[andrew.luke]

I've been trying to generate a self signed certificate to get SSL working on
a very simple internal web server.  I'm using a windows server 2003 box so I
got the open SSL windows binaries from
http://www.slproweb.com/products/Win32OpenSSL.html.  Using a HOWTO I found
here http://www.sitepoint.com/article/securing-apache-2-server-ssl/  I used
the following command to try and generate a cert:

openssl req -new -key domainname.com.key -x509 -out sslname.crt

I got an error on that one so I tried a command the openssl.org
documentation had:

openssl req -new -key privkey.pem -out cert.csr

Again I got an error like this:
Error opening Private Key privkey.pem
3924:error:02001002:system library:fopen:No such file or
directory:.\crypto\bio\bss_file.c:356:fopen
3924:error:20074002:BIO routines:FILE_CTRL:system
lib:.\crypto\bio\bss_file.c:358:
unable to load Private Key

Any idea what the problem is?
-- 
View this message in context: 
http://www.nabble.com/Trouble-generating-a-self-signed-certificate-tp23869634p23869634.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: revoking a self-signed certificate

[David Schwartz]

Olaf Gellert:

> I would not say so. If I found a CRL which contains the
> self signed root certificate I would stop to trust it
> immediately.

Why? What do you think that CRL means? Specifically, do you think it means
the public key was compromised? Do you think it means the issuer of the
original certificate no longer wants you to trust it?

> Why should I not trust a CRL issued by a
> root CA that I trust?

You should trust a CRL when it revokes certificates that you trust
specifically because they're not on that CRL.

> Remember: The trust has to be
> established before, but when you already trust the CA,
> you can trust CRLs issued by it. Even if the root CAs
> key was compromised, I would not care if the CRL was
> issued by the attacker or the CA itself.

Right, but you have to know what the CRL means. In some alternate universe
where that means "no longer trust the public key that this certificate
signs" or "no longer trust the root certificate that's in this CRL", then
you might choose to stop trusting the trust anchor. But in this universe, it
doesn't mean any of those things.

> I agree that
> it makes sense to have higher level protocols that take
> care of root CA revocation and trust anchor management,
> but in my opinion not evaluating a CRL which revokes the
> root is missing a chance of good CA practise and taking
> an unnecessary risk...

The problem is that it doesn't mean anything. A certificate being in a CRL
does not mean the certificate's public key has been compromised. The
mechanism you are describing simply doesn't exist. Maybe it could exist,
maybe it should, but it doesn't.

DS


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: revoking a self-signed certificate

[Olaf Gellert]

Hi all,

David Schwartz wrote:
>> Can you please elaborate on how would the higher-layer security
>> infrastructure go about this?
> 
> Simply put, whatever put the certificate in its trusted position is what is
> to remove it. If a CA says to trust a certificate, that CA can say not to.
> But if the certificate is self-signed, the trust came from the user who said
> to trust it (or some other mechanims outside the scope of the certificate
> verification scheme). That same mechanism is the only thing that can say to
> stop trusting it.

I would not say so. If I found a CRL which contains the
self signed root certificate I would stop to trust it
immediately. Why should I not trust a CRL issued by a
root CA that I trust? Remember: The trust has to be
established before, but when you already trust the CA,
you can trust CRLs issued by it. Even if the root CAs
key was compromised, I would not care if the CRL was
issued by the attacker or the CA itself. I agree that
it makes sense to have higher level protocols that take
care of root CA revocation and trust anchor management,
but in my opinion not evaluating a CRL which revokes the
root is missing a chance of good CA practise and taking
an unnecessary risk...

Cheers, Olaf

-- 
Olaf Gellert_ - __o
gell...@arasca.de  _- _`<,_
http://www.arasca.de/  - (_)/ (_)
--
Due to circumstances beyond your control
you are master of your fate & captain of your soul.
--
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: revoking a self-signed certificate

[Kyle Hamilton]

There is currently no automated protocol for doing this.  There is
currently an effort at PKIX for a "Trust Anchor Management Protocol",
though, which would allow for tools to be made cross-platform.

Also, self-signed CAs are basically never checked for expiration.
(The 'trust anchor' is technically the public key, not the identity
information strongly bound to the public key in the certificate.)

-Kyle H

On Mon, Jan 26, 2009 at 9:28 PM, PS  wrote:
> Can you please elaborate on how would the higher-layer security
> infrastructure go about this?
> To me, it just seems impossible to do this and the issue might only be
> mitigated by spreading awareness by an out-of-band means but not eliminated
> until ofcourse, the self-signed CA certificate expires.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: revoking a self-signed certificate

[David Schwartz]

> Can you please elaborate on how would the higher-layer security
> infrastructure go about this?

Simply put, whatever put the certificate in its trusted position is what is
to remove it. If a CA says to trust a certificate, that CA can say not to.
But if the certificate is self-signed, the trust came from the user who said
to trust it (or some other mechanims outside the scope of the certificate
verification scheme). That same mechanism is the only thing that can say to
stop trusting it.

> To me, it just seems impossible to do this and the issue might only
> be mitigated by spreading awareness by an out-of-band means but not
eliminated
> until ofcourse, the self-signed CA certificate expires.

It's not impossible. Just use the same technique that installed the
self-signed certificate to uninstall it. If you could get it trusted
somehow, why can't you get it untrusted that same way?

DS


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: revoking a self-signed certificate

[PS]

Also, does openssl allow a CA to revoked its own self-signed certificate?
What happens when during the openssl verify, it finds that the CRL given by
CA contains the CA-certificate in the revoked list?

On Mon, Jan 26, 2009 at 9:28 PM, PS  wrote:

> Can you please elaborate on how would the higher-layer security
> infrastructure go about this?
> To me, it just seems impossible to do this and the issue might only be
> mitigated by spreading awareness by an out-of-band means but not eliminated
> until ofcourse, the self-signed CA certificate expires.
>
>
> On Mon, Jan 26, 2009 at 9:20 PM, Kyle Hamilton  wrote:
>
>> A self-signed CA certificate (technically, a "trust anchor") cannot be
>> revoked via CRL.  This is assumed to be a function of the higher-layer
>> security infrastructure which led to the trust anchor being trusted in
>> the first place, and is outside the scope of CRL.
>>
>> -Kyle H
>>
>> On Mon, Jan 26, 2009 at 9:17 PM, PS  wrote:
>> > Hi All,
>> > Is it possible to revoke a self-signed CA certificate?
>> >
>> > If yes, then I dont understand why it should be allowed. It does not
>> make
>> > sense. The only reason a root CA would want to revoke its own
>> certificate is
>> > if its private-key might have been compromised. So, the CA would want to
>> > revoke its certificate and create a new CRL.
>> > But since the private-key is compromised, the attacker can always use
>> the
>> > private-key (of the CA), and create a yet new CRL and distribute.
>> >
>> > This looks like a chicken and egg problem because you are trusting a
>> > CRL-list sent by a CA  and the CRL mentions not to trust the very same
>> CA
>> > since its  certificate is revoked. What is the solution to this problem?
>> Any
>> > insights?
>> >
>> __
>> OpenSSL Project http://www.openssl.org
>> User Support Mailing Listopenssl-users@openssl.org
>> Automated List Manager   majord...@openssl.org
>>
>
>

Re: revoking a self-signed certificate

[PS]

Can you please elaborate on how would the higher-layer security
infrastructure go about this?
To me, it just seems impossible to do this and the issue might only be
mitigated by spreading awareness by an out-of-band means but not eliminated
until ofcourse, the self-signed CA certificate expires.

On Mon, Jan 26, 2009 at 9:20 PM, Kyle Hamilton  wrote:

> A self-signed CA certificate (technically, a "trust anchor") cannot be
> revoked via CRL.  This is assumed to be a function of the higher-layer
> security infrastructure which led to the trust anchor being trusted in
> the first place, and is outside the scope of CRL.
>
> -Kyle H
>
> On Mon, Jan 26, 2009 at 9:17 PM, PS  wrote:
> > Hi All,
> > Is it possible to revoke a self-signed CA certificate?
> >
> > If yes, then I dont understand why it should be allowed. It does not make
> > sense. The only reason a root CA would want to revoke its own certificate
> is
> > if its private-key might have been compromised. So, the CA would want to
> > revoke its certificate and create a new CRL.
> > But since the private-key is compromised, the attacker can always use the
> > private-key (of the CA), and create a yet new CRL and distribute.
> >
> > This looks like a chicken and egg problem because you are trusting a
> > CRL-list sent by a CA  and the CRL mentions not to trust the very same CA
> > since its  certificate is revoked. What is the solution to this problem?
> Any
> > insights?
> >
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager   majord...@openssl.org
>

Re: revoking a self-signed certificate

[Kyle Hamilton]

A self-signed CA certificate (technically, a "trust anchor") cannot be
revoked via CRL.  This is assumed to be a function of the higher-layer
security infrastructure which led to the trust anchor being trusted in
the first place, and is outside the scope of CRL.

-Kyle H

On Mon, Jan 26, 2009 at 9:17 PM, PS  wrote:
> Hi All,
> Is it possible to revoke a self-signed CA certificate?
>
> If yes, then I dont understand why it should be allowed. It does not make
> sense. The only reason a root CA would want to revoke its own certificate is
> if its private-key might have been compromised. So, the CA would want to
> revoke its certificate and create a new CRL.
> But since the private-key is compromised, the attacker can always use the
> private-key (of the CA), and create a yet new CRL and distribute.
>
> This looks like a chicken and egg problem because you are trusting a
> CRL-list sent by a CA  and the CRL mentions not to trust the very same CA
> since its  certificate is revoked. What is the solution to this problem? Any
> insights?
>
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

revoking a self-signed certificate

[PS]

Hi All,
Is it possible to revoke a self-signed CA certificate?

If yes, then I dont understand why it should be allowed. It does not make
sense. The only reason a root CA would want to revoke its own certificate is
if its private-key might have been compromised. So, the CA would want to
revoke its certificate and create a new CRL.
But since the private-key is compromised, the attacker can always use the
private-key (of the CA), and create a yet new CRL and distribute.

This looks like a chicken and egg problem because you are trusting a
CRL-list sent by a CA  and the CRL mentions not to trust the very same CA
since its  certificate is revoked. What is the solution to this problem? Any
insights?

Re: Problem related to self signed certificate peer verification

[Tim Hudson]

[EMAIL PROTECTED] wrote:

Sir,

How do I check to see what version of Open SSL that I have on my 
system? I am trying to answer the attached vulnerability.


If you have the executable for the superapp then use:
  openssl version -a

If you don't then you can
  strings path-to-library | grep ' part of '
and look at the strings generated

e.g. for an old Ubuntu build

ldd /usr/bin/openssl
(to figure out the path to the library)

strings /usr/lib/i686/cmov/libssl.so.0.9.8  | grep ' part of '

SSLv2 part of OpenSSL 0.9.8c 05 Sep 2006
SSLv3 part of OpenSSL 0.9.8c 05 Sep 2006
TLSv1 part of OpenSSL 0.9.8c 05 Sep 2006
DTLSv1 part of OpenSSL 0.9.8c 05 Sep 2006

If you have code:

Look in crypto/opensslv.h (or whereever you place placed the include file during 
installation) and see OPENSSL_VERSION_NUMBER


grep OPENSSL_VERSION_ /usr/include/openssl/opensslv.h

Tim.


PGP.sig
Description: PGP signature

Problem related to self signed certificate peer verification

[Ajeet kumar.S]

Dear All,

I have self signed root certificate. I want to verify the peer certificate.
In API static   int check_issued(X509_STORE_CTX *ctx, X509 *x, X509
*issuer).

 I saw function calling X509_check_issued(issuer, x); where they are
matching   issuer and subject. But I saw server is sending the Thwate as
server CA (issuer and subject).But self sign certificate having server
name(service provider name and email) in subject and issuer.

So openssl always returning unknown CA due not matching of issuer and
subject.

So please help me how to debug this problem to verify the peer using our
self signed root certificate (which is provided by service provider).

 

 

Thank you.

Regards,

--Ajeet  Kumar  Singh

 

 

 

<>

Re: how trust self signed certificate

[Sergio]

matteo mattau escribió:

Dears,
I'm in trouble with self signed certificate, when I try to verify via 
ocsp a certificate whose issuer is self signed.

The error I receive is always
openssl ocsp -issuer /usr/local/ssl/cert/issuerPEM.crt -cert 
./certificatePEM.cer -url http://ocsp.foo.com -CApath /usr/local/ssl/cert

Response Verify Failure
1903:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify 
error:ocsp_vfy.c:122:Verify error:self signed certificate in 
certificate chain
 
Into /usr/local/ssl/cert I've copied the issuer certificate and 
created the "ln -s" hash link.
Is that anyway to trust the "self signed" certificate? If I load the 
issuer certificate into IE browser,

It appeares as root...
Thanks in advance
Mattew
 



I'm not an expert but openssl builds the certificate chain to verify it, 
it uses subject DN (i think) field to link the certificates. If you put 
a self-signed in the middle of the chain, it will be broken because 
openssl won't find the next certificate. If really your issuer has a 
self-signed certificate and there is another ca above with another 
self-signed certificate, my only idea would be to try with another ocsp 
options when you type the command but it sounds strange, because means 
that there is one certificate into the chain which shouldn't be verified 
and this contradicts PKI ideas.
In theory, the self-signed certificate must be with -CAfile option and 
the issuer, which is just an intermediate CA with a NOT self-signed 
certificate, with -issuer option. I've used ocsp command several times 
and -CApath was not necessary, also linking with "ln" command. Just 
cert, issuer, url and ca.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

how trust self signed certificate

[matteo mattau]

Dears,
I'm in trouble with self signed certificate, when I try to verify via ocsp a 
certificate whose issuer is self signed.
The error I receive is always 
openssl ocsp -issuer /usr/local/ssl/cert/issuerPEM.crt -cert 
./certificatePEM.cer -url http://ocsp.foo.com -CApath 
/usr/local/ssl/certResponse Verify Failure1903:error:27069065:OCSP 
routines:OCSP_basic_verify:certificate verify error:ocsp_vfy.c:122:Verify 
error:self signed certificate in certificate chain
 
Into /usr/local/ssl/cert I've copied the issuer certificate and created the "ln 
-s" hash link.
Is that anyway to trust the "self signed" certificate? If I load the issuer 
certificate into IE browser,
It appeares as root...
Thanks in advance
Mattew
 
_
Invite your mail contacts to join your friends list with Windows Live Spaces. 
It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us

Self-signed certificate created by SelfSSL.exe (IIS Resource Kit)

[Иосиф Виссарионович]

I used SelfSSL.exe utility to create self-signed certificate and installed it 
into IIS on my website.
My OpenSSL client fails when I try to connect to my website. I've got this 
error:

SSL_connect() failed: error:0001:lib(0):func(0):reason(1) 
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed

After that I created self-signed certificate using OpenSSL and installed it 
into IIS on my website. In that case my OpenSSL client work fine.

I compared two certificates (created by SelfSSL and OpenSSL). I found one 
important difference: SelfSSL's certificate's "Key Usage" extension has no 
"Certificate Signing" bit asserted. In other words SelfSSL generates 
self-signed certificate which cannot be used to sign certificates. But it's 
self-signed! It was used to sign certificate, but certificate signing is 
restricted for it.

So, there are two questions:

1. Is this (SelfSSL) certificate valid (for OpenSSL)?

2. Are there any workaround to use this certificate in my OpenSSL client?
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: ECC Self-Signed Certificate

[Larry Bugbee]

I have noticed this as well.  I believe it operates correctly in the
0.9.9 snapshot.


Indeed, the change log indicates a fix.  Thanks.  At the moment I'm  
unable to get a good build with the 3/10 SNAP.  ...a problem  
linking .dylib.



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: ECC Self-Signed Certificate

[Bill Colvin]

I have noticed this as well.  I believe it operates correctly in the
0.9.9 snapshot.



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Larry Bugbee
Sent: February 13, 2008 8:41 PM
To: openssl-users@openssl.org
Subject: Re: ECC Self-Signed Certificate


I've signed and consumed ECC certs just fine.  My only problem is that  
when I specify a hash algorithm like SHA-256, OpenSSL falls back to  
the default SHA-1 for self-signed certs only.



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: ECC Self-Signed Certificate

[Larry Bugbee]

I've signed and consumed ECC certs just fine.  My only problem is that  
when I specify a hash algorithm like SHA-256, OpenSSL falls back to  
the default SHA-1 for self-signed certs only.




On Feb 13, 2008, at 7:13 AM, Nabil Ghadiali wrote:

Ahh ok. That means that even if the signature is valid, it will show  
up like

that.

Thanks,

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Patrick  
Patterson

Sent: Wednesday, February 13, 2008 10:07 AM
To: openssl-users@openssl.org
Subject: Re: ECC Self-Signed Certificate

On Wednesday 13 February 2008 09:58:08 Nabil Ghadiali wrote:
I saved the base64 encoded text in a file with an extension ".cer"  
and

then
double-clicked it. Microsoft recognizes it is a certificate and  
opens it

up

in a certificate viewer.

Over here it says "The integrity of the certificate cannot be  
guaranteed.

The certificate may be corrupted or may have been altered"


Unless you are using Vista, Microsoft CAPI doesn't support ECC.

Have fun.

Patrick.


Thanks,

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Victor Duchovni
Sent: Wednesday, February 13, 2008 8:00 AM
To: openssl-users@openssl.org
Subject: Re: ECC Self-Signed Certificate

On Wed, Feb 13, 2008 at 12:40:18AM -0500, Nabil Ghadiali wrote:

Can someone help me with the command to generate a self-signed
certificate using openssl?



I have used the following steps and when I get a certificate and  
open up


it


says "the signature is invalid". Am I missing something?


What does "open it up" mean? The self-signed EC cert you posted looks
fine.

$ openssl verify -CAfile foo.pem -purpose crlsign foo.pem
foo.pem: OK

$ openssl x509 -text -in foo.pem
Certificate:
   Data:
   Version: 3 (0x2)
   Serial Number:
   d2:4e:d0:af:62:63:da:1b
   Signature Algorithm: ecdsa-with-SHA1
   Issuer: C=US, ST=Some-State, O=Internet Widgits Pty Ltd
   Validity
   Not Before: Feb 13 05:37:39 2008 GMT
   Not After : Feb 12 05:37:39 2009 GMT
   Subject: C=US, ST=Some-State, O=Internet Widgits Pty Ltd
   Subject Public Key Info:
   Public Key Algorithm: id-ecPublicKey
   Public-Key: (256 bit)
   pub:
   04:f3:26:32:97:d1:db:f9:e6:18:40:53:95:f7:67:
   f7:ab:52:25:96:aa:58:d2:8e:dc:6d:d3:a5:e5:5d:
   11:95:e7:73:f9:b3:24:df:5e:4f:b1:5e:55:49:66:
   3e:a4:39:3c:c5:a4:74:f0:a3:62:35:94:23:aa:e5:
   db:83:67:07:35
   ASN1 OID: prime256v1
   X509v3 extensions:
   X509v3 Subject Key Identifier:


E6:9B:18:14:7F:52:88:EB:C5:86:BE:B3:68:9E:BE:39:F3:A6:2B:E2

   X509v3 Authority Key Identifier:

keyid:E6:9B:18:14:7F:52:88:EB:C5:86:BE:B3:68:9E:BE:39:F3:A6:2B:E2
   DirName:/C=US/ST=Some-State/O=Internet Widgits Pty Ltd
   serial:D2:4E:D0:AF:62:63:DA:1B

   X509v3 Basic Constraints:
   CA:TRUE
   Signature Algorithm: ecdsa-with-SHA1
   30:45:02:21:00:a7:58:a0:52:62:be:42:dd:53:83:6d:4c:c4:
   4f:dd:96:24:56:f5:f8:6b:76:ec:3f:cf:fa:0b:41:8c:6c:4b:
   85:02:20:24:00:ae:a7:fb:1b:37:cf:77:f6:3e:2e:47:22:ed:
   ba:21:0b:79:32:31:3a:07:2b:2f:32:0e:81:4f:8c:eb:b0
-BEGIN CERTIFICATE-
MIICJzCCAc6gAwIBAgIJANJO0K9iY9obMAkGByqGSM49BAEwRTELMAkGA1UEBhMC
VVMxEzARBgNVBAgTClNvbWUtU3RhdGUxITAfBgNVBAoTGEludGVybmV0IFdpZGdp
dHMgUHR5IEx0ZDAeFw0wODAyMTMwNTM3MzlaFw0wOTAyMTIwNTM3MzlaMEUxCzAJ
BgNVBAYTAlVTMRMwEQYDVQQIEwpTb21lLVN0YXRlMSEwHwYDVQQKExhJbnRlcm5l
dCBXaWRnaXRzIFB0eSBMdGQwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATzJjKX
0dv55hhAU5X3Z/erUiWWqljSjtxt06XlXRGV53P5syTfXk+xXlVJZj6kOTzFpHTw
o2I1lCOq5duDZwc1o4GnMIGkMB0GA1UdDgQWBBTmmxgUf1KI68WGvrNonr4586Yr
4jB1BgNVHSMEbjBsgBTmmxgUf1KI68WGvrNonr4586Yr4qFJpEcwRTELMAkGA1UE
BhMCVVMxEzARBgNVBAgTClNvbWUtU3RhdGUxITAfBgNVBAoTGEludGVybmV0IFdp
ZGdpdHMgUHR5IEx0ZIIJANJO0K9iY9obMAwGA1UdEwQFMAMBAf8wCQYHKoZIzj0E
AQNIADBFAiEAp1igUmK+Qt1Tg21MxE/dliRW9fhrduw/z/oLQYxsS4UCICQArqf7
GzfPd/Y+Lkci7bohC3kyMToHKy8yDoFPjOuw
-END CERTIFICATE-




--
Patrick Patterson
President and Chief PKI Architect,
Carillon Information Security Inc.
http://www.carillon.ca
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]



__
OpenSSL Project http://www.openssl.org
User Sup

RE: ECC Self-Signed Certificate

[Nabil Ghadiali]

Ahh ok. That means that even if the signature is valid, it will show up like
that.

Thanks,

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Patrick Patterson
Sent: Wednesday, February 13, 2008 10:07 AM
To: openssl-users@openssl.org
Subject: Re: ECC Self-Signed Certificate

On Wednesday 13 February 2008 09:58:08 Nabil Ghadiali wrote:
> I saved the base64 encoded text in a file with an extension ".cer" and
then
> double-clicked it. Microsoft recognizes it is a certificate and opens it
up
> in a certificate viewer.
>
> Over here it says "The integrity of the certificate cannot be guaranteed.
> The certificate may be corrupted or may have been altered"
>
Unless you are using Vista, Microsoft CAPI doesn't support ECC.

Have fun.

Patrick.

> Thanks,
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Victor Duchovni
> Sent: Wednesday, February 13, 2008 8:00 AM
> To: openssl-users@openssl.org
> Subject: Re: ECC Self-Signed Certificate
>
> On Wed, Feb 13, 2008 at 12:40:18AM -0500, Nabil Ghadiali wrote:
> > Can someone help me with the command to generate a self-signed
> > certificate using openssl?
> >
> >
> >
> > I have used the following steps and when I get a certificate and open up
>
> it
>
> > says "the signature is invalid". Am I missing something?
>
> What does "open it up" mean? The self-signed EC cert you posted looks
> fine.
>
> $ openssl verify -CAfile foo.pem -purpose crlsign foo.pem
> foo.pem: OK
>
> $ openssl x509 -text -in foo.pem
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number:
> d2:4e:d0:af:62:63:da:1b
> Signature Algorithm: ecdsa-with-SHA1
> Issuer: C=US, ST=Some-State, O=Internet Widgits Pty Ltd
> Validity
> Not Before: Feb 13 05:37:39 2008 GMT
> Not After : Feb 12 05:37:39 2009 GMT
> Subject: C=US, ST=Some-State, O=Internet Widgits Pty Ltd
> Subject Public Key Info:
> Public Key Algorithm: id-ecPublicKey
> Public-Key: (256 bit)
> pub:
> 04:f3:26:32:97:d1:db:f9:e6:18:40:53:95:f7:67:
> f7:ab:52:25:96:aa:58:d2:8e:dc:6d:d3:a5:e5:5d:
> 11:95:e7:73:f9:b3:24:df:5e:4f:b1:5e:55:49:66:
> 3e:a4:39:3c:c5:a4:74:f0:a3:62:35:94:23:aa:e5:
> db:83:67:07:35
> ASN1 OID: prime256v1
> X509v3 extensions:
> X509v3 Subject Key Identifier:
>
E6:9B:18:14:7F:52:88:EB:C5:86:BE:B3:68:9E:BE:39:F3:A6:2B:E2
> X509v3 Authority Key Identifier:
>
> keyid:E6:9B:18:14:7F:52:88:EB:C5:86:BE:B3:68:9E:BE:39:F3:A6:2B:E2
> DirName:/C=US/ST=Some-State/O=Internet Widgits Pty Ltd
> serial:D2:4E:D0:AF:62:63:DA:1B
>
> X509v3 Basic Constraints:
> CA:TRUE
> Signature Algorithm: ecdsa-with-SHA1
> 30:45:02:21:00:a7:58:a0:52:62:be:42:dd:53:83:6d:4c:c4:
> 4f:dd:96:24:56:f5:f8:6b:76:ec:3f:cf:fa:0b:41:8c:6c:4b:
> 85:02:20:24:00:ae:a7:fb:1b:37:cf:77:f6:3e:2e:47:22:ed:
> ba:21:0b:79:32:31:3a:07:2b:2f:32:0e:81:4f:8c:eb:b0
> -BEGIN CERTIFICATE-
> MIICJzCCAc6gAwIBAgIJANJO0K9iY9obMAkGByqGSM49BAEwRTELMAkGA1UEBhMC
> VVMxEzARBgNVBAgTClNvbWUtU3RhdGUxITAfBgNVBAoTGEludGVybmV0IFdpZGdp
> dHMgUHR5IEx0ZDAeFw0wODAyMTMwNTM3MzlaFw0wOTAyMTIwNTM3MzlaMEUxCzAJ
> BgNVBAYTAlVTMRMwEQYDVQQIEwpTb21lLVN0YXRlMSEwHwYDVQQKExhJbnRlcm5l
> dCBXaWRnaXRzIFB0eSBMdGQwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATzJjKX
> 0dv55hhAU5X3Z/erUiWWqljSjtxt06XlXRGV53P5syTfXk+xXlVJZj6kOTzFpHTw
> o2I1lCOq5duDZwc1o4GnMIGkMB0GA1UdDgQWBBTmmxgUf1KI68WGvrNonr4586Yr
> 4jB1BgNVHSMEbjBsgBTmmxgUf1KI68WGvrNonr4586Yr4qFJpEcwRTELMAkGA1UE
> BhMCVVMxEzARBgNVBAgTClNvbWUtU3RhdGUxITAfBgNVBAoTGEludGVybmV0IFdp
> ZGdpdHMgUHR5IEx0ZIIJANJO0K9iY9obMAwGA1UdEwQFMAMBAf8wCQYHKoZIzj0E
> AQNIADBFAiEAp1igUmK+Qt1Tg21MxE/dliRW9fhrduw/z/oLQYxsS4UCICQArqf7
> GzfPd/Y+Lkci7bohC3kyMToHKy8yDoFPjOuw
> -END CERTIFICATE-



-- 
Patrick Patterson
President and Chief PKI Architect,
Carillon Information Security Inc.
http://www.carillon.ca
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: ECC Self-Signed Certificate

[Bill Colvin]

Can you be more specific about what your problem is?  The cert appears
to be a self-signed cert.

 

The command "openssl x509 -in test.pem -noout -text" generates:

 

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

d2:4e:d0:af:62:63:da:1b

Signature Algorithm: ecdsa-with-SHA1

Issuer: C=US, ST=Some-State, O=Internet Widgits Pty Ltd

Validity

Not Before: Feb 13 05:37:39 2008 GMT

Not After : Feb 12 05:37:39 2009 GMT

Subject: C=US, ST=Some-State, O=Internet Widgits Pty Ltd

Subject Public Key Info:

Public Key Algorithm: id-ecPublicKey

EC Public Key:

pub:

04:f3:26:32:97:d1:db:f9:e6:18:40:53:95:f7:67:

f7:ab:52:25:96:aa:58:d2:8e:dc:6d:d3:a5:e5:5d:

11:95:e7:73:f9:b3:24:df:5e:4f:b1:5e:55:49:66:

3e:a4:39:3c:c5:a4:74:f0:a3:62:35:94:23:aa:e5:

db:83:67:07:35

ASN1 OID: prime256v1

X509v3 extensions:

X509v3 Subject Key Identifier:

 
E6:9B:18:14:7F:52:88:EB:C5:86:BE:B3:68:9E:BE:39:F3:A6:2B:E2

X509v3 Authority Key Identifier:

 
keyid:E6:9B:18:14:7F:52:88:EB:C5:86:BE:B3:68:9E:BE:39:F3:A6:2B:E2

DirName:/C=US/ST=Some-State/O=Internet Widgits Pty Ltd

serial:D2:4E:D0:AF:62:63:DA:1B

 

X509v3 Basic Constraints:

CA:TRUE

Signature Algorithm: ecdsa-with-SHA1

30:45:02:21:00:a7:58:a0:52:62:be:42:dd:53:83:6d:4c:c4:

4f:dd:96:24:56:f5:f8:6b:76:ec:3f:cf:fa:0b:41:8c:6c:4b:

85:02:20:24:00:ae:a7:fb:1b:37:cf:77:f6:3e:2e:47:22:ed:

ba:21:0b:79:32:31:3a:07:2b:2f:32:0e:81:4f:8c:eb:b0

 

 

Bill



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nabil Ghadiali
Sent: February 13, 2008 12:40 AM
To: openssl-users@openssl.org
Subject: ECC Self-Signed Certificate

 

Can someone help me with the command to generate a self-signed
certificate using openssl?

 

I have used the following steps and when I get a certificate and open up
it says "the signature is invalid". Am I missing something?

 

I have created an ECC key pair using the following:

openssl ecparam -out key.pem -name prime256v1 -genkey

 

I create the request using the following

openssl req -new -key key.pem -out req.pem

 

I create the self-signed certificate using the following

openssl req -x509 -in req.pem -days 365 -key key.pem 

 

I cannot tell why the certificate that is generated doesn't work. I am
pasting the generated certificate as well

-BEGIN CERTIFICATE-

MIICJzCCAc6gAwIBAgIJANJO0K9iY9obMAkGByqGSM49BAEwRTELMAkGA1UEBhMC

VVMxEzARBgNVBAgTClNvbWUtU3RhdGUxITAfBgNVBAoTGEludGVybmV0IFdpZGdp

dHMgUHR5IEx0ZDAeFw0wODAyMTMwNTM3MzlaFw0wOTAyMTIwNTM3MzlaMEUxCzAJ

BgNVBAYTAlVTMRMwEQYDVQQIEwpTb21lLVN0YXRlMSEwHwYDVQQKExhJbnRlcm5l

dCBXaWRnaXRzIFB0eSBMdGQwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATzJjKX

0dv55hhAU5X3Z/erUiWWqljSjtxt06XlXRGV53P5syTfXk+xXlVJZj6kOTzFpHTw

o2I1lCOq5duDZwc1o4GnMIGkMB0GA1UdDgQWBBTmmxgUf1KI68WGvrNonr4586Yr

4jB1BgNVHSMEbjBsgBTmmxgUf1KI68WGvrNonr4586Yr4qFJpEcwRTELMAkGA1UE

BhMCVVMxEzARBgNVBAgTClNvbWUtU3RhdGUxITAfBgNVBAoTGEludGVybmV0IFdp

ZGdpdHMgUHR5IEx0ZIIJANJO0K9iY9obMAwGA1UdEwQFMAMBAf8wCQYHKoZIzj0E

AQNIADBFAiEAp1igUmK+Qt1Tg21MxE/dliRW9fhrduw/z/oLQYxsS4UCICQArqf7

GzfPd/Y+Lkci7bohC3kyMToHKy8yDoFPjOuw

-END CERTIFICATE-

 

Thanks,

Nabil

 

 

 

 

 

 

Re: ECC Self-Signed Certificate

[Patrick Patterson]

On Wednesday 13 February 2008 09:58:08 Nabil Ghadiali wrote:
> I saved the base64 encoded text in a file with an extension ".cer" and then
> double-clicked it. Microsoft recognizes it is a certificate and opens it up
> in a certificate viewer.
>
> Over here it says "The integrity of the certificate cannot be guaranteed.
> The certificate may be corrupted or may have been altered"
>
Unless you are using Vista, Microsoft CAPI doesn't support ECC.

Have fun.

Patrick.

> Thanks,
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Victor Duchovni
> Sent: Wednesday, February 13, 2008 8:00 AM
> To: openssl-users@openssl.org
> Subject: Re: ECC Self-Signed Certificate
>
> On Wed, Feb 13, 2008 at 12:40:18AM -0500, Nabil Ghadiali wrote:
> > Can someone help me with the command to generate a self-signed
> > certificate using openssl?
> >
> >
> >
> > I have used the following steps and when I get a certificate and open up
>
> it
>
> > says "the signature is invalid". Am I missing something?
>
> What does "open it up" mean? The self-signed EC cert you posted looks
> fine.
>
> $ openssl verify -CAfile foo.pem -purpose crlsign foo.pem
> foo.pem: OK
>
> $ openssl x509 -text -in foo.pem
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number:
> d2:4e:d0:af:62:63:da:1b
> Signature Algorithm: ecdsa-with-SHA1
> Issuer: C=US, ST=Some-State, O=Internet Widgits Pty Ltd
> Validity
> Not Before: Feb 13 05:37:39 2008 GMT
> Not After : Feb 12 05:37:39 2009 GMT
> Subject: C=US, ST=Some-State, O=Internet Widgits Pty Ltd
> Subject Public Key Info:
> Public Key Algorithm: id-ecPublicKey
> Public-Key: (256 bit)
> pub:
> 04:f3:26:32:97:d1:db:f9:e6:18:40:53:95:f7:67:
> f7:ab:52:25:96:aa:58:d2:8e:dc:6d:d3:a5:e5:5d:
> 11:95:e7:73:f9:b3:24:df:5e:4f:b1:5e:55:49:66:
> 3e:a4:39:3c:c5:a4:74:f0:a3:62:35:94:23:aa:e5:
> db:83:67:07:35
> ASN1 OID: prime256v1
> X509v3 extensions:
> X509v3 Subject Key Identifier:
> E6:9B:18:14:7F:52:88:EB:C5:86:BE:B3:68:9E:BE:39:F3:A6:2B:E2
> X509v3 Authority Key Identifier:
>
> keyid:E6:9B:18:14:7F:52:88:EB:C5:86:BE:B3:68:9E:BE:39:F3:A6:2B:E2
> DirName:/C=US/ST=Some-State/O=Internet Widgits Pty Ltd
> serial:D2:4E:D0:AF:62:63:DA:1B
>
> X509v3 Basic Constraints:
> CA:TRUE
> Signature Algorithm: ecdsa-with-SHA1
> 30:45:02:21:00:a7:58:a0:52:62:be:42:dd:53:83:6d:4c:c4:
> 4f:dd:96:24:56:f5:f8:6b:76:ec:3f:cf:fa:0b:41:8c:6c:4b:
> 85:02:20:24:00:ae:a7:fb:1b:37:cf:77:f6:3e:2e:47:22:ed:
> ba:21:0b:79:32:31:3a:07:2b:2f:32:0e:81:4f:8c:eb:b0
> -BEGIN CERTIFICATE-
> MIICJzCCAc6gAwIBAgIJANJO0K9iY9obMAkGByqGSM49BAEwRTELMAkGA1UEBhMC
> VVMxEzARBgNVBAgTClNvbWUtU3RhdGUxITAfBgNVBAoTGEludGVybmV0IFdpZGdp
> dHMgUHR5IEx0ZDAeFw0wODAyMTMwNTM3MzlaFw0wOTAyMTIwNTM3MzlaMEUxCzAJ
> BgNVBAYTAlVTMRMwEQYDVQQIEwpTb21lLVN0YXRlMSEwHwYDVQQKExhJbnRlcm5l
> dCBXaWRnaXRzIFB0eSBMdGQwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATzJjKX
> 0dv55hhAU5X3Z/erUiWWqljSjtxt06XlXRGV53P5syTfXk+xXlVJZj6kOTzFpHTw
> o2I1lCOq5duDZwc1o4GnMIGkMB0GA1UdDgQWBBTmmxgUf1KI68WGvrNonr4586Yr
> 4jB1BgNVHSMEbjBsgBTmmxgUf1KI68WGvrNonr4586Yr4qFJpEcwRTELMAkGA1UE
> BhMCVVMxEzARBgNVBAgTClNvbWUtU3RhdGUxITAfBgNVBAoTGEludGVybmV0IFdp
> ZGdpdHMgUHR5IEx0ZIIJANJO0K9iY9obMAwGA1UdEwQFMAMBAf8wCQYHKoZIzj0E
> AQNIADBFAiEAp1igUmK+Qt1Tg21MxE/dliRW9fhrduw/z/oLQYxsS4UCICQArqf7
> GzfPd/Y+Lkci7bohC3kyMToHKy8yDoFPjOuw
> -END CERTIFICATE-



-- 
Patrick Patterson
President and Chief PKI Architect,
Carillon Information Security Inc.
http://www.carillon.ca
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: ECC Self-Signed Certificate

[Nabil Ghadiali]

I saved the base64 encoded text in a file with an extension ".cer" and then
double-clicked it. Microsoft recognizes it is a certificate and opens it up
in a certificate viewer. 

Over here it says "The integrity of the certificate cannot be guaranteed.
The certificate may be corrupted or may have been altered"

Thanks, 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Victor Duchovni
Sent: Wednesday, February 13, 2008 8:00 AM
To: openssl-users@openssl.org
Subject: Re: ECC Self-Signed Certificate

On Wed, Feb 13, 2008 at 12:40:18AM -0500, Nabil Ghadiali wrote:

> Can someone help me with the command to generate a self-signed certificate
> using openssl?
> 
>  
> 
> I have used the following steps and when I get a certificate and open up
it
> says "the signature is invalid". Am I missing something?

What does "open it up" mean? The self-signed EC cert you posted looks
fine.

$ openssl verify -CAfile foo.pem -purpose crlsign foo.pem
foo.pem: OK

$ openssl x509 -text -in foo.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
d2:4e:d0:af:62:63:da:1b
Signature Algorithm: ecdsa-with-SHA1
Issuer: C=US, ST=Some-State, O=Internet Widgits Pty Ltd
Validity
Not Before: Feb 13 05:37:39 2008 GMT
Not After : Feb 12 05:37:39 2009 GMT
Subject: C=US, ST=Some-State, O=Internet Widgits Pty Ltd
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:f3:26:32:97:d1:db:f9:e6:18:40:53:95:f7:67:
f7:ab:52:25:96:aa:58:d2:8e:dc:6d:d3:a5:e5:5d:
11:95:e7:73:f9:b3:24:df:5e:4f:b1:5e:55:49:66:
3e:a4:39:3c:c5:a4:74:f0:a3:62:35:94:23:aa:e5:
db:83:67:07:35
ASN1 OID: prime256v1
X509v3 extensions:
X509v3 Subject Key Identifier:
E6:9B:18:14:7F:52:88:EB:C5:86:BE:B3:68:9E:BE:39:F3:A6:2B:E2
X509v3 Authority Key Identifier:
 
keyid:E6:9B:18:14:7F:52:88:EB:C5:86:BE:B3:68:9E:BE:39:F3:A6:2B:E2
DirName:/C=US/ST=Some-State/O=Internet Widgits Pty Ltd
serial:D2:4E:D0:AF:62:63:DA:1B

X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: ecdsa-with-SHA1
30:45:02:21:00:a7:58:a0:52:62:be:42:dd:53:83:6d:4c:c4:
4f:dd:96:24:56:f5:f8:6b:76:ec:3f:cf:fa:0b:41:8c:6c:4b:
85:02:20:24:00:ae:a7:fb:1b:37:cf:77:f6:3e:2e:47:22:ed:
ba:21:0b:79:32:31:3a:07:2b:2f:32:0e:81:4f:8c:eb:b0
-BEGIN CERTIFICATE-
MIICJzCCAc6gAwIBAgIJANJO0K9iY9obMAkGByqGSM49BAEwRTELMAkGA1UEBhMC
VVMxEzARBgNVBAgTClNvbWUtU3RhdGUxITAfBgNVBAoTGEludGVybmV0IFdpZGdp
dHMgUHR5IEx0ZDAeFw0wODAyMTMwNTM3MzlaFw0wOTAyMTIwNTM3MzlaMEUxCzAJ
BgNVBAYTAlVTMRMwEQYDVQQIEwpTb21lLVN0YXRlMSEwHwYDVQQKExhJbnRlcm5l
dCBXaWRnaXRzIFB0eSBMdGQwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATzJjKX
0dv55hhAU5X3Z/erUiWWqljSjtxt06XlXRGV53P5syTfXk+xXlVJZj6kOTzFpHTw
o2I1lCOq5duDZwc1o4GnMIGkMB0GA1UdDgQWBBTmmxgUf1KI68WGvrNonr4586Yr
4jB1BgNVHSMEbjBsgBTmmxgUf1KI68WGvrNonr4586Yr4qFJpEcwRTELMAkGA1UE
BhMCVVMxEzARBgNVBAgTClNvbWUtU3RhdGUxITAfBgNVBAoTGEludGVybmV0IFdp
ZGdpdHMgUHR5IEx0ZIIJANJO0K9iY9obMAwGA1UdEwQFMAMBAf8wCQYHKoZIzj0E
AQNIADBFAiEAp1igUmK+Qt1Tg21MxE/dliRW9fhrduw/z/oLQYxsS4UCICQArqf7
GzfPd/Y+Lkci7bohC3kyMToHKy8yDoFPjOuw
-END CERTIFICATE-

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: ECC Self-Signed Certificate

[Victor Duchovni]

On Wed, Feb 13, 2008 at 12:40:18AM -0500, Nabil Ghadiali wrote:

> Can someone help me with the command to generate a self-signed certificate
> using openssl?
> 
>  
> 
> I have used the following steps and when I get a certificate and open up it
> says "the signature is invalid". Am I missing something?

What does "open it up" mean? The self-signed EC cert you posted looks
fine.

$ openssl verify -CAfile foo.pem -purpose crlsign foo.pem
foo.pem: OK

$ openssl x509 -text -in foo.pem
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
d2:4e:d0:af:62:63:da:1b
Signature Algorithm: ecdsa-with-SHA1
Issuer: C=US, ST=Some-State, O=Internet Widgits Pty Ltd
Validity
Not Before: Feb 13 05:37:39 2008 GMT
Not After : Feb 12 05:37:39 2009 GMT
Subject: C=US, ST=Some-State, O=Internet Widgits Pty Ltd
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:f3:26:32:97:d1:db:f9:e6:18:40:53:95:f7:67:
f7:ab:52:25:96:aa:58:d2:8e:dc:6d:d3:a5:e5:5d:
11:95:e7:73:f9:b3:24:df:5e:4f:b1:5e:55:49:66:
3e:a4:39:3c:c5:a4:74:f0:a3:62:35:94:23:aa:e5:
db:83:67:07:35
ASN1 OID: prime256v1
X509v3 extensions:
X509v3 Subject Key Identifier:
E6:9B:18:14:7F:52:88:EB:C5:86:BE:B3:68:9E:BE:39:F3:A6:2B:E2
X509v3 Authority Key Identifier:

keyid:E6:9B:18:14:7F:52:88:EB:C5:86:BE:B3:68:9E:BE:39:F3:A6:2B:E2
DirName:/C=US/ST=Some-State/O=Internet Widgits Pty Ltd
serial:D2:4E:D0:AF:62:63:DA:1B

X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: ecdsa-with-SHA1
30:45:02:21:00:a7:58:a0:52:62:be:42:dd:53:83:6d:4c:c4:
4f:dd:96:24:56:f5:f8:6b:76:ec:3f:cf:fa:0b:41:8c:6c:4b:
85:02:20:24:00:ae:a7:fb:1b:37:cf:77:f6:3e:2e:47:22:ed:
ba:21:0b:79:32:31:3a:07:2b:2f:32:0e:81:4f:8c:eb:b0
-BEGIN CERTIFICATE-
MIICJzCCAc6gAwIBAgIJANJO0K9iY9obMAkGByqGSM49BAEwRTELMAkGA1UEBhMC
VVMxEzARBgNVBAgTClNvbWUtU3RhdGUxITAfBgNVBAoTGEludGVybmV0IFdpZGdp
dHMgUHR5IEx0ZDAeFw0wODAyMTMwNTM3MzlaFw0wOTAyMTIwNTM3MzlaMEUxCzAJ
BgNVBAYTAlVTMRMwEQYDVQQIEwpTb21lLVN0YXRlMSEwHwYDVQQKExhJbnRlcm5l
dCBXaWRnaXRzIFB0eSBMdGQwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATzJjKX
0dv55hhAU5X3Z/erUiWWqljSjtxt06XlXRGV53P5syTfXk+xXlVJZj6kOTzFpHTw
o2I1lCOq5duDZwc1o4GnMIGkMB0GA1UdDgQWBBTmmxgUf1KI68WGvrNonr4586Yr
4jB1BgNVHSMEbjBsgBTmmxgUf1KI68WGvrNonr4586Yr4qFJpEcwRTELMAkGA1UE
BhMCVVMxEzARBgNVBAgTClNvbWUtU3RhdGUxITAfBgNVBAoTGEludGVybmV0IFdp
ZGdpdHMgUHR5IEx0ZIIJANJO0K9iY9obMAwGA1UdEwQFMAMBAf8wCQYHKoZIzj0E
AQNIADBFAiEAp1igUmK+Qt1Tg21MxE/dliRW9fhrduw/z/oLQYxsS4UCICQArqf7
GzfPd/Y+Lkci7bohC3kyMToHKy8yDoFPjOuw
-END CERTIFICATE-

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

ECC Self-Signed Certificate

[Nabil Ghadiali]

Can someone help me with the command to generate a self-signed certificate
using openssl?

 

I have used the following steps and when I get a certificate and open up it
says "the signature is invalid". Am I missing something?

 

I have created an ECC key pair using the following:

openssl ecparam -out key.pem -name prime256v1 -genkey

 

I create the request using the following

openssl req -new -key key.pem -out req.pem

 

I create the self-signed certificate using the following

openssl req -x509 -in req.pem -days 365 -key key.pem 

 

I cannot tell why the certificate that is generated doesn't work. I am
pasting the generated certificate as well

-BEGIN CERTIFICATE-

MIICJzCCAc6gAwIBAgIJANJO0K9iY9obMAkGByqGSM49BAEwRTELMAkGA1UEBhMC

VVMxEzARBgNVBAgTClNvbWUtU3RhdGUxITAfBgNVBAoTGEludGVybmV0IFdpZGdp

dHMgUHR5IEx0ZDAeFw0wODAyMTMwNTM3MzlaFw0wOTAyMTIwNTM3MzlaMEUxCzAJ

BgNVBAYTAlVTMRMwEQYDVQQIEwpTb21lLVN0YXRlMSEwHwYDVQQKExhJbnRlcm5l

dCBXaWRnaXRzIFB0eSBMdGQwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATzJjKX

0dv55hhAU5X3Z/erUiWWqljSjtxt06XlXRGV53P5syTfXk+xXlVJZj6kOTzFpHTw

o2I1lCOq5duDZwc1o4GnMIGkMB0GA1UdDgQWBBTmmxgUf1KI68WGvrNonr4586Yr

4jB1BgNVHSMEbjBsgBTmmxgUf1KI68WGvrNonr4586Yr4qFJpEcwRTELMAkGA1UE

BhMCVVMxEzARBgNVBAgTClNvbWUtU3RhdGUxITAfBgNVBAoTGEludGVybmV0IFdp

ZGdpdHMgUHR5IEx0ZIIJANJO0K9iY9obMAwGA1UdEwQFMAMBAf8wCQYHKoZIzj0E

AQNIADBFAiEAp1igUmK+Qt1Tg21MxE/dliRW9fhrduw/z/oLQYxsS4UCICQArqf7

GzfPd/Y+Lkci7bohC3kyMToHKy8yDoFPjOuw

-END CERTIFICATE-

 

Thanks,

Nabil

 

 

 

 

 

 

certificate chain verification up to self-signed certificate - why?

[Steffen DETTMER]

Hi,

certificate chain verification is always done until a self-signed
CA certificate (root CA certificate), even if intermediate sub-CA
certificates are locally known (which equals trusted) - but why?
Is there some cryptographic requirement for this?

  (I understood that a root-CA certificate must be self-signed
   (instead of having no signature at all) to avoid that a
   man-in-the-middle could modify cerificates properties -
   however, the local filesystem must be safe for such
   manipulations anyway).

Please note that someone may trust (in means of authentication
for the appropriate purpose) the root CA but not all of their sub
CAs, for instance, when there is a high level policy and a medium
level policy.

oki,

Steffen
 
About Ingenico Throughout the world businesses rely on Ingenico for secure and 
expedient electronic transaction acceptance. Ingenico products leverage proven 
technology, established standards and unparalleled ergonomics to provide 
optimal reliability, versatility and usability. This comprehensive range of 
products is complemented by a global array of services and partnerships, 
enabling businesses in a number of vertical sectors to accept transactions 
anywhere their business takes them.
www.ingenico.com This message may contain confidential and/or privileged 
information. If you are not the addressee or authorized to receive this for the 
addressee, you must not use, copy, disclose or take any action based on this 
message or any information herein. If you have received this message in error, 
please advise the sender immediately by reply e-mail and delete this message. 
Thank you for your cooperation.
 
About Ingenico Throughout the world businesses rely on Ingenico for secure and 
expedient electronic transaction acceptance. Ingenico products leverage proven 
technology, established standards and unparalleled ergonomics to provide 
optimal reliability, versatility and usability. This comprehensive range of 
products is complemented by a global array of services and partnerships, 
enabling businesses in a number of vertical sectors to accept transactions 
anywhere their business takes them.
www.ingenico.com This message may contain confidential and/or privileged 
information. If you are not the addressee or authorized to receive this for the 
addressee, you must not use, copy, disclose or take any action based on this 
message or any information herein. If you have received this message in error, 
please advise the sender immediately by reply e-mail and delete this message. 
Thank you for your cooperation.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Problem with Self-Signed certificate and wpa_supplicant

[jinlu8591]

Hi,

I have a problem with self assigned certificate when using wpa_supplicant as
(exactly) described 
in the attached old message in this forum.  I wonder if anybody can shed
some light into it.

Here is what tried to solve it, but without any luck:

* find OPENSSLDIR ("openssl version -d")
* put the self signed certificate ( cacert.pem) in $OPENSSLDIR/certs
* create the hash-based symlink using some script
* then I do "openssl verify cacert.pem", and got ok

despite the above, I till get 

TLS: Certificate verification failed, error 18 (self signed   
certificate) depth 0 for '/C=US/ST= .. .' 
SSL: (where=0x4008 ret=0x230) 
SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unknown CA 

** old message *********

Problem with Self-Signed certificate and wpa_supplicant   by Philippe Vachon
Jun 23, 2005; 08:52am :: Rate this Message:(use ratings to moderate[?])

Reply | Reply to Author | View in Thread 
Hello All. 

I've been trying to setup WPA security on my network. As such, I have   
been generating my own root and server certificate, and signing my   
client certificates with said root certificate. However, for some   
reason, whenever I try to use the certificates with wpa_supplicant, I   
get the following errors: 

TLS: Certificate verification failed, error 18 (self signed   
certificate) depth 0 for '/C=CA/O=Radialink/CN=RADIUS' 
SSL: (where=0x4008 ret=0x230) 
SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unknown CA 
SSL: (where=0x1002 ret=0x) 
SSL: SSL_connect:error in SSLv3 read server certificate B 
SSL: SSL_connect: error:14090086:SSL   
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed 

whenever I try to authenticate. I am reasonably certain there is no   
problem with my FreeRADIUS configuration, however, I suspect there   
might be a problem with my root certificate based on this error. Is   
anybody able to shed any light on this for me? 

Thanks, 
Phil. 


-- 
View this message in context: 
http://www.nabble.com/Problem-with-Self-Signed-certificate-and-wpa_supplicant-tf4270305.html#a12154183
Sent from the OpenSSL - User mailing list archive at Nabble.com.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: Self Signed Certificate: certificate chain verification failure

[Goetz Babin-Ebell]

Hello,

--On Juli 03, 2007 13:31:27 +0530 Vishal V <[EMAIL PROTECTED]> wrote:


Many thanks for the information.

But my query is partially answered.

Here it goes

A) Doesn't client need server's self-signed certificate to validate the
transmitted certificate?
- Is Question A is true then how to obtain this certificate.

That is outside of the scope of OpenSSL.
You can contact the server's admibistrator to obtain
the certificate, download and store it with s_client and
compare the fingerprint (by phone or other means) or contact
somebody else you trust.

OpenSSL can only check if a certificate was signed by
a CA certificate or was self signed.
The decision if YOU trust the identity that signed
the certificate to sign certificates can only done by YOU.


- Also how to configure this certificate for use at the client side

That depends on the client.
In openssl s_client you do that with the -CAfile option.

Bye

Goetz

--
DMCA: The greed of the few outweights the freedom of the many


pgplGwQEmmAuK.pgp
Description: PGP signature

RE: Self Signed Certificate: certificate chain verification failure

[Vishal V]

Many thanks for the information. 

But my query is partially answered.

Here it goes

A) Doesn't client need server's self-signed certificate to validate the
transmitted certificate? 
- Is Question A is true then how to obtain this certificate. 
- Also how to configure this certificate for use at the client side 

Client Environment is 
Solaris (Unix), gSOAP (C++), openssl 

Thanks once again for your patience

Regards,
Vishal Vashishta
Tata Consultancy Services
Mailto: [EMAIL PROTECTED]
Website: http://www.tcs.com



"Lindsay Hausner" <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED]
07/02/2007 11:50 PM
Please respond to
openssl-users@openssl.org


To

cc

Subject
RE: Self Signed Certificate: certificate chain verification failure








-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Vishal V
Sent: Monday, July 02, 2007 5:17 AM
To: openssl-users@openssl.org
Subject: Self Signed Certificate: certificate chain verification failure
Importance: High


Resending my mail with corrected information 





Dear All, 
My client program fails to establish the secure connection (https) with 
web
server due to certificate chain verification failure. 
And I think the error is due to a self signed certificate. 

___ 
MY UNDERSTANDING 
-- 
"During a session establishment a server always transmits its certificate 
to
the client, and the client must validate the certificate. 
Therefore, if the server is using a self-signed certificate, the 
certificate
must be made available to the client prior to the actual 
session establishment attempt. 

___ 
QUERY 
- 
A) Doesn't client need server's self-signed certificate to validate the
transmitted certificate? 

Yes.

lh..


ForwardSourceID:NT00016CB6 
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you

RE: Self Signed Certificate: certificate chain verification failure

[Lindsay Hausner]

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Vishal V
Sent: Monday, July 02, 2007 5:17 AM
To: openssl-users@openssl.org
Subject: Self Signed Certificate: certificate chain verification failure
Importance: High


Resending my mail with corrected information 





Dear All, 
My client program fails to establish the secure connection (https) with web
server due to certificate chain verification failure.   
And I think the error is due to a self signed certificate. 

___ 
MY UNDERSTANDING 
-- 
"During a session establishment a server always transmits its certificate to
the client, and the client must validate the certificate. 
Therefore, if the server is using a self-signed certificate, the certificate
must be made available to the client prior to the actual 
session establishment attempt. 

___ 
QUERY 
- 
A) Doesn't client need server's self-signed certificate to validate the
transmitted certificate? 

Yes.

lh..



smime.p7s
Description: S/MIME cryptographic signature

Self Signed Certificate: certificate chain verification failure

[Vishal V]

Resending my mail with corrected information





Dear All, 
My client program fails to establish the secure connection (https) with 
web server due to certificate chain verification failure.   
And I think the error is due to a self signed certificate. 
___
 

MY UNDERSTANDING 
-- 
?During a session establishment a server always transmits its certificate 
to the client, and the client must validate the certificate. 
Therefore, if the server is using a self-signed certificate, the 
certificate must be made available to the client prior to the actual 
session establishment attempt. 
___
 

QUERY 
- 
A) Doesn't client need server's self-signed certificate to validate the 
transmitted certificate? 
Or 
B) Is there a setting that allows accepting of self-signed certificate? 

Is Question A is true then how to obtain this certificate. 
Client Environment is 
Solaris (Unix), gSOAP (C++), openssl 

___
 

OPENSSL command output (confidential information is replaced here) 
--- 
CONNECTED(0004) 
depth=0 /C=UK/ST=New York/L=ABC House/O=ABC Bank/OU=ZIT-A CMA BOS 
(2.3.5.1)/CN=shsvd1a.gde 
verify error:num=18:self signed certificate 
verify return:1 
depth=0 /C=UK/ST=New York/L=ABC House/O=ABC Bank/OU=ZIT-A CMA BOS 
(2.3.5.1)/CN=shsvd1a.gde 
verify return:1 
--- 
Certificate chain 
 0 s:/C=UK/ST=New York/L=ABC House/O=ABC Bank/OU=ZIT-A CMA BOS 
(2.3.5.1)/CN=shsvd1a.gde 
   i:/C=UK/ST=New York/L=ABC House/O=ABC Bank/OU=ZIT-A CMA BOS 
(2.3.5.1)/CN=shsvd1a.gde 
--- 
Server certificate 
-BEGIN CERTIFICATE- 
MIICgDCCAekCBETYvTYwDQYJKoZIhvcNAQEEBQAwgYYxCzAJBgNVBAYTAlVLMQ8w 
AWDQYDVQQIEwZMb25kb24xGDAWBgNVBAcTD1NoZXJib3JuZSBIb3VzZTEUMBIGA1UE 
ChMLQ29tbWVyemJhbmsxIDAeBgNVBAsTF1pJVC1BIENNQSBCT1MgKDIuMy41LjEp 
MRQwEgYDVQQDEwtzaHN2ZDNhLmdkZTAeFw0wNjA4MDgxNjM1MDJaFw0yMzAxMTEx 
NjM1MDJaMIGGMQswCQYDVQQGEwJVSzEPMA0GA1UECBMGTG9uZG9uMRgwFgYDVQQH 
Ew9TaGVyYm9ybmUgSG91c2UxFDASBgNVBAoTC0NvbW1lcnpiYW5rMSAwHgYDVQQL 
ExdaSVQtQSBDTUEgQk9TICgyLjMuNS4xKTEUMBIGA1UEAxMLc2hzdmQzYS5nZGUw 
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMqFdZrLVDXMgrnX7ne6IfRqo38C 
ODn2vXMiy+khDVLUDxPh0qsMmV03loPhzwLNviBhxxamiBbtsXXe6ztXf09LOmtu 
g4UTQUXuBTaBqsOivqZBmr2Nxaq9j7Ma3dVG+dAsgfSgzn5h78sWfQkD+hX6DCXR 
xFxP2Ls1wrnJ5Ia9AgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAgfOx7UeISfuw04OU 
EC4Ur5uNPE2kQ92KSNgLRJMZ/xQYjZVmCWSOEJVO+NrLWuO6Mv86cnKPLBWnCRFe 
GYm9EIbMKDExs8QWU0+gYkUHBHjtWbMYIeiFNUFBQvr+rqINdci2L52jRbLeWPgY 
HK+zxEoiBFpbDEciVFUzyq1XTeA= 
-END CERTIFICATE- 
subject=/C=UK/ST=New York/L=ABC House/O=ABC Bank/OU=ZIT-A CMA BOS 
(2.3.5.1)/CN=shsvd1a.gde 
issuer=/C=UK/ST=New York/L=ABC House/O=ABC Bank/OU=ZIT-A CMA BOS 
(2.3.5.1)/CN=shsvd1a.gde 
--- 
No client certificate CA names sent 
--- 
SSL handshake has read 1185 bytes and written 338 bytes 
--- 
New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA 
Server public key is 1024 bit 
SSL-Session: 
Protocol  : TLSv1 
Cipher: EDH-RSA-DES-CBC3-SHA 
Session-ID: 
4688BDBECF7EEBC40A44CD4DBC9B272864EBC987406E0F72579D444A4831F457 
Session-ID-ctx: 
Master-Key: 
99F6236023E13435BD8CBEDD5126254E3F46E61EEB6D432483F1D755975623EF708C85E3BBC36418AEFCFFF791612C32
 

Key-Arg   : None 
Start Time: 1183366590 
Timeout   : 300 (sec) 
Verify return code: 18 (self signed certificate) 
--- 

Thanks in advance 

Regards,
Vishal Vashishta
ForwardSourceID:NT00016C66 
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you

Self Signed Certificate: certificate chain verification failure

[Vishal V]

Dear All,

My client problem fails to establish the secure connection (https) with 
web server due to certificate chain verification failure. 
And I think the error is due to a self signed certificate. 
___
MY UNDERSTANDING
--
?During a session establishment a server always transmits its certificate 
to the client, and the client must validate the certificate. 
Therefore, if the server is using a self-signed certificate, the 
certificate must be made available to the client prior to the actual 
session establishment attempt. 
___
QUERY
-
A) Doesn't client need server's self-signed certificate to validate the 
transmitted certificate? 
Or 
B) Is there a setting that allows accepting of self-signed certificate? 

Is Question A is true then how to obtain this certificate. 
Client Environment is 
Solaris (Unix), gSOAP (C++), openssl

___
OPENSSL command output (confidential information is replaced here)
--- 
CONNECTED(0004)
depth=0 /C=UK/ST=New York/L=ABC House/O=ABC Bank/OU=ZIT-A CMA BOS 
(2.3.5.1)/CN=shsvd1a.gde
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=UK/ST=New York/L=ABC House/O=ABC Bank/OU=ZIT-A CMA BOS 
(2.3.5.1)/CN=shsvd1a.gde
verify return:1
---
Certificate chain
 0 s:/C=UK/ST=New York/L=ABC House/O=ABC Bank/OU=ZIT-A CMA BOS 
(2.3.5.1)/CN=shsvd1a.gde
   i:/C=UK/ST=New York/L=ABC House/O=ABC Bank/OU=ZIT-A CMA BOS 
(2.3.5.1)/CN=shsvd1a.gde
---
Server certificate
-BEGIN CERTIFICATE-
MIICgDCCAekCBETYvTYwDQYJKoZIhvcNAQEEBQAwgYYxCzAJBgNVBAYTAlVLMQ8w
AWDQYDVQQIEwZMb25kb24xGDAWBgNVBAcTD1NoZXJib3JuZSBIb3VzZTEUMBIGA1UE
ChMLQ29tbWVyemJhbmsxIDAeBgNVBAsTF1pJVC1BIENNQSBCT1MgKDIuMy41LjEp
MRQwEgYDVQQDEwtzaHN2ZDNhLmdkZTAeFw0wNjA4MDgxNjM1MDJaFw0yMzAxMTEx
NjM1MDJaMIGGMQswCQYDVQQGEwJVSzEPMA0GA1UECBMGTG9uZG9uMRgwFgYDVQQH
Ew9TaGVyYm9ybmUgSG91c2UxFDASBgNVBAoTC0NvbW1lcnpiYW5rMSAwHgYDVQQL
ExdaSVQtQSBDTUEgQk9TICgyLjMuNS4xKTEUMBIGA1UEAxMLc2hzdmQzYS5nZGUw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMqFdZrLVDXMgrnX7ne6IfRqo38C
ODn2vXMiy+khDVLUDxPh0qsMmV03loPhzwLNviBhxxamiBbtsXXe6ztXf09LOmtu
g4UTQUXuBTaBqsOivqZBmr2Nxaq9j7Ma3dVG+dAsgfSgzn5h78sWfQkD+hX6DCXR
xFxP2Ls1wrnJ5Ia9AgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAgfOx7UeISfuw04OU
EC4Ur5uNPE2kQ92KSNgLRJMZ/xQYjZVmCWSOEJVO+NrLWuO6Mv86cnKPLBWnCRFe
GYm9EIbMKDExs8QWU0+gYkUHBHjtWbMYIeiFNUFBQvr+rqINdci2L52jRbLeWPgY
HK+zxEoiBFpbDEciVFUzyq1XTeA=
-END CERTIFICATE-
subject=/C=UK/ST=New York/L=ABC House/O=ABC Bank/OU=ZIT-A CMA BOS 
(2.3.5.1)/CN=shsvd1a.gde
issuer=/C=UK/ST=New York/L=ABC House/O=ABC Bank/OU=ZIT-A CMA BOS 
(2.3.5.1)/CN=shsvd1a.gde
---
No client certificate CA names sent
---
SSL handshake has read 1185 bytes and written 338 bytes
---
New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA
Server public key is 1024 bit
SSL-Session:
Protocol  : TLSv1
Cipher: EDH-RSA-DES-CBC3-SHA
Session-ID: 
4688BDBECF7EEBC40A44CD4DBC9B272864EBC987406E0F72579D444A4831F457
Session-ID-ctx:
Master-Key: 
99F6236023E13435BD8CBEDD5126254E3F46E61EEB6D432483F1D755975623EF708C85E3BBC36418AEFCFFF791612C32
Key-Arg   : None
Start Time: 1183366590
Timeout   : 300 (sec)
Verify return code: 18 (self signed certificate)
---
CONNECTED(0003) 
depth=3D0 /C=3Dau/ST=3Dtest/O=3Dtest/OU=3Dtest/CN=3Dtest 
verify error:num=3D18:self signed certificate 
verify return:1 
depth=3D0 /C=3Dau/ST=3Dtest/O=3Dtest/OU=3Dtest/CN=3Dtest 
verify return:1 
--- 
Certificate chain 
 0 s:/C=3Dau/ST=3Dtest/O=3Dtest/OU=3Dtest/CN=3Dtest 
   i:/C=3Dau/ST=3Dtest/O=3Dtest/OU=3Dtest/CN=3Dtest 
--- 
Server certificate 
[output deleted] 
subject=3D/C=3Dau/ST=3Dtest/O=3Dtest/OU=3Dtest/CN=3Dtest 
issuer=3D/C=3Dau/ST=3Dtest/O=3Dtest/OU=3Dtest/CN=3Dtest 
--- 
No client certificate CA names sent 
--- 
SSL handshake has read 672 bytes and written 252 bytes 
--- 
New, TLSv1/SSLv3, Cipher is AES128-SHA 
Server public key is 1024 bit 
Compression: NONE 
Expansion: NONE 
SSL-Session: 
Protocol  : TLSv1 
Cipher: AES128-SHA 
Session-ID: 
[output deleted] 
Verify return code: 18 (self signed certificate) 
--- 
[output of http get deleted] 


Thanks in advance

Regards,
Vishal Vashishta
Mailto: [EMAIL PROTECTED]
Website: http://www.tcs.com
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently