Re: [openssl-users] Certificate validating (openssl -verify ...) and interpreting messages
On 18/05/2016 21:38, Walter H. wrote: On 18.05.2016 21:10, Viktor Dukhovni wrote: On May 18, 2016, at 1:26 PM, Walter H.wrote: openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.trust.crt -trusted_first -untrusted /tmp/chain.pem /tmp/cert.pem /tmp/chain.pem contains a root certificate /tmp/cert.pem contains a certificate that was signed by this root certificate; I get the following output /tmp/cert.pem: CN = ..., O = ..., ST = ..., C = ... error 19 at 1 depth lookup:self signed certificate in certificate chain of couse the number 19 means 'self signed certificate in certificate chain' as shown here: https://www.openssl.org/docs/manmaster/apps/verify.html but what does the number 1 (at ... depth) say? It means that while constructing a chain, the immediate issue of the leaf certificate was an untrusted self-signed certificate. The leaf certificate has depth 1, its issuer has depth 0. Ah, ok; in case there had been a chain with 3 certificates 2 means the leaf certificate, 1 means the issuing intermediate and 0 means the self signed root? No, 0 is always the leaf, 1 is always the issuer of the leaf 2 is always the issuer of the issuer of the leaf etc. So for a chain with 3 certificates, 2 is the root. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Certificate validating (openssl -verify ...) and interpreting messages
On 18.05.2016 21:10, Viktor Dukhovni wrote: On May 18, 2016, at 1:26 PM, Walter H.wrote: openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.trust.crt -trusted_first -untrusted /tmp/chain.pem /tmp/cert.pem /tmp/chain.pem contains a root certificate /tmp/cert.pem contains a certificate that was signed by this root certificate; I get the following output /tmp/cert.pem: CN = ..., O = ..., ST = ..., C = ... error 19 at 1 depth lookup:self signed certificate in certificate chain of couse the number 19 means 'self signed certificate in certificate chain' as shown here: https://www.openssl.org/docs/manmaster/apps/verify.html but what does the number 1 (at ... depth) say? It means that while constructing a chain, the immediate issue of the leaf certificate was an untrusted self-signed certificate. The leaf certificate has depth 1, its issuer has depth 0. Ah, ok; in case there had been a chain with 3 certificates 2 means the leaf certificate, 1 means the issuing intermediate and 0 means the self signed root? Thanks, Walter smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Certificate validating (openssl -verify ...) and interpreting messages
> On May 18, 2016, at 1:26 PM, Walter H.wrote: > > openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.trust.crt -trusted_first > -untrusted /tmp/chain.pem /tmp/cert.pem > > /tmp/chain.pem contains a root certificate > /tmp/cert.pem contains a certificate that was signed by this root certificate; > > I get the following output > > /tmp/cert.pem: CN = ..., O = ..., ST = ..., C = ... > error 19 at 1 depth lookup:self signed certificate in certificate chain > > of couse the number 19 means 'self signed certificate in certificate chain' > as shown here: https://www.openssl.org/docs/manmaster/apps/verify.html > > but what does the number 1 (at ... depth) say? It means that while constructing a chain, the immediate issue of the leaf certificate was an untrusted self-signed certificate. The leaf certificate has depth 1, its issuer has depth 0. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Reload certificates?
On 18/05/2016 20:00, Jordan Brown wrote: On 5/18/2016 10:51 AM, Salz, Rich wrote: Would it be reasonable to have OpenSSL watch the metadata on the file or directory and, on change, discard cached certificates and, for a file, reload the file? Unlikely to happen :) Are you saying that because nobody is interested in doing the development work, or because there's some reason why it would be a bad idea? I am guessing this is because watching for file system metadata changes is very OS specific and far outside the small subset of OS functionality already abstracted by the OS portability layers inside OpenSSL. Perhaps a simpler solution would be if certificates cached from the "CApath" mechanism would not be reused beyond a time limit of e.g. 12 hours. Similarly, for any self-loading mechanism, cached CRLs should be reloaded at the earlier of e.g. 12 hours and their "Not After" time. Of cause mechanisms that load all the data (CAs, CRLs etc.) at program startup cannot do reloads because that would fail when chroot or other security mechanisms disable the relevant access permission shortly after program startup (to prevent a security-compromised process from accessing / changing data it is not supposed to change during normal operations). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Reload certificates?
On 18.05.2016 19:51, Salz, Rich wrote: Is there something I'm missing? Nope. From the description of SSL_CTX_load_verify_locations i would have expected that certificates loaded via the CApath mechanism are loaded anew for every verification process. If this is not the case an appropriate note in that description would be very nice. Ciao, Richard -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Reload certificates?
On 5/18/2016 10:51 AM, Salz, Rich wrote: >> Would it be reasonable to have OpenSSL watch the metadata on the file or >> directory and, on change, discard cached certificates and, for a file, >> reload the file? > Unlikely to happen :) Are you saying that because nobody is interested in doing the development work, or because there's some reason why it would be a bad idea? -- Jordan Brown, Oracle Solaris -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Reload certificates?
On 5/18/2016 10:52 AM, Scott Neugroschl wrote: > > I believe that’s specific to the servers in question. Often you can > “restart” a server by giving it a SIGHUP. I don’t know if slapd and > slurpd will respond in the way you want. > I'm thinking more of long-running client applications. Because the various software stacks with OpenSSL at their base can be loaded into any number of client applications, it would be best if we didn't have to track down all of the consumers and notify them that they needed to recreate their SSL contexts. (Plus there's the difficulty of getting those various consumers, some of which may be externally-sourced software, to accept such a request.) > > > *From:*openssl-users [mailto:openssl-users-boun...@openssl.org] *On > Behalf Of *Jordan Brown > *Sent:* Wednesday, May 18, 2016 10:44 AM > *To:* openssl-users@openssl.org > *Subject:* [openssl-users] Reload certificates? > > > > We have OpenSSL consumers (primarily but not exclusively OpenLDAP). > Some of them are long-running processes. > > We'd like to be able to update the list of trusted certificates and > have the changes take effect, without needing to restart those > long-running processes and preferably without needing to interact with > them in any way. > > It *looks* like the "file" style of certificate store is loaded once > only, at the time it's specified, and never reloaded again for the > life of a particular SSL context. Similarly, it looks like in the > "directory" style of certificate store once a particular certificate > has been loaded, it's never unloaded, even if the underlying file is > deleted. It looks like the only way to see changes (and especially > deletions) is to create a new SSL context. In addition to the > difficulty of getting middleware to do that, it seems like the > middleware would need to either watch the files and directories on its > own, or always create new SSL contexts for new connections, or > something else similarly intrusive. > > Is there something I'm missing? > > Would it be reasonable to have OpenSSL watch the metadata on the file > or directory and, on change, discard cached certificates and, for a > file, reload the file? > > -- > > Jordan Brown, Oracle Solaris > > > > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Reload certificates?
I believe that's specific to the servers in question. Often you can "restart" a server by giving it a SIGHUP. I don't know if slapd and slurpd will respond in the way you want. From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Jordan Brown Sent: Wednesday, May 18, 2016 10:44 AM To: openssl-users@openssl.org Subject: [openssl-users] Reload certificates? We have OpenSSL consumers (primarily but not exclusively OpenLDAP). Some of them are long-running processes. We'd like to be able to update the list of trusted certificates and have the changes take effect, without needing to restart those long-running processes and preferably without needing to interact with them in any way. It *looks* like the "file" style of certificate store is loaded once only, at the time it's specified, and never reloaded again for the life of a particular SSL context. Similarly, it looks like in the "directory" style of certificate store once a particular certificate has been loaded, it's never unloaded, even if the underlying file is deleted. It looks like the only way to see changes (and especially deletions) is to create a new SSL context. In addition to the difficulty of getting middleware to do that, it seems like the middleware would need to either watch the files and directories on its own, or always create new SSL contexts for new connections, or something else similarly intrusive. Is there something I'm missing? Would it be reasonable to have OpenSSL watch the metadata on the file or directory and, on change, discard cached certificates and, for a file, reload the file? -- Jordan Brown, Oracle Solaris -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Reload certificates?
> Is there something I'm missing? Nope. > Would it be reasonable to have OpenSSL watch the metadata on the file or > directory and, on change, discard cached certificates and, for a file, reload > the file? Unlikely to happen :) -- Jordan Brown, Oracle Solaris -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Reload certificates?
We have OpenSSL consumers (primarily but not exclusively OpenLDAP). Some of them are long-running processes. We'd like to be able to update the list of trusted certificates and have the changes take effect, without needing to restart those long-running processes and preferably without needing to interact with them in any way. It *looks* like the "file" style of certificate store is loaded once only, at the time it's specified, and never reloaded again for the life of a particular SSL context. Similarly, it looks like in the "directory" style of certificate store once a particular certificate has been loaded, it's never unloaded, even if the underlying file is deleted. It looks like the only way to see changes (and especially deletions) is to create a new SSL context. In addition to the difficulty of getting middleware to do that, it seems like the middleware would need to either watch the files and directories on its own, or always create new SSL contexts for new connections, or something else similarly intrusive. Is there something I'm missing? Would it be reasonable to have OpenSSL watch the metadata on the file or directory and, on change, discard cached certificates and, for a file, reload the file? -- Jordan Brown, Oracle Solaris -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Certificate validating (openssl -verify ...) and interpreting messages
Hello, when running this: openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.trust.crt -trusted_first -untrusted /tmp/chain.pem /tmp/cert.pem /tmp/chain.pem contains a root certificate /tmp/cert.pem contains a certificate that was signed by this root certificate; I get the following output /tmp/cert.pem: CN = ..., O = ..., ST = ..., C = ... error 19 at 1 depth lookup:self signed certificate in certificate chain of couse the number 19 means 'self signed certificate in certificate chain' as shown here: https://www.openssl.org/docs/manmaster/apps/verify.html but what does the number 1 (at ... depth) say? does this reference a certificate of the whole chain, if so, which one the root or the other one? Thanks for help; Greetings from Austria, Walter smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users