141–150 of 154 posts
I have never really wanted to go "serverless" until today. TIL that I can buy a cert that expires in a year that is signed by a root certificate that expires sooner. Still not sure WHY this is the case, but this is definitely the case.
We had to get an entirely new certificate to resolve this. We had recently migrated our docker images to be based on Amazon Linux 2, and low a behold, there was no easy way we found to upgrade to the required version of OpenSSL on Amazon Linux 2. Was easier to just upgrade our certificates
Everything is fine with PKI and SSL certificates. It was a bug in OpenSSL 1.0.1 / 1.0.2 in dealing with two times cross-signed root CA. It is fixed in 1.1.1, but these older versions are still default on RHEL6/RHEL7/Centos6/Centos7 and even Ubuntu16.04. I think a large portion of online communications have been affected today.
This one bit me today and abruptly ended my day at the beach. The certificate reseller advised my customer that it was okay to include the cross-signing cert in the chain, because browsers will automatically ignore it once it expires, and use the Comodo CA root instead. And that was true for browsers I guess. But my customer also has about 100 machines in the field that use cURL to access their HTTPS API endpoint. cU…
Earlier quoted context omitted.
> You can authenticate outside of the insecure channel. There is a real world outside of the internet. Exactly, and you can look at how much of a failure PGP has been to see how successful that approach is. > Why is it that, in practice, the only certificates an end user's "CA" can sign are the end user's server certificates? CAs can sign any X.509 certificate. They only authenticate domain control or business owners…
"CAs can sign any X.509 certificate." Please explain how a user who creates a CA pem file with openssl can sign the certificate from example.com. Not a faked up certificate for example.com but the real one the owner of the example.com domain name got from Digicert.
Earlier quoted context omitted.
Unfortunately, given crypto algo evolution and Moore's Law, the reverse is more likely true. Though that would be a neat hack.
I don't understand how this is relevant. We're talking about a deterministic timeout, based on the diff between cert exp date and current date. If Chrome added e.g. a 20 second slowdown to connect to the page for every user in the world one day after the cert expired, surely there would be some users who would ping the company that the site is unbearably slow (on social media, by email, whatever). Or someone in the c…
Of course a specifically-implemented timeout might be incorporated. That faces the challenge of bad actors (or incompetent / unaware ones) bypassing such a mechanism.
Incorporating the cost into the algorithm itself (say; requiring, more rounds based on time since first release, according to a mandatory and well-estabished protocol, just off the top of my head, with both client and server agreeing on minimum required rounds) might work.
Earlier quoted context omitted.
"CAs can sign any X.509 certificate." Please explain how a user who creates a CA pem file with openssl can sign the certificate from example.com. Not a faked up certificate for example.com but the real one the owner of the example.com domain name got from Digicert.
This is the no true Scotsman fallacy. If I told you how to sign a certificate with your own CA, you'd tell me the result was "faked up".
Thankfully our uptime services spotted this earlier in the week. I'm terrible with certs, so no idea why a cert we brought this year is even using this root ca. To be honest, things like let's encrypt or cloud services which manage ssl is a great help
Earlier quoted context omitted.
This is the no true Scotsman fallacy. If I told you how to sign a certificate with your own CA, you'd tell me the result was "faked up".
If the owner of the example.com website creates the CSR and send its to the user, then the result is not "faked up". I use the term "faked up" only to refer to a scenario where the user generates a CSR for a domain name that is not under her control.
openssl x509 -req -days 365 -in example.com.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out example.com.crtEarlier quoted context omitted.
My experience with commercial CA is that they set the expiry exactly 1 year from creation. Doesn't matter if it's a week end or a holiday.
Generally that’s for Server certs, Roots and Intermediates will be multiple years from what I’ve seen. Roots in particular 10+ years.