AES-GCM
Hi, I have ciphertext encrypted in Java (using BouncyCastle - BC) with AES/GCM/NoPadding cipher. When I tried to decrypt it using OpenSSL in a 'c' program, the last call 'EVP_DecryptFinal_ex' fails. Somehow, ERR_print_errors_fp is not printing anything either. I do have the IV that is used in the Java's encrypt. However, I don't know where BC stores the tag in the ciphertext. I tried it at the beginning and the end of the ciphertext, but it didn't help. That is, I tried both of the following in the decrypt: |IV|TAG|Ciphertext |IV|Ciphertext|TAG Both didn't work. I tried both of the following as well with the same failure: EVP_aes_256_gcm EVP_aes_128_gcm I have run out of ideas what else to try. Any help would be greatly appreciated. Thanks in advance!
PKCS7_sign PKCS7_verify
Hey, guys. I have a small problem when using the PKCS7_sign and PKCS7_verify. Do not check the signature in the example, but is checked by using the openssl in command line. What am I doing wrong? code is attached. Dikarev Evgeniy pkcs7.tar.gz Description: application/gzip
Re: AES-GCM
On 05/27/2014 09:00 AM, Anant Rao wrote: Hi, I have ciphertext encrypted in Java (using BouncyCastle - BC) with AES/GCM/NoPadding cipher. When I tried to decrypt it using OpenSSL in a 'c' program, the last call 'EVP_DecryptFinal_ex' fails. Somehow, ERR_print_errors_fp is not printing anything either. I do have the IV that is used in the Java's encrypt. However, I don't know where BC stores the tag in the ciphertext. I tried it at the beginning and the end of the ciphertext, but it didn't help. That is, I tried both of the following in the decrypt: |IV|TAG|Ciphertext |IV|Ciphertext|TAG Both didn't work. I tried both of the following as well with the same failure: EVP_aes_256_gcm EVP_aes_128_gcm I have run out of ideas what else to try. Any help would be greatly appreciated. Thanks in advance! Have a look at https://www.openssl.org/docs/crypto/EVP_EncryptInit.html#GCM_Mode and at the example in 'openssl/demos/evp/aesgcm.c' of the current master branch (git://git.openssl.org/openssl.git). Regards Jens __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: suspending and continuing handshake
That is exactly what I thought first, to control it with BIOs. Unfortunately even if I give openssl the exact amount of bytes (not more) to be able to call the SNI callback, right after I return from the callback, openssl's own state machine goes into a state where it'll immediately say the: No shared cipher error. (so I don't have time to set the certificate later). That is why I think an internal code change is needed in openssl itself, to support this case. On Mon, May 26, 2014 at 11:40 PM, Kyle Hamilton aerow...@gmail.com wrote: I would think that this could be done by handling BIO communications yourself via memory BIOs, then sending the content of those BIOs over the network as appropriate. But, this does appear to be something that needs attention (given the reactive nature of SNI's specification long after the original API was developed). Ironically, this issue appears to make it much easier to write an MITM proxy than an opaque CONNECT-method proxy. -Kyle H On Mon, May 26, 2014 at 2:03 AM, DEXTER mydexte...@gmail.com wrote: Hi! In a proxying environment when the client connects to the proxy and it sends the SNI, you have to suspend the handshake with the client side, start the handshake on the serverside, get the certificate from the server, and send that certificate back to the client. This is only possible, if I can suspend the handshake procedure with the client, and continue when I have the certificate from the server. Right now openssl has some callbacks like the info and msg callbacks but you cannot return from it with let's say: SSL_HANDSHAKE_SUSPEND, or SSL_HANDSHAKE_INTERRUPT or something like that to be able to continue it later. So right now when you return from these and you don't have the certificate set you'll get the: No shared cipher error. The question is that will there'be some kind of way to suspend and continue the handshake? Or is there any other way to do this now? Thank you.
Re: suspending and continuing handshake
On Tue, May 27, 2014 at 12:03:05PM +0200, DEXTER wrote: That is exactly what I thought first, to control it with BIOs. Unfortunately even if I give openssl the exact amount of bytes (not more) to be able to call the SNI callback, right after I return from the callback, openssl's own state machine goes into a state where it'll immediately say the: No shared cipher error. (so I don't have time to set the certificate later). That is why I think an internal code change is needed in openssl itself, to support this case. You need to register default certificates of each type (RSA, DSA, ECDSA). Your SNI callback can switch to a fresh SSL_CTX with the appropriate MITM chain. If you're not doing MITM, you can't splice-in the server's chain anyway, since you don't have the private keys. For non-MITM proxies you should not an SSL API, as you're not terminating the SSL connection, just copying bytes back and forth. You'll just need some custom code to parse the client SSL HELLO and forward the connection accordingly. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: suspending and continuing handshake
What do you mean by I have to register default certificates? There are no default certificates. Before I know what certificate should I show to the client, I have to connect to the server to get the certificate from it (and then copy it, sign it, etc.). But before connecting to the server I need the SNI from the client to be able to connect to the server with SNI, so the server will show the proper cert. I can only set the certificate on the client side _after_ I got the sni, connected to the server(with the servername got from the client), got the certificate from the server, copied/signed/whatever and _then_ I can show this to the client. Do we misunderstand each other? Or am I only misunderstanding you? On Tue, May 27, 2014 at 2:46 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Tue, May 27, 2014 at 12:03:05PM +0200, DEXTER wrote: That is exactly what I thought first, to control it with BIOs. Unfortunately even if I give openssl the exact amount of bytes (not more) to be able to call the SNI callback, right after I return from the callback, openssl's own state machine goes into a state where it'll immediately say the: No shared cipher error. (so I don't have time to set the certificate later). That is why I think an internal code change is needed in openssl itself, to support this case. You need to register default certificates of each type (RSA, DSA, ECDSA). Your SNI callback can switch to a fresh SSL_CTX with the appropriate MITM chain. If you're not doing MITM, you can't splice-in the server's chain anyway, since you don't have the private keys. For non-MITM proxies you should not an SSL API, as you're not terminating the SSL connection, just copying bytes back and forth. You'll just need some custom code to parse the client SSL HELLO and forward the connection accordingly. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Verification of a certificate chain
Hi, I'm having a comprehension question on certificate verification. Having a trustchain like this: rootCA - subCA - subCA2 I can verify the subCA2 certificate using the command: openssl verify -CAfile rootCA.pem -untrusted subCA.pem subCA2.pem But, should't it also be possible to only verify the trust chain up to the subCA (i.e., if I fully trust this CA)? I would have expected that this will verify sucessfully: openssl verify -CAfile subCA.pem subCA2.pem Instead, I'm getting error 2 at 1 depth lookup:unable to get issuer certificate What do I miss? Thanks, Sven. -- PGP Key: https://0x80.io/pub/files/key.asc PGP Key Fingerprint: 2DF2 79CD 48DD 4D38 F0B6 7557 2E68 D557 49AA 1D99 Note: I'll be transitioning away from this key in the near future. signature.asc Description: OpenPGP digital signature
Re: suspending and continuing handshake
On Tue, May 27, 2014 at 03:20:22PM +0200, DEXTER wrote: Before I know what certificate should I show to the client, I have to connect to the server to get the certificate from it (and then copy it, sign it, etc.). So you are writing an MiTM proxy? When you sign the server certificate, do you replace the public key with a new public key whose private key you know? Do you instantiate the keypair in question in a new SSL_CTX that you associate with the SSL connection before returning from the SNI callback? You should also not forget to verify the upstream server's certificate and if verification fails, avoid signing it with a key that is trusted by the downstream client. But before connecting to the server I need the SNI from the client to be able to connect to the server with SNI, so the server will show the proper cert. That's fine, this just increases the latency of your SNI callback. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verification of a certificate chain
Hello, On Tue, May 27, 2014 15:44, Sven Reissmann wrote: Hi, I'm having a comprehension question on certificate verification. Having a trustchain like this: rootCA - subCA - subCA2 I can verify the subCA2 certificate using the command: openssl verify -CAfile rootCA.pem -untrusted subCA.pem subCA2.pem But, should't it also be possible to only verify the trust chain up to the subCA (i.e., if I fully trust this CA)? yes, then the rootCA is in your cert store, and OpenSSL must have access to this, implied by settings in openssl.cnf I would have expected that this will verify sucessfully: openssl verify -CAfile subCA.pem subCA2.pem Instead, I'm getting error 2 at 1 depth lookup:unable to get issuer certificate What do I miss? settings in openssl.cnf Walter __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: suspending and continuing handshake
On Tue, May 27, 2014 at 4:34 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Tue, May 27, 2014 at 03:20:22PM +0200, DEXTER wrote: So you are writing an MiTM proxy? Exactly. When you sign the server certificate, do you replace the public key with a new public key whose private key you know? Yep. Do you instantiate the keypair in question in a new SSL_CTX that you associate with the SSL connection before returning from the SNI callback? Not now. Right now I'm sort of hacking the connection. I mean, I store the client's data in a temp buffer, and when I got back to the client to continue the handshake with it, I threw away the original ssl connection, create a new one, and feed it from the temp buffer. But it is really a hacking and my state machine becomes very complicated because of this. You should also not forget to verify the upstream server's certificate and if verification fails, avoid signing it with a key that is trusted by the downstream client. Of course. But before connecting to the server I need the SNI from the client to be able to connect to the server with SNI, so the server will show the proper cert. That's fine, this just increases the latency of your SNI callback. You mean I should connect to the server from the SNI callback itself? That doesn't seem to be a very good idea. Openssl itself should have a mechanism built in it, so I could return from the SNI callback with something like SSL_TLSEXT_ERR_SUSPEND and later after I've set the appropriate certs (or changed the context) and called the SSL_do_handshake() again, it should continue where it left off. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verification of a certificate chain
On Tue, May 27, 2014 at 03:44:46PM +0200, Sven Reissmann wrote: But, should't it also be possible to only verify the trust chain up to the subCA (i.e., if I fully trust this CA)? I would have expected that this will verify sucessfully: OpenSSL versions prior to 1.0.2 require that all trusted certificates be self-signed. In 1.0.2 it is possible to use X509_verify_cert() with a trust anchor that is not self-signed, but I don't recall whether this is possible through the CLI. openssl verify -CAfile subCA.pem subCA2.pem Instead, I'm getting error 2 at 1 depth lookup:unable to get issuer certificate What do I miss? The chain construction code in X509_verify_cert() is currently limited to self-signed trust anchors. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verification of a certificate chain
On Tue, May 27, 2014, Viktor Dukhovni wrote: On Tue, May 27, 2014 at 03:44:46PM +0200, Sven Reissmann wrote: But, should't it also be possible to only verify the trust chain up to the subCA (i.e., if I fully trust this CA)? I would have expected that this will verify sucessfully: OpenSSL versions prior to 1.0.2 require that all trusted certificates be self-signed. In 1.0.2 it is possible to use X509_verify_cert() with a trust anchor that is not self-signed, but I don't recall whether this is possible through the CLI. It is with the -parial_chain option. 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: suspending and continuing handshake
On Tue, May 27, 2014 at 5:09 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Tue, May 27, 2014 at 04:57:39PM +0200, DEXTER wrote: Not now. Right now I'm sort of hacking the connection. I mean, I store the client's data in a temp buffer, and when I got back to the client to continue the handshake with it, I threw away the original ssl connection, create a new one, and feed it from the temp buffer. But it is really a hacking and my state machine becomes very complicated because of this. You're doing it wrong. Since there's no other way right now, it is the only way. Perhaps using OpenSSL to implement an MiTM proxy is not the right approach, but if you're using OpenSSL, then you must not return from the SNI callback before instantiating the appropriate connection-specific key-pair. That is exactly my problem, that you cannot return from the SNI callback before instantiating the appropriate connection-specific key-pair. Well, that's not how it works. Normally when OpenSSL returns with something like WANT_READ or WANT_WRITE, it is possible to later determine whether the preconditions for moving forward are satisfied. In this case you're asking OpenSSL to just wait for nothing in particular. That feature does not exist. That's the problem. I'm asking kindly the devs of openssl to make this feature exist. With the current API, you need something like threads or co-routines to suspend execution in the middle of the SNI callback and resume at that point once you have the required data. I want to avoid using threads/co-routines. Perhaps the OpenSSL state-machine is not sufficiently fine-grained (in terms of possible suspend/resume entry points) to make it easy to write an event-based MiTM proxy. That is why I'm saying that openssl should have a mechanism to support this case. Perhaps this is not the appropriate mailing list to discuss this, though noone answered my post on the openssl-devel list yet. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: suspending and continuing handshake
On Tue, May 27, 2014 at 05:28:31PM +0200, DEXTER wrote: On Tue, May 27, 2014 at 5:09 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Tue, May 27, 2014 at 04:57:39PM +0200, DEXTER wrote: Not now. Right now I'm sort of hacking the connection. I mean, I store the client's data in a temp buffer, and when I got back to the client to continue the handshake with it, I threw away the original ssl connection, create a new one, and feed it from the temp buffer. But it is really a hacking and my state machine becomes very complicated because of this. Well, replaying the client HELLO with a new SSL handle once you have the server certificate in hand is not so terrible. My comment about you're doing it wrong was meant to be about returning from the SNI callback and trying to use the original SSL state. Since SNI is sent in the original client HELLO, it is quite reasonable to store the complete HELLO and retry once you have the required key material. You can feed the HELLO back into a new SSL conneciton via an associated BIO_pair. So your approach is not especially inelegant. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: suspending and continuing handshake
On Tue, May 27, 2014 at 04:57:39PM +0200, DEXTER wrote: Do you instantiate the keypair in question in a new SSL_CTX that you associate with the SSL connection before returning from the SNI callback? Not now. Right now I'm sort of hacking the connection. I mean, I store the client's data in a temp buffer, and when I got back to the client to continue the handshake with it, I threw away the original ssl connection, create a new one, and feed it from the temp buffer. But it is really a hacking and my state machine becomes very complicated because of this. You're doing it wrong. That's fine, this just increases the latency of your SNI callback. You mean I should connect to the server from the SNI callback itself? That doesn't seem to be a very good idea. Perhaps using OpenSSL to implement an MiTM proxy is not the right approach, but if you're using OpenSSL, then you must not return from the SNI callback before instantiating the appropriate connection-specific key-pair. Openssl itself should have a mechanism built in it, so I could return from the SNI callback with something like SSL_TLSEXT_ERR_SUSPEND and later after I've set the appropriate certs (or changed the context) and called the SSL_do_handshake() again, it should continue where it left off. Well, that's not how it works. Normally when OpenSSL returns with something like WANT_READ or WANT_WRITE, it is possible to later determine whether the preconditions for moving forward are satisfied. In this case you're asking OpenSSL to just wait for nothing in particular. That feature does not exist. With the current API, you need something like threads or co-routines to suspend execution in the middle of the SNI callback and resume at that point once you have the required data. Perhaps the OpenSSL state-machine is not sufficiently fine-grained (in terms of possible suspend/resume entry points) to make it easy to write an event-based MiTM proxy. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verification of a certificate chain
Hi, thank you all for the clarification. As most users do not have OpenSSL 1.0.2, this doesn't seem to solve my problem. What I want to achieve is having a new rootCA, which replaces an oldRootCA, which I am using until now. So far the trust chain is: oldRoot - oldServerCert. What I thought should be possible is building this trust chain: oldRoot - newRoot - newSubCA - newServerCert As Users are trusting oldRoot, changing the oldServerCert to newServerCert is no problem. After some time, users would move trust to newRoot and I can disable oldRoot. This doesn't seem possible, if I understand your answers correct. Is there another/better/default way of smoothly changing a trust anchor? I.e. by cross-signing the newRoot by itself and the oldRoot? Thanks, Sven. -- PGP Key: https://0x80.io/pub/files/key.asc PGP Key Fingerprint: 2DF2 79CD 48DD 4D38 F0B6 7557 2E68 D557 49AA 1D99 Note: I'll be transitioning away from this key in the near future. On 05/27/2014 05:16 PM, Dr. Stephen Henson wrote: On Tue, May 27, 2014, Viktor Dukhovni wrote: On Tue, May 27, 2014 at 03:44:46PM +0200, Sven Reissmann wrote: But, should't it also be possible to only verify the trust chain up to the subCA (i.e., if I fully trust this CA)? I would have expected that this will verify sucessfully: OpenSSL versions prior to 1.0.2 require that all trusted certificates be self-signed. In 1.0.2 it is possible to use X509_verify_cert() with a trust anchor that is not self-signed, but I don't recall whether this is possible through the CLI. It is with the -parial_chain option. 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 signature.asc Description: OpenPGP digital signature
RE: Verification of a certificate chain
Hi Sven,
-Original Message-
From: Sven Reissmann
What I want to achieve is having a new rootCA, which replaces an
oldRootCA, which I am using until now.
So far the trust chain is: oldRoot - oldServerCert.
What I thought should be possible is building this trust chain:
oldRoot - newRoot - newSubCA - newServerCert
As Users are trusting oldRoot, changing the oldServerCert to
newServerCert is no problem. After some time, users would move trust to
newRoot and I can disable oldRoot.
This doesn't seem possible, if I understand your answers correct.
Is there another/better/default way of smoothly changing a trust anchor?
I.e. by cross-signing the newRoot by itself and the oldRoot?
Just add the new root-CA certificate to all relevant truststores. Afterwards
you can start issueing certificates that are trusted by all parties with
updated truststores.
HTH,
Patrick Eisenacher
:��IϮ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
Re: Verification of a certificate chain
The X.509-canonical way to do this is to have the old trust anchor sign a new certificate containing the new public key, using the same Issuer name and a different AuthorityKeyIdentifier. This is called key rollover, but it retains the security level of the old key (meaning, if the original trust anchor is a 1024-bit key, then when the original key is brute-forced it could sign an alternative rollover certificate). -Kyle H On Tue, May 27, 2014 at 8:58 AM, Sven Reissmann s...@0x80.io wrote: Hi, thank you all for the clarification. As most users do not have OpenSSL 1.0.2, this doesn't seem to solve my problem. What I want to achieve is having a new rootCA, which replaces an oldRootCA, which I am using until now. So far the trust chain is: oldRoot - oldServerCert. What I thought should be possible is building this trust chain: oldRoot - newRoot - newSubCA - newServerCert As Users are trusting oldRoot, changing the oldServerCert to newServerCert is no problem. After some time, users would move trust to newRoot and I can disable oldRoot. This doesn't seem possible, if I understand your answers correct. Is there another/better/default way of smoothly changing a trust anchor? I.e. by cross-signing the newRoot by itself and the oldRoot? Thanks, Sven. -- PGP Key: https://0x80.io/pub/files/key.asc PGP Key Fingerprint: 2DF2 79CD 48DD 4D38 F0B6 7557 2E68 D557 49AA 1D99 Note: I'll be transitioning away from this key in the near future. On 05/27/2014 05:16 PM, Dr. Stephen Henson wrote: On Tue, May 27, 2014, Viktor Dukhovni wrote: On Tue, May 27, 2014 at 03:44:46PM +0200, Sven Reissmann wrote: But, should't it also be possible to only verify the trust chain up to the subCA (i.e., if I fully trust this CA)? I would have expected that this will verify sucessfully: OpenSSL versions prior to 1.0.2 require that all trusted certificates be self-signed. In 1.0.2 it is possible to use X509_verify_cert() with a trust anchor that is not self-signed, but I don't recall whether this is possible through the CLI. It is with the -parial_chain option. 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
Donation from Smartisan Technology
I am pleased to announce that the OpenSSL project has received what is by far our largest donation to date, 100 RMB or roughly US$16, from Smartisan Technology (http://www.smartisan.com/). I was told that they understand the importance of open source projects like OpenSSL to many IT companies in the world and the security of the Internet, and also use OpenSSL extensively in developing their smartphone operating system and application software. I am further told that their CEO Yonghao Luo admires the idealism of the OpenSSL team and believes that such faith deserves to be supported and maintained. This donation is some pretty significant support :-) Thank you Smartisan Technology, and Mr. Yonghao Luo. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Donation from Smartisan Technology
On Tue, May 27, 2014 at 3:08 PM, Steve Marquess marqu...@opensslfoundation.com wrote: I am pleased to announce that the OpenSSL project has received what is by far our largest donation to date, 100 RMB or roughly US$16, from Smartisan Technology (http://www.smartisan.com/). I was told that they understand the importance of open source projects like OpenSSL to many IT companies in the world and the security of the Internet, and also use OpenSSL extensively in developing their smartphone operating system and application software. I am further told that their CEO Yonghao Luo admires the idealism of the OpenSSL team and believes that such faith deserves to be supported and maintained. This donation is some pretty significant support :-) Thank you Smartisan Technology, and Mr. Yonghao Luo. -Steve M. Whoa... Congratulations, guys. We all feel the same way. Dustin -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Verification of a certificate chain
From: owner-openssl-us...@openssl.org On Behalf Of Eisenacher, Patrick Sent: Tuesday, May 27, 2014 12:41 From: Sven Reissmann What I want to achieve is having a new rootCA, which replaces an oldRootCA, which I am using until now. So far the trust chain is: oldRoot - oldServerCert. What I thought should be possible is building this trust chain: oldRoot - newRoot - newSubCA - newServerCert As Users are trusting oldRoot, changing the oldServerCert to newServerCert is no problem. After some time, users would move trust to newRoot and I can disable oldRoot. This doesn't seem possible, if I understand your answers correct. Is there another/better/default way of smoothly changing a trust anchor? I.e. by cross-signing the newRoot by itself and the oldRoot? Just add the new root-CA certificate to all relevant truststores. Afterwards you can start issueing certificates that are trusted by all parties with updated truststores. If you can get (all) the clients to update, yes. Sometimes that's hard. Sometimes it's hard even *locating* the clients, especially programs. You shouldn't cross-sign the new root itself, then it isn't a true root and (more importantly) won't consistently be accepted as an anchor. What you can do, and in my experience real public CAs actually do, is: - create new root key, and new (selfsigned) root cert for it. - also create a 'bridge' cert for the new root key, and the new root DN if different (which it usually is, e.g. Joe's Clam, Oyster and Cert Emporium Gen3 supercedes Joe's Clam and Cert Shack Gen2), (cross)signed by the old root (thus with issuer and AKI if present identifying oldroot, but SKI same as newroot). - issue the subCA cert(s) with AKI keyid for the new root key or omitted, and issuer matching both newroot and bridge, but NOT using AKI issuerserial - have server(s) handshake send subCA and bridge certs, at least for a period of time. A stale client has only oldroot will chain bridge to oldroot and succeed as long as oldroot doesn't expire. A clever fresh client has newroot abd will chain subCA to newroot, ignoring bridge -- while a dumb client will ignore available newroot and insist on chaining bridge to oldroot. Every time I've looked (not systematically) major browsers and Java are clever, but OpenSSL (client/relier) through 1.0.1 is not. I know 1.0.2 will change verification but don't know about this particular point. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: PKCS7_sign PKCS7_verify
The third arg of PKCS7_verify (indata) should only be used for an ‘external’ or ‘detached’ signature where the PKCS#7 does not contain the data. In your case it should be null. Also note that the _BINARY flag isn’t actually used for “plain” PKCS#7, only for SMIME. And I don’t think it really works right for SMIME. Avoid it. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dikarev Evgeniy Sent: Tuesday, May 27, 2014 03:45 To: openssl-users@openssl.org Subject: PKCS7_sign PKCS7_verify Hey, guys. I have a small problem when using the PKCS7_sign and PKCS7_verify. Do not check the signature in the example, but is checked by using the openssl in command line. What am I doing wrong? code is attached. Dikarev Evgeniy
Re: PKCS7_sign PKCS7_verify
Dave, As I know the PKCS7_BINARY flag is used to prevent a binary data from translation to MIME format. It always leads to data corruption. I advise to use this flag when a binary data is to be signed. 2014-05-28 2:39 GMT+04:00 Dave Thompson dthomp...@prinpay.com: The third arg of PKCS7_verify (indata) should only be used for an ‘external’ or ‘detached’ signature where the PKCS#7 does not contain the data. In your case it should be null. Also note that the _BINARY flag isn’t actually used for “plain” PKCS#7, only for SMIME. And I don’t think it really works right for SMIME. Avoid it. *From:* owner-openssl-us...@openssl.org [mailto: owner-openssl-us...@openssl.org] *On Behalf Of *Dikarev Evgeniy *Sent:* Tuesday, May 27, 2014 03:45 *To:* openssl-users@openssl.org *Subject:* PKCS7_sign PKCS7_verify Hey, guys. I have a small problem when using the PKCS7_sign and PKCS7_verify. Do not check the signature in the example, but is checked by using the openssl in command line. What am I doing wrong? code is attached. Dikarev Evgeniy
