Hacker News new | past | comments | ask | show | jobs | submit login

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.




Because the certificate authority paradigm is LITERALLY INSANE.


It’s the PKI paradigm that creates most of the insanity. Authentication is still an unsolved issue with PKI, there’s many ways that you can perform authentication, but all of the different approaches lead to one form of insanity or another. The CA system has its share of insanity, but it is the most successful PKI implementation in history, and by a long way.


PKI authentication is only insane when delegated to a third party. There is a built-in assumption within the CA system that no two parties can ever trust each other and intermediaries are always needed. A world of strangers who never learn anything about or get to know each other. It is either impractical or impossible for the first party to trust the second, using this system, without third party intervention. What reason is there that a website owner should never send a CSR to an end user who creates her own CA cert? Why are third parties the only ones permitted by websites to sign their certificates? Welcome to the world wide web of middlemen.


Well you can’t perform authentication over an insecure channel, and you can’t have a secure channel without authentication. Either you trust an authority, or you authenticate manually yourself. There’s a reason TLS uses the CA system, and not PGP.


You can authenticate outside of the insecure channel. There is a real world outside of the internet.

It is this "manual authentication" that the CA system does not account for. It is not an option. Why is it that, in practice, the only certificates an end user's "CA" can sign are the end user's server certificates?


> 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 ownership (via “EV”), though. CA certs also aren’t only used for TLS. You can get a code signing cert from a CA for instance.

You can write a very long list of perfectly valid complaints about the CA system. However it is undeniably the most successful PKI ever implemented, and not just by a little bit.

This isn’t because CAs are bad at what they do. It’s because there is absolutely no elegant solution to that problem. If you want to authenticate identity manually, then I wish you luck finding one or two other people to join you. If you want to securely communicate with people you don’t know personally, or who don’t know how to/can’t be bothered to maintain their own set of private keys, then you’re going to need to establish trust via a 3rd party authority.


"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".


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.


Fair enough. This command would do it then:

    openssl x509 -req -days 365 -in example.com.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out example.com.crt


As far as I understand your certificate is still valid but you need to remove the intermediate certificate from your bundle. That was the case for me anyway.


If your traffic comes from a browser you are fine with this but if you're coming from e.g. Curl you will find that you need to include an intermediate chain.

(The reason for the difference being that browser stay up to date, many old client systems do not.)

We ended up getting a new cert from a different provider.


You only need to remove the cert if you want to support buggy clients. If none of your clients are buggy, it will be fine to leave the expired cert in the chain.


That’s not the case — all certs are cross-signed with a newer root. The real problem is that certificate issuers have been giving people the old CA chain instead of the new one.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: