[wbond]

It also means you have to automate things that are tied to your certificate lifetime. Apple Pay on the web requires you authenticate your server, and it uses your certificate serial num as proof you still own the server.

This means every three months you need to re-authenticate with Apple Pay. But there is no Acme client for authenticating with Apple Pay. So instead, I was having to re-authenticate something manually every 3 months. It involved logging into an Apple Developer account, downloading a PEM file, uploading to my server and then clicking a button in the Developer Account to check the file.

After doing that dance, I happily paid for 2 year certificates from RapidSSL. Now you can only buy one year certificates. I really hope the CAB isn’t successful in making those non-conforming and requiring shorter certs.

There are plenty of other environments where certificate automation is not possible. And honestly, I haven’t seen arguments as to how on-machine automation is more secure than requiring someone be involved in the process.

While I’m dreaming about improvements to the CA ecosystem, having some way to actually prove your are the company you claim would be amazing. Instead we are actively removing support for anything that tried to provide that…

[infogulch]

I'm not sure why you choose to see this as something that "can't be automated, so must use long-expiry certs" and not "apple fails to offer an api to perform an essential-to-automate task".

[wbond]

I see LE as generally trading low cost certs for expensive labor. It’s great when you have scale and need hundreds of certs.

I care more about making it easy for people to pay me than getting “free” certificates that cost me hundreds of dollars in labor costs.

Everyone talks about LE like it is perfect. I’ve just determined after using it at four different orgs that for smaller shops it tends to take more time/money to get it working than using long expiring certs deployed via an automation system.

Honestly, setting up even more automation, like you suggest Apple provide, would probably cost 5x in labor as being able to purchase 3 year certs for the next 12 years.

Automation is great when you have scale. In this case, I don’t. I tend to work at smaller companies, so I’ve never worked at an org big enough for the automation to pay off versus buying certs.

[infogulch]

> long expiring certs deployed via an automation system

If you're already automating it why stop halfway? I don't see your point.

> setting up even more automation ... would probably cost 5x in labor [than the cost of 3 year certs over 12 years].

(0. 3 year certs are going away for operational security reasons, but lets skip that for now.)

1. Are you sure it costs more in labor to automate? Are you factoring in: a) the opportunity cost of lost sales and customer dissatisfaction when the certs expire in prod? b) the time it takes to train new employees how to change the certs [which at the average turnover rate is paid at every cert change]? c) the recurring labor of finance and operations professionals and management expensing, accounting, reporting, and reviewing this irregular cost? d) the opportunity cost of avoiding setting up new https-enabled services because it's such a huge pita for the organization?

> Automation is great when you have scale.

2. Lets decompose your scale argument into "vertical" vs "horizontal" scale that is hopefully familiar to people provisioning infrastructure. Here, "vertical scale" is one company needing many certs. I agree that if your vertical scale is low (say 10 certs) then it may not be worth it to spend 200h of labor automating it by yourself. But automation can also be scaled "horizontally": if 100 companies need it they can amortize the labor cost of creating the automation between them and have plenty of hours left over to implement it. This is the central ethos of open source and the reason why it can work at all.

[tialaramex]

The reduction from 825 days to 1 year was instituted by Apple. The same people apparently forcing you to perform a manual step every time you replace the certificate.

Some people might look at that and conclude Apple is the problem, but you apparently decided it's "the CA ecosystem".

You can get proof you "are the company you claim" from CAs today, both OV and EV support that capability, but let me guess, Apple doesn't make any use of that information and so once again rather than spot where the problem is, you'll give Apple a free pass and blame everybody else.

Edited to add: As to "actively removing support for anything that tried to provide that… " EV doesn't do what people expect it to do. Maybe Apple knows whether they want to do business with the Ohio Funky Rabbit Pizza or the West Virginia Funky Rabbit Pizza, but the customer has no clue that those are even different companies, much less which is which, so the whole "Let's show the company name in the browser" doesn't achieve what its proponents wanted, not least because of course it'll turn out the "Funky Rabbit Pizza" restaurant actually in Coolville Ohio isn't run by either company but instead by Generic Food Holdings Inc. registered in New York, so with an EV cert their legitimate web site says "Generic Food Holdings Inc." which is even more suspicious, not less.

[JshWright]

Same issue with Okta if you want to use a custom domain. The only way to update the cert is via the web UI. It's a very frustrating oversight for a security related service...

[mdaniel]

The only _supported_ way ... if the browser can do it then a headless browser can do it

Did you open a ticket with Okta about that? I'd like to "me, too" and/or watch it, if so

[cute_boi]

headless browser is not the solution because ui may be very brittle. I always have to update my scrappers as people tend to change ui time to time.

Headless browser is only solution if upstream website don't change their ui and is very stable.

[mdaniel]

Sure, I doubt anyone who in the history of programming has even fired up a headless browser and thought "whew, I'm glad that work is finished, never to be touched again!"

But if it's a choice between _me_ (a) remembering every 3 months (b) then opening Chrome, authenticating, recalling the 18 clicks to get to the right settings screen, copy-pasting the 3 text fields, hitting submit, then logging out, or puppeteer doing that, there's absolutely no contest which of those is the better use of the company's series-A

---

Separately, I'm not sure where this falls on the HN etiquette guide, but the word is "scraper", because a "scrapper" is someone who collects and recycles metal: https://en.wikipedia.org/wiki/Scrapper

It's just a pet peeve of mine

[sleevi]

Do you have links to documentation on the Apple Pay requirement?

That sounds like Apple Pay is encouraging certificate pinning, and I suspect the Apple Root Program may have opinions to the contrary, given how it puts Apple users at risk to encourage pinning.