from:"openssl"

答复: How run the specific test case //答复: How to run a simple test case

2022-02-09 Thread Chenxinping via openssl-users

Thanks for the  information.
NCONF_load  will failed with “./test/ssl_test 
./test-runs/test_ssl_new/17-renegotiate.cnf.default”. As strdup will failed in 
case of “${ENV::TEST_CERTS_DIR}/*” .
Maybe the ENV should be setted before run the test case.

Error information:
# ERROR: (int) 'NCONF_load(conf, test_get_argument(0), NULL) > 0' failed @ 
test/ssl_test.c:550
# [0] compared to [0]
# ERROR:  @ test/ssl_test.c:553

发件人: Dr. Matthias St. Pierre [mailto:matthias.st.pie...@ncp-e.com]
发送时间: 2022年2月9日 23:31
收件人: Chenxinping ; openssl-users@openssl.org
主题: RE: How run the specific test case //答复: How to run a simple test case

Ah ok, maybe I slightly misunderstood your question. From your transcript below 
I infer that the testsuite ran the perl script `generate_ssl_tests.pl`, which 
generated some test files an then ran the binary `ssl_test` as follows:

./test/ssl_test ./test-runs/test_ssl_new/17-renegotiate.cnf.default

If the testfile `./test-runs/test_ssl_new/17-renegotiate.cnf.default` still 
exists, you should be able to debug the program in gdb with the aid of the 
`wrap.pl` helper script as follows:

./util/wrap.pl  gdb –args ./test/ssl_test 
./test-runs/test_ssl_new/17-renegotiate.cnf.default


Hope that helps,

Matthias





[NCP engingeering GmbH]

Dr. Matthias St. Pierre

Tech Lead Cryptography
matthias.st.pie...@ncp-e.com<mailto:matthias.st.pie...@ncp-e.com>
Phone: +49 911 9968-0
www.ncp-e.com<http://www.ncp-e.com>


Follow us on:
 Facebook<https://www.facebook.com/NCPengineering> | 
Twitter<https://twitter.com/NCP_engineering> | 
Xing<https://www.xing.com/companies/ncpengineeringgmbh> | 
YouTube<https://www.youtube.com/user/NCPengineeringGmbH> | 
LinkedIn<http://www.linkedin.com/company/ncp-engineering-inc.?trk=cws-cpw-coname-0-0>

Headquarters Germany: NCP engineering GmbH • Dombuehler Str. 2 • 90449 • 
Nuremberg
North American HQ: NCP engineering Inc. • 601 Cleveland Str., Suite 501-25 • 
Clearwater, FL 33755

Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate Dietrich
Registry Court: Lower District Court of Nuremberg
Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE 
133557619

This e-mail message including any attachments is for the sole use of the 
intended recipient(s) and may contain privileged or confidential information. 
Any unauthorized review, use, disclosure or distribution is prohibited. If you 
are not the intended recipient, please immediately contact the sender by reply 
e-mail and delete the original message and destroy all copies thereof.



From: Chenxinping mailto:kan.c...@huawei.com>>
Sent: Wednesday, February 9, 2022 4:10 PM
To: Dr. Matthias St. Pierre 
mailto:matthias.st.pie...@ncp-e.com>>; 
openssl-users@openssl.org<mailto:openssl-users@openssl.org>
Subject: How run the specific test case //答复: How to run a simple test case

Thanks for your information,  simple test case means some specific test case.
Some  error reported from some specific test case  in case of “make V=1 
TESTS='test_ssl_new*' test”, the error information could not help to local the 
issue, So I need run and debug the specific test case.

Error information:
../../util/wrap.pl /usr/bin/perl -I ../../util/perl 
../../test/generate_ssl_tests.pl ../../test/ssl-tests/17-renegotiate.cnf.in 
none > 17-renegotiate.cnf.none => 0
ok 1 - Getting output from generate_ssl_tests.pl.
ok 2 - Comparing generated 17-renegotiate.cnf.none with 
../../test/ssl-tests/17-renegotiate.cnf.
# Subtest: ../../test/ssl_test
1..1
# Subtest: test_handshake
1..17
ok 1 - iteration 1
ok 2 - iteration 2
ok 3 - iteration 3
ok 4 - iteration 4
ok 5 - iteration 5
ok 6 - iteration 6
ok 7 - iteration 7
ok 8 - iteration 8
ok 9 - iteration 9
ok 10 - iteration 10
ok 11 - iteration 11
# ERROR: (int) 'peer->status == PEER_RETRY' failed @ 
test/helpers/handshake.c:868
# [2] compared to [1]
# ERROR: (int) 'result->result == test_ctx->expected_result' failed 
@ test/ssl_test.c:36
# [3] compared to [1]
# INFO:  @ test/ssl_test.c:37
# ExpectedResult mismatch: expected ServerFail, got InternalError.
# OPENSSL_TEST_RAND_ORDER=1644408281
not ok 12 - iteration 12
ok 13 - iteration 13
# ERROR: (int) 'peer->status == PEER_RETRY' failed @ 
test/helpers/handshake.c:868
# [2] compared to [1]
# ERROR: (int) 'result->result == test_ctx->expected_result' failed 
@ test/ssl_test.c:36
# [3] compared to [2]
# INFO:  @ test/ssl_test.c:37
# ExpectedResult mismatch: expected ClientFail, got InternalError.
# OPENSSL_TEST_RAND_ORDER=1644408281
not ok 14 - iteration 14

答复: How run the specific test case //答复: How to run a simple test case

2022-02-10 Thread Chenxinping via openssl-users

Thanks for your information.
Issue have raised:
https://github.com/openssl/openssl/issues/17681

-邮件原件-
发件人: Dr. Matthias St. Pierre [mailto:matthias.st.pie...@ncp-e.com] 
发送时间: 2022年2月10日 0:03
收件人: Chenxinping ; openssl-users@openssl.org
主题: RE: How run the specific test case //答复: How to run a simple test case

The problem lies with the Perl script, not the C program.

The perl script generates the file 17-renegotiate.cnf.default from the template 
file  17-renegotiate.cnf.in.
The environment variable “${ENV::TEST_CERTS_DIR}” should have been replaced by 
Perl.

Please open an issue on GitHub, it’s easier to discuss your problem there. You 
might want to tag @levitte, he should be able to help.

https://github.com/openssl/openssl/issues/new/choose


Matthias



Dr. Matthias St. Pierre
Tech Lead Cryptography
matthias.st.pie...@ncp-e.com
Phone: +49 911 9968-0
 www.ncp-e.com

Headquarters Germany: NCP engineering GmbH • Dombuehler Str. 2 • 90449 • 
Nuremberg
North American HQ: NCP engineering Inc. • 601 Cleveland Str., Suite 501-25 • 
Clearwater, FL 33755

Authorized representatives: Peter Soell, Patrick Oliver Graf, Beate Dietrich
Registry Court: Lower District Court of Nuremberg
Commercial register No.: HRB 7786 Nuremberg, VAT identification No.: DE 
133557619

This e-mail message including any attachments is for the sole use of the 
intended recipient(s) and may contain privileged
or confidential information. Any unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended recipient,
please immediately contact the sender by reply e-mail and delete the original 
message and destroy all copies thereof.

自动回复: Re: How to distinguish between encrypted/unencrypted key in a PEM file

2022-01-27 Thread 562430030 via openssl-users

您好，您的邮件我已收到，我会尽快阅读，谢谢！

自动回复: Re: TLSv1.2 Distinguished Names Length 0 / how to set it

2022-01-19 Thread 562430030 via openssl-users

您好，您的邮件我已收到，我会尽快阅读，谢谢！

Mac OS X and openssl 3

2022-04-23 Thread The Doctor via openssl-users

Just wondering if Apple OS is compatible with OPenssl 3 .

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b  
If challenge is our enemy, we won't have friends. -unknown Beware 
https://mindspring.com

Re: CA upgrade in several aspects

2022-05-13 Thread egoitz--- via openssl-users

Hi Mark! 

Thank you so much for answering. 

I think that the process of issuing a new ca cert (for replacing the old
ca cert with a new a certificate with more bits and better signing
algorithms) should be : 

- Generate in the own ca a new ca cert. 

- Replace in openssl.conf which ca cert and ca keys should be used to
issue certificates. 

- Then reissue all certificates. 

Am I wrong?. 

If I apply the following changes in openssl.conf from the openssl.conf I
attached in my previous email, I suppose all should be fine then?. The
commented changes are : 

- Added the line : "signer_digest  = sha256" 

- Modified the line : "digests= md5, sha1" by "digests =
sha1, sha256, sha384, sha512" 

- Added the line : "ess_cert_id_alg= sha1" 

Best regards,

El 2022-05-12 18:21, Mark Hack escribió:

> NIST-800-131a deprecated SHA1 signatures in January of 2013 along with 
> RSA1024 bit keys. You should be issuing certificates with at least RSA2048 
> with SHA2 signatures, and preferably at least RSA3072 with SHA-384 signatures 
> and if you are re-issuing CA certs more bits is better. 
> 
> Nothing was said about CA certificates with SHA1 signatures and some 
> implementations will now reject these as non-compliant even if they were 
> issued before 2013. 
> 
> On Thu, 2022-05-12 at 17:40 +0200, egoitz--- via openssl-users wrote: 
> 
> Please ignore the line below I said regards in my previous mail... it's there 
> by error... 
> 
> cheers!
> 
> El 2022-05-12 17:38, ego...@ramattack.net escribió: 
> 
> Good afternoon, 
> 
> I'm running a CA, for generating the certificates for the backup clients of 
> my network and for the backup servers too. The certificates are used for 
> encrypting the backups stored in the servers and too, for comunicating over 
> TLS between severs and clients. 
> 
> This CA has some years now and the certificates I generate for new clients, 
> are not working (directly) in new machines. The reason for that is that new 
> operating systems, are requiring stronger signing algorithms. When you try to 
> start the service using that certificates (bacula file daemon) in a fresh new 
> Debian for instance, systemd throws the following error : 
> 
> _OPENSSL.C:68 ERROR LOADING CERTIFICATE FILE: ERR=ERROR:140AB18E:SSL 
> ROUTINES:SSL_CTX_USE_CERTIFICATE:CA MD TOO WEAK_ 
> 
> I know you can fix that with the following change in openssl.conf : 
> 
> _CIPHERSTRING = DEFAULT@SECLEVEL=2_ 
> 
> _CIPHERSTRING = DEFAULT@SECLEVEL=1_ 
> 
> But this last way, does not convince me... so I have started debugging what 
> exactly was causing the the problem. I saw, that sha1 is not allowed as a 
> signing valid algorithm for SECLEVEL 2. So, I tried moving the CA to a more 
> recent testing machine (with a newer OpenSSL 1.1.1l-freebsd), and I modified 
> too in the openssl.conf of the CA (The openssl.conf existing in the CA dir 
> for generating certs and so...) : 
> 
> I have attached the old version. The new using version in the testing 
> machine, is the old one plus the below changes : 
> 
> - Added the line : "signer_digest  = sha256" 
> 
> - Modified the line : "digests= md5, sha1" by "digests = 
> sha1, sha256, sha384, sha512" 
> 
> - Added the line : "ess_cert_id_alg= sha1" 
> 
> Now... I have generated a new certificate by following the normal 
> procedure... generate the key and csr... later sing new cert... etc etc. 
> 
> This new generated certificate (signed with sha256WithRSAEncryption 
> algorithm), has worked with a newer version of the Bacula client and in a 
> almost new Debian system. So it seems, just by generating new certificates, 
> using them in that new machines, with a newer os and keeping the old ca 
> certificate, at least the service has started. We have too, another master 
> public key for encrypting content (which is an oldly generated certificate 
> signed with sha1WithRSAEncryption) that we keep in case a customer looses 
> it's keys for avoiding a possible disaster. 
> 
> I was wondering if some sort of problem could exist, by using those old two 
> certificates (the master public key and the old ca certifcate) with the new 
> generated certificate. 
> 
> Now, that I have that CA, for whose purpose seems to be working, I have 
> started thinking... some more... I have noticed that the CA certificate will 
> expire in 2024. I assume that what I would have to do before that CA cert 
> expires could be : 
> 
> - Generate a second ca cert for the CA. 
> 
> - Change the ca certificate to be used (for signing and issuing new certs) in 
> openssl.conf : 
> 
> _CERTIFICATE= $DIR/CACERT-NEW.PEM

CA upgrade in several aspects

2022-05-12 Thread egoitz--- via openssl-users

Good afternoon,

I'm running a CA, for generating the certificates for the backup clients
of my network and for the backup servers too. The certificates are used
for encrypting the backups stored in the servers and too, for
comunicating over TLS between severs and clients.

This CA has some years now and the certificates I generate for new
clients, are not working (directly) in new machines. The reason for that
is that new operating systems, are requiring stronger signing
algorithms. When you try to start the service using that certificates
(bacula file daemon) in a fresh new Debian for instance, systemd throws
the following error :

_OPENSSL.C:68 ERROR LOADING CERTIFICATE FILE: ERR=ERROR:140AB18E:SSL
ROUTINES:SSL_CTX_USE_CERTIFICATE:CA MD TOO WEAK_

I know you can fix that with the following change in openssl.conf :

_CIPHERSTRING = DEFAULT@SECLEVEL=2_

_CIPHERSTRING = DEFAULT@SECLEVEL=1_

But this last way, does not convince me... so I have started debugging
what exactly was causing the the problem. I saw, that sha1 is not
allowed as a signing valid algorithm for SECLEVEL 2. So, I tried moving
the CA to a more recent testing machine (with a newer OpenSSL
1.1.1l-freebsd), and I modified too in the openssl.conf of the CA (The
openssl.conf existing in the CA dir for generating certs and so...) :

I have attached the old version. The new using version in the testing
machine, is the old one plus the below changes :

- Added the line : "signer_digest = sha256"

- Modified the line : "digests= md5, sha1" by "digests =
sha1, sha256, sha384, sha512"

- Added the line : "ess_cert_id_alg= sha1"

Now... I have generated a new certificate by following the normal
procedure... generate the key and csr... later sing new cert... etc
etc.

This new generated certificate (signed with sha256WithRSAEncryption
algorithm), has worked with a newer version of the Bacula client and in
a almost new Debian system. So it seems, just by generating new
certificates, using them in that new machines, with a newer os and
keeping the old ca certificate, at least the service has started. We
have too, another master public key for encrypting content (which is an
oldly generated certificate signed with sha1WithRSAEncryption) that we
keep in case a customer looses it's keys for avoiding a possible
disaster.

I was wondering if some sort of problem could exist, by using those old
two certificates (the master public key and the old ca certifcate) with
the new generated certificate.

Now, that I have that CA, for whose purpose seems to be working, I have
started thinking... some more... I have noticed that the CA certificate
will expire in 2024. I assume that what I would have to do before that
CA cert expires could be :

- Generate a second ca cert for the CA.

- Change the ca certificate to be used (for signing and issuing new
certs) in openssl.conf :

_CERTIFICATE= $DIR/CACERT-NEW.PEM # THE CA CERTIFICATE_

- Sign again all the certificates in the CA...

- Change, all certificates in the CA (except the own ca cert which is
already changed).

- Finally replace in each servers and clients certs.

Is this a correct procedure for upgrading a CA?. I assume it can be
correct. Isn't it?. I think this procedure shouldn't break nothing
related to serials of certificates and so in the own ca. Am I wrong?.

Best regards,

+are causing to set a special config in /etc/ssl/openssl.conf saying : "# $FreeBSD: release/10.0.0/crypto/openssl/apps/openssl.cnf 238405 2012-07-12
19:30:53Z jkim $
#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#

# This definition stops the following lines choking if HOME isn't
# defined.
HOME= .
RANDFILE= $ENV::HOME/.rnd

# Extra OBJECT IDENTIFIER info:
#oid_file = $ENV::HOME/.oid
oid_section = new_oids

# To use this configuration file with the "-extfile" option of the
# "openssl x509" utility, name here the section containing the
# X.509v3 extensions to use:
# extensions=
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)

[ new_oids ]

# We can add new OIDs in here for use by 'ca', 'req' and 'ts'.
# Add a simple OID like this:
# testoid1=1.2.3.4
# Or use config file substitution like this:
# testoid2=${testoid1}.5.6

< 1 2 3 4 5 6 7 8 9 10 >

401 - 500 of 1653 matches

Mail list logo