4 ms·

There is some argument for this kind of certificate pinning (though I'm honestly not sold on the idea), but I think that this example is a further argument for

by cyphar 7y ago

There is some argument for this kind of certificate pinning (though I'm honestly not sold on the idea), but I think that this example is a further argument for scriptable certificate renewal. Most ACME clients allow you to run scripts after the certificate is renewed, so you could (in principle) trigger a script that does this Apple-specific verification process for you (maybe you could even trigger the "verify" button click by messing around with cURL -- though it'd be pretty annoying for there to be no API for this process). By manually getting 2-year certificates you're setting yourself up to forget part of the renewal process. This was the main argument behind Let's Encrypt having such short expiration windows -- it encourages people to script their entire deployments.

maxgashkov 7y ago
> maybe you could even trigger the "verify" button click by messing around with cURL Good luck with that—some time ago Apple locked down pretty much everything related to developer accounts with 2FA requirement that, of course, works on their proprietary platform via sending codes to logged in Apple devices. Maybe you can snatch it via some Automator kung-fu but I seriously doubt that.
wbond 7y ago
I think this is an argument that while a certain group of server administrators and security professionals love ACME, it still has a number of kinks to work out. In my case I’m not really setting myself up to forget about the renewal process as I have a script to generate the key and CSR and an ansible playbook to update the cert once sent to me. Certificate vendors are more than happy to email you to remind you of an upcoming renewal, in just the same way Let’s Encrypt does. On a side note, trying to script out the proper setup/migration of Let’s Encrypt is WAY more involved and fraught with mistakes than a simple certificate upload. The failure case is that the initial certificate issuance succeeds but since the initial setup needs to happen before SSL is configured and working with Nginx, you can’t use the same config before and after the initial setup. Thus you need to have two separate Nginx configs and switch them, or you have to use standalone for the initial issuance and webroot for renewals. Both of these are far easier to mess up than uploading a certificate. I’ve set up more than 10 different servers with Let’s Encrypt and I don’t think a single one has just worked. I think in every case something got messed up along the way, and you only find out about it 70 days later with the renewal email, IF you are the admin email on the LE account. Don’t get me wrong, I think there are great things about Let’s Encrypt, but it has plenty of thorns to deal with. I’m glad we haven’t all been forced into three month renewals by the CAB forum (since the certificate vendors have a say and they got feedback from customers before agreeing). I am fairly annoyed that Apple decided to unilaterally change the rules when they were already part of an organization that deals with this topic. I can only imagine browser vendors moving forward will have little to no concern for site/server administrators and how their changes are affecting things. As it stands now, we are at 400 day certificate lifetime, which means a bad actor can only impersonate for a year, in the name of revocation being performance prohibitive. This is effectively the same as three years from a users perspective. The only meaningful change would be a lifetime of something like a week or a day, but I shudder to think of all the ways that will fail spectacularly.

by cyphar 7y ago

maxgashkov 7y ago

> maybe you could even trigger the "verify" button click by messing around with cURL Good luck with that—some time ago Apple locked down pretty much everything related to developer accounts with 2FA requirement that, of course, works on their proprietary platform via sending codes to logged in Apple devices. Maybe you can snatch it via some Automator kung-fu but I seriously doubt that.

wbond 7y ago

I think this is an argument that while a certain group of server administrators and security professionals love ACME, it still has a number of kinks to work out. In my case I’m not really setting myself up to forget about the renewal process as I have a script to generate the key and CSR and an ansible playbook to update the cert once sent to me. Certificate vendors are more than happy to email you to remind you of an upcoming renewal, in just the same way Let’s Encrypt does. On a side note, trying to script out the proper setup/migration of Let’s Encrypt is WAY more involved and fraught with mistakes than a simple certificate upload. The failure case is that the initial certificate issuance succeeds but since the initial setup needs to happen before SSL is configured and working with Nginx, you can’t use the same config before and after the initial setup. Thus you need to have two separate Nginx configs and switch them, or you have to use standalone for the initial issuance and webroot for renewals. Both of these are far easier to mess up than uploading a certificate. I’ve set up more than 10 different servers with Let’s Encrypt and I don’t think a single one has just worked. I think in every case something got messed up along the way, and you only find out about it 70 days later with the renewal email, IF you are the admin email on the LE account. Don’t get me wrong, I think there are great things about Let’s Encrypt, but it has plenty of thorns to deal with. I’m glad we haven’t all been forced into three month renewals by the CAB forum (since the certificate vendors have a say and they got feedback from customers before agreeing). I am fairly annoyed that Apple decided to unilaterally change the rules when they were already part of an organization that deals with this topic. I can only imagine browser vendors moving forward will have little to no concern for site/server administrators and how their changes are affecting things. As it stands now, we are at 400 day certificate lifetime, which means a bad actor can only impersonate for a year, in the name of revocation being performance prohibitive. This is effectively the same as three years from a users perspective. The only meaningful change would be a lifetime of something like a week or a day, but I shudder to think of all the ways that will fail spectacularly.