TLS Client Certificate + Luci login Issues on Safari

I'm running into some issues logging in to Luci while using TLS client certs via Safari. It's all working rather nicely with Chrome (Mac), but on Safari (iOS, iPadOS, and the same Mac) I'm seeing issues logging in. Curiously, if I disable the server-side client cert configuration, log in, and then re-enable client certs, Luci continues to work as expected until the session expires -- so it's really just the login process that seems to break on Safari.

To be clear, I'm talking about using client certs to authenticate the TLS session only. I understand that there were some proposed patches to enable client certs as a login mechanism for Luci itself via rpcd, but I'm not sure what the current status of those are, and wasn't able to find any evidence of them actually landing in the source tree.

Interestingly, it doesn't seem to matter where in the chain I implement the TLS client cert logic. I've tried putting the logic in at nginx running on the openwrt device, and I've also tried putting the logic in haproxy running on a separate device in front of the openwrt device. I've even tried the latter with plaintext HTTP proxying out the back of haproxy into nginx to no avail. In all cases, Chrome works fine, and disabling client certs works fine in Safari as well.

Has anyone gotten Luci login over TLS with client certs working with Safari? Any special sauce or advice?

For posterity: Finally got this figured out. From what I can tell, Safari handles a 403 (Forbidden) response as pertaining to the client certificate, and thus tries to refresh the page after showing a client cert selection dialog to the user (on Mac). Luci's login page is displayed using a 403 response code.

I was able to work around this issue with haproxy using the following backend config:

    http-response set-status 200 if { status 403 }

It's a total hack, but it does the trick if reasonably scoped down. It'd be great to have a specific Luci login page path that can be used instead, so I may look into that. Better still, if Safari handles location headers correctly in this case (I haven't checked this), it'd be nice to redirect to such a page with a 200 response that can be properly displayed.

Issue filed.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.