Re: OCSP response signature algorithm
I just got the OpenSSL ocsp tool option -rmd for specifying the digest algorithm in signature. This option is described at the below page, https://www.openssl.org/docs/manmaster/man1/openssl-ocsp.html Just out of curiosity, why isn't it at the following man page? https://www.openssl.org/docs/man1.1.1/man1/ocsp.html Though this option is supported by 1.1.1 series. On Mon, Jul 6, 2020 at 6:15 AM John Jiang wrote: > I just want to know how does OpenSSL implement RFC 6960 section 4.4.7.2 > Responder Signature Algorithm Selection. > > Could I take a OpenSSL responder to use SHA1withRSA signature algorithm > if the certificate is signed by this algorithm? > > [1] https://tools.ietf.org/html/rfc6960#section-4.4.7.2 > > On Sat, Jul 4, 2020 at 12:18 AM John Jiang > wrote: > >> Hi, >> I'm using OpenSSL 1.1.1. >> >> Can I configure the OCSP response signature algorithm? >> For a RSA issuer, it looks SHA256withRSA always be selected. >> >> PreferredSignatureAlgorithms extension in OCSP request may affect this >> algorithm in OpenSSL OCSP response. However, I prefer to use configuration. >> >> Thanks! >> >
Re: Question about SSL_key_update
On Thu, Jul 09, 2020 at 06:07:41PM +, Andreas Müller wrote: > Hi, > > I "inherited" our project to support/use TLSv1.3 from a late colleague. We > have a server written in C++ (Windows, Linux) > and clients (Windows, Linux, also written in C++ and also a Java client). > With Java, we use the native SSLSocket implementation, in Windows we use > Schannel and in Linux we use OpenSSL 1.1.1g. It seems to work and even > interoperability > did not show issues on some initial testing. > > I was curious about SSL_key_update. I read that other implementations use it > automatically, but with OpenSSL I have to > do it manually. So I added a > > int rc = SSL_key_update(ssl, SSL_KEY_UPDATE_REQUESTED); > > after 1000 I/O operations and looked what happened. > > I started with the Java client and it gets wrong application data in such a > situation. > > I tested with our Windows implementation (I know it may have > interoperability issues) and here I can see the > data I get from the server side and it is the same that I see on server side > in the callback, but the Windows > DecryptMessage function fails with SEC_E_INVALID_TOKEN. (I had expected > something like SEC_I_RENEGOTIATE to > get the information to put this record into InitializeSecurityContext.) > > The Linux client also aborts the connection, but here I have not yet more > details, but either the decryption fails > or the decrypted application data is wrong. Hopefully I can dig in there > next week. > > Here is what happens on server side: > > 1. I call SSL_key_update (see above) > 2. I call SSL_write with application data > 3. The write callback is invoked with this data: >DATA: 17 03 03 00 16 b6 02 b1 06 87 f2 30 0d 77 35 31 7a 5b 6d 3c c2 aa > 11 2c 32 95 a9 > 4. The write callback is invoked again with application data provided to > SSL_write: >DATA: 17 03 03 00 45 12 24 e5 66 36 2f 28 ea 62 2e 17 4c 62 f0 38 07 7f > 72 70 87 25 ba 45 ff cf f7 9f 0d 7d 48 ... > > I see these data arrive at the client side (Windows): >DATA: 17 03 03 00 16 b6 02 b1 06 87 f2 30 0d 77 35 31 7a 5b 6d 3c c2 aa > 11 2c 32 95 a9 > but get the error described above. In Java I get wrong application data, so > it seems to decrypt this as application > data?! > > I saw an additional call to SSL_do_handshake in the apps/s_server.c and > tried this, but it did not change anything. > > Is there anything else (except calling SSL_key_update) I have to take care of? Per the documentation (https://www.openssl.org/docs/man1.1.1/man3/SSL_key_update.html) it sounds like you're doing all you need to be. (In particular, you don't need to call SSL_do_handshake().) Probably the fastest way to track down what's happening is to get a full packet capture and keylog (e.g., with s_client -keylogfile path/to/log, then point wireshark at the trace+keys. -Ben
Re: Master fails tests (mentioning # TODO Currently not supported)
(I'm not an OpenSSL developer, but I know enough of development processes to explain what I see here. Actual OpenSSL developers should correct me if I'm wrong.) Most likely, yes this is currently expected. Since it's a dev branch, not a release branch, it's not expected to have everything internally consistent. Under test-driven development, one writes the tests for the behavior one expects to implement before one writes the code to implement that behavior. This is primarily to commit to the contract, and to ensure that the contract is fulfilled with the test data. A comment of "TODO Currently not supported" in the output of a failed test implies intent to support it in the next release, but the support hasn't yet been implemented. -Kyle H On Thu, Jul 9, 2020 at 10:22 AM Blumenthal, Uri - 0553 - MITLL wrote: > > MacOS 10.15.5, Xcode-11.5, current OpenSSL master (3.0 dev) > > Is this expected: > > > genpkey: Error setting ec_param_enc:explicit parameter: > C00D090F0100:error::digital envelope > routines:legacy_ctrl_str_to_param:command not > supported:crypto/evp/pmeth_lib.c:1011: > ../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC > -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' > -text => 1 > not ok 1 - genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' > (text) # TODO Currently not supported > # > -- > # Failed (TODO) test 'genpkey EC params Oakley-EC2N-3 with > ec_param_enc:'explicit' (text)' > # at test/recipes/15-test_genec.t line 37. > genpkey: Error setting ec_param_enc:explicit parameter: > C0CDBE160100:error::digital envelope > routines:legacy_ctrl_str_to_param:command not > supported:crypto/evp/pmeth_lib.c:1011: > ../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC > -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' > -outform PEM -out ecgen.Oakley-EC2N-3.explicit.pem => 1 > not ok 2 - genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' > (PEM) # TODO Currently not supported > # > -- > # Failed (TODO) test 'genpkey EC params Oakley-EC2N-3 with > ec_param_enc:'explicit' (PEM)' > # at test/recipes/15-test_genec.t line 37. > genpkey: Error setting ec_param_enc:explicit parameter: > C01D251B0100:error::digital envelope > routines:legacy_ctrl_str_to_param:command not > supported:crypto/evp/pmeth_lib.c:1011: > ../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC > -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' > -outform DER -out ecgen.Oakley-EC2N-3.explicit.der => 1 > not ok 3 - genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' > (DER) # TODO Currently not supported > # > -- > # Failed (TODO) test 'genpkey EC params Oakley-EC2N-3 with > ec_param_enc:'explicit' (DER)' > # at test/recipes/15-test_genec.t line 37. > genpkey: Error setting ec_param_enc:explicit parameter: > C07DD70A0100:error::digital envelope > routines:legacy_ctrl_str_to_param:command not > supported:crypto/evp/pmeth_lib.c:1011: > ../../util/wrap.pl ../../apps/openssl genpkey -algorithm EC -pkeyopt > 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -text => 1 > not ok 4 - genpkey EC key on Oakley-EC2N-3 with ec_param_enc:'explicit' > (text) # TODO Currently not supported > # > -- > # Failed (TODO) test 'genpkey EC key on Oakley-EC2N-3 with > ec_param_enc:'explicit' (text)' > # at test/recipes/15-test_genec.t line 37. > genpkey: Error setting ec_param_enc:explicit parameter: > C00D34120100:error::digital envelope > routines:legacy_ctrl_str_to_param:command not > supported:crypto/evp/pmeth_lib.c:1011: > ../../util/wrap.pl ../../apps/openssl genpkey -algorithm EC -pkeyopt > 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -outform > PEM -out ecgen.Oakley-EC2N-3.explicit.pem => 1 > not ok 5 - genpkey EC key on Oakley-EC2N-3 with ec_param_enc:'explicit' > (PEM) # TODO Currently not supported > # > -- > # Failed (TODO) test 'genpkey EC key on Oakley-EC2N-3 with > ec_param_enc:'explicit' (PEM)' > # at test/recipes/15-test_genec.t line 37. > genpkey: Error setting ec_param_enc:explicit parameter: > C0FDFE100100:error::digital envelope > routines:legacy_ctrl_str_to_param:command not > supported:crypto/evp/pmeth_lib.c:1011: > ../../util/wrap.pl ../../apps/openssl genpkey -algorithm EC -pkeyopt > 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -outform > DER -out ecgen.Oakley-EC2N-3.explicit.der => 1 > n
Question about SSL_key_update
Hi, I "inherited" our project to support/use TLSv1.3 from a late colleague. We have a server written in C++ (Windows, Linux) and clients (Windows, Linux, also written in C++ and also a Java client). With Java, we use the native SSLSocket implementation, in Windows we use Schannel and in Linux we use OpenSSL 1.1.1g. It seems to work and even interoperability did not show issues on some initial testing. I was curious about SSL_key_update. I read that other implementations use it automatically, but with OpenSSL I have to do it manually. So I added a int rc = SSL_key_update(ssl, SSL_KEY_UPDATE_REQUESTED); after 1000 I/O operations and looked what happened. I started with the Java client and it gets wrong application data in such a situation. I tested with our Windows implementation (I know it may have interoperability issues) and here I can see the data I get from the server side and it is the same that I see on server side in the callback, but the Windows DecryptMessage function fails with SEC_E_INVALID_TOKEN. (I had expected something like SEC_I_RENEGOTIATE to get the information to put this record into InitializeSecurityContext.) The Linux client also aborts the connection, but here I have not yet more details, but either the decryption fails or the decrypted application data is wrong. Hopefully I can dig in there next week. Here is what happens on server side: 1. I call SSL_key_update (see above) 2. I call SSL_write with application data 3. The write callback is invoked with this data: DATA: 17 03 03 00 16 b6 02 b1 06 87 f2 30 0d 77 35 31 7a 5b 6d 3c c2 aa 11 2c 32 95 a9 4. The write callback is invoked again with application data provided to SSL_write: DATA: 17 03 03 00 45 12 24 e5 66 36 2f 28 ea 62 2e 17 4c 62 f0 38 07 7f 72 70 87 25 ba 45 ff cf f7 9f 0d 7d 48 ... I see these data arrive at the client side (Windows): DATA: 17 03 03 00 16 b6 02 b1 06 87 f2 30 0d 77 35 31 7a 5b 6d 3c c2 aa 11 2c 32 95 a9 but get the error described above. In Java I get wrong application data, so it seems to decrypt this as application data?! I saw an additional call to SSL_do_handshake in the apps/s_server.c and tried this, but it did not change anything. Is there anything else (except calling SSL_key_update) I have to take care of? Did anyone use this successfully with a Java SSLSocket? (We currently use Azul 8 which has a backport of TLSv1.3, and Azul 11). Has anyone experience with Windows Schannel against OpenSSL? I still believe that I do something wrong, because the Linux client also fails. Any hints are appreciated. Regards, Andreas
Master fails tests (mentioning # TODO Currently not supported)
MacOS 10.15.5, Xcode-11.5, current OpenSSL master (3.0 dev) Is this expected: genpkey: Error setting ec_param_enc:explicit parameter: C00D090F0100:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: ../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -text => 1 not ok 1 - genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' (text) # TODO Currently not supported # -- # Failed (TODO) test 'genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' (text)' # at test/recipes/15-test_genec.t line 37. genpkey: Error setting ec_param_enc:explicit parameter: C0CDBE160100:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: ../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -outform PEM -out ecgen.Oakley-EC2N-3.explicit.pem => 1 not ok 2 - genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' (PEM) # TODO Currently not supported # -- # Failed (TODO) test 'genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' (PEM)' # at test/recipes/15-test_genec.t line 37. genpkey: Error setting ec_param_enc:explicit parameter: C01D251B0100:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: ../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -outform DER -out ecgen.Oakley-EC2N-3.explicit.der => 1 not ok 3 - genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' (DER) # TODO Currently not supported # -- # Failed (TODO) test 'genpkey EC params Oakley-EC2N-3 with ec_param_enc:'explicit' (DER)' # at test/recipes/15-test_genec.t line 37. genpkey: Error setting ec_param_enc:explicit parameter: C07DD70A0100:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: ../../util/wrap.pl ../../apps/openssl genpkey -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -text => 1 not ok 4 - genpkey EC key on Oakley-EC2N-3 with ec_param_enc:'explicit' (text) # TODO Currently not supported # -- # Failed (TODO) test 'genpkey EC key on Oakley-EC2N-3 with ec_param_enc:'explicit' (text)' # at test/recipes/15-test_genec.t line 37. genpkey: Error setting ec_param_enc:explicit parameter: C00D34120100:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: ../../util/wrap.pl ../../apps/openssl genpkey -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -outform PEM -out ecgen.Oakley-EC2N-3.explicit.pem => 1 not ok 5 - genpkey EC key on Oakley-EC2N-3 with ec_param_enc:'explicit' (PEM) # TODO Currently not supported # -- # Failed (TODO) test 'genpkey EC key on Oakley-EC2N-3 with ec_param_enc:'explicit' (PEM)' # at test/recipes/15-test_genec.t line 37. genpkey: Error setting ec_param_enc:explicit parameter: C0FDFE100100:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: ../../util/wrap.pl ../../apps/openssl genpkey -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-3' -pkeyopt 'ec_param_enc:explicit' -outform DER -out ecgen.Oakley-EC2N-3.explicit.der => 1 not ok 6 - genpkey EC key on Oakley-EC2N-3 with ec_param_enc:'explicit' (DER) # TODO Currently not supported # -- genpkey: Error setting ec_param_enc:explicit parameter: C09D39110100:error::digital envelope routines:legacy_ctrl_str_to_param:command not supported:crypto/evp/pmeth_lib.c:1011: ../../util/wrap.pl ../../apps/openssl genpkey -genparam -algorithm EC -pkeyopt 'ec_paramgen_curve:Oakley-EC2N-4' -pkeyopt 'ec_param_enc:explicit' -text => 1 not ok 13 - genpkey EC params Oakley-EC2N-4 with ec_param_enc:'explicit' (text) # TODO Currently not supported # -- # Failed (TODO) test 'genpkey EC params Oakley-EC2N-4 with ec_param_enc:'explicit' (text)' # at test/recipes/15-test_genec.t line 37. genpkey: Error setting ec_param_enc:explicit parameter: C04DD9180100:error::digital envelope routines:legacy_ctrl_str
creating certificate by code / problems to load via openssl x509 / pem format
Hello,
your first help in this project, helps much, but now some weeks later,
there is a new problem, and I cannot find any tipps via google.
For all the coding a have looked into the openssl examples.
I create a private key per code, the "openssl rsa -in
test_privatekey.pem -check" is fine
I create a certificate request per code, "openssl req -text -noout
-verify -in test_request.pem" is fine
I create a certifcate via this reqeust and store it with
"PEM_write_bio_X509(out, crt);" like the others. (some more code below)
Perhaps there is something wrong, but to detect this, I will use the
validation, but it cannot load the certificate to validate it:
>> openssl x509 -in test_certificate.pem -text
unable to load certificate
14018039872:error:0D07209B:asn1 encoding
routines:ASN1_get_object:too long:../crypto/asn1/asn1_lib.c:91:
14018039872:error:0D068066:asn1 encoding
routines:asn1_check_tlen:bad object header:../crypto/asn1/tasn_dec.c:1118:
14018039872:error:0D07803A:asn1 encoding
routines:asn1_item_embed_d2i:nested asn1
error:../crypto/asn1/tasn_dec.c:190:Type=ASN1_TIME
14018039872:error:0D08303A:asn1 encoding
routines:asn1_template_noexp_d2i:nested asn1
error:../crypto/asn1/tasn_dec.c:627:Field=notBefore, Type=X509_VAL
14018039872:error:0D08303A:asn1 encoding
routines:asn1_template_noexp_d2i:nested asn1
error:../crypto/asn1/tasn_dec.c:627:Field=validity, Type=X509_CINF
14018039872:error:0D08303A:asn1 encoding
routines:asn1_template_noexp_d2i:nested asn1
error:../crypto/asn1/tasn_dec.c:627:Field=cert_info, Type=X509
14018039872:error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1
lib:../crypto/pem/pem_oth.c:33:
Thanks for any help.
Best regards
Andreas
ErrorHandling should be added in a second step, first debug outputs (I
have deleted for here) says everything is created
X509* certificate_create(const X509_REQ* req)
{
//openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.crt -CAkey
ca.key -CAcreateserial -out server.crt
if ((crt = X509_new()) == NULL);
//xca = load_cert(CAfile, CAformat, "CA Certificate");
BIO *bio = NULL;
bio = BIO_new_file(CAfile, "r");
xca = PEM_read_bio_X509_AUX(bio, NULL, NULL, NULL);
BIO_free(bio);
upkey = X509_get0_pubkey(xca);
char CAkeyile[] = "ca.key";
int CAkeyformat = 5; //FORMAT_PEM
char passin[] = "xyz";
ENGINE *e = NULL;
EVP_PKEY * CApkey = NULL;
//CApkey = load_key(CAkeyfile, CAkeyformat, 0, passin, e, "CA Private
Key");
bio = BIO_new_file(CAkeyile, "r");
CApkey = PEM_read_bio_PrivateKey(bio, NULL, NULL, passin);
BIO_free(bio);
EVP_PKEY_copy_parameters(upkey, CApkey);
X509_STORE *ctx = NULL;
ctx = X509_STORE_new();
X509_STORE_CTX *xsc = NULL;
xsc = X509_STORE_CTX_new();
if (xsc == NULL || !X509_STORE_CTX_init(xsc, ctx, crt, NULL));
ASN1_INTEGER *serialno = NULL;
serialno = ASN1_INTEGER_new();
BIGNUM *btmp = NULL;
btmp = BN_new();
# define SERIAL_RAND_BITS 159
if (!BN_rand(btmp, SERIAL_RAND_BITS, BN_RAND_TOP_ANY,
BN_RAND_BOTTOM_ANY));
if (!BN_to_ASN1_INTEGER(btmp, serialno));
BN_free(btmp);
X509_STORE_CTX_set_cert(xsc, crt);
X509_STORE_CTX_set_flags(xsc, X509_V_FLAG_CHECK_SS_SIGNATURE);
if (!X509_check_private_key(xca, CApkey)) ;
if (!X509_set_issuer_name(crt, X509_get_subject_name(xca)));
if (!X509_set_serialNumber(crt, serialno));
int days = 365;
if (X509_time_adj_ex(X509_getm_notAfter(crt), days, 0, NULL) == NULL);
const char digestname[] = "sha256";
const EVP_MD* md = EVP_get_digestbyname(digestname);
EVP_MD_CTX *mctx = EVP_MD_CTX_new();
EVP_PKEY_CTX *pkctx = NULL;
EVP_DigestSignInit(mctx, &pkctx, md, NULL, CApkey); //ist CApkey hier
der richtige private Key? sollte eigentlich
int rv = (X509_sign_ctx(crt, mctx) > 0);
EVP_MD_CTX_free(mctx);
BIO *out = NULL;
out = BIO_new_file("test_certificate.pem", "w");
PEM_write_bio_X509(out, crt);
BIO_free_all(out);
...some more frees ...
return crt;
}
