James Feist wrote: > I think the original motivation of 10 years was something above the average > support cycle of a server, so on first boot the user has something they can > use to login to the server with. That's not a crazy consideration to me. > That being said, if the browser wont let you > in, that is obviously more important. 30 days seems a bit too strict > considering shipping / unpacking times make it likely you'll have an expired > certificate upon arrival. But if we can't come to an agreement, we can always > make this configurable. 1) it would be good to clarify what browsers are really going to do. 2) it won't apply to CURL, etc. which might be used to onboard a system automatically. 3) you can't make it configurable, because you can't configure it if you can't connect :-) 825 days (27 months, so 2yr plus some wiggle room) is definitely what they are going to for built-in trust anchors. I'm not sure if this will apply to trust anchors that are loaded into browsers by end users, or if that configuration will somehow be attached to the trust anchor. So, if 825 days is a good default, I'd make it 820 days, and after 410 days, I'd have the self-signed certificate resigned, but not generate a new private key. This allows for mgmt stations to pin the public key of the BMC, ignoring the actual certificate contents. I will try to send a patch to do this. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [