On 03/04/2016 11:08 PM, Jan Just Keijser wrote: > Hi, > > On 04/03/16 14:24, Arne Schwabe wrote: > the more I think about it, the more I think that what you are trying to > achieve ought not to work: > > your current situation is this: > - clients are equipped with a 1024bit CA cert; the server certificate (chain) > must be signed using this end-entity CA cert for the client to trust the > server > - the server supplies this 1024bit CA cert, as well as a cross-signed 4096bit > CA cert and a server cert. > - The client will never "accept" the 4K CA cert as the new end-entity, as > that is not configured in the config file.
This is correct, except that server doesn't send CA. > > *but* > anything signed using a 1K cert should be considered insecure, as it's > feasible nowadays to brute-force generate a key that will match that > certificate. That > means that an attacker can grab your 1K CA cert, generate a new CA key for > it, then generate new server cert (or even a 4K cross-signed CA cert) and > lure an > unsuspecting client to the server - your shiny new cross-signed CA cert will > not prevent this. This is also correct. > > The only way to prevent this from happening is by getting the clients to stop > trusting/using the 1K CA cert - thus, you must alter the client-side > configuration for this, painstaking as it is... This is only to easily move to a new CA. New clients will get configuration files with new 4096 bit CA, old clients would update their configuration files in 2 months. I'd like both old and new clients to be able to connect to the server without any hassle. Then, in 2 months, when all clients use 4096 bit CA, I'll remove old chain from server. > > > JJK >
signature.asc
Description: OpenPGP digital signature
