It's exactly the same excepting that no CA will sign your CSR (it'll be a self-signed certificate) and it's mostly superfluous because .onion is already providing end-to-end authenticate encryption.
Update to address comments and updated question:
There is no difference between the approach over tor or a dangernet site, you'd setup something like:
HiddenServiceDir /var/lib/tor/onion
HiddenServicePort 80 8080
HiddenServicePort 443 4433
Then configure your httpd to 301 to https://$hostname for any requests on 8080, just as you would for a dangernet website.
HidServAuth
If you're interested in client authentication then onion services can actually provide this, depending on your requirements and the size of your userbase, this would remove the requirement for a TLS stack on the server, clients setting TLS exceptions on their browser and installing a client-side TLS certificate.
To do this, you'd create a config like:
HiddenServiceDir /var/lib/tor/onion
HiddenServiceAuthorizeClient basic alice,bob,charlene,diane,edgar
HiddenServicePort 80 8080
HiddenServicePort 443 4433 # maybe irrelevant now?
Now you'd have a file in /var/lib/tor/onion/hostname that'd look like:
w27mu53v64gcpfru.onion Bq1T05QWOWhZG5/EN5oqfQ # client: alice
w27mu53v64gcpfru.onion n5I/fRj05aQG/2gqy1KC3g # client: bob
w27mu53v64gcpfru.onion rN+OCpC5ntgDGnCW0Quxpw # client: charlene
w27mu53v64gcpfru.onion 0K5Fd2zOiSo/Fc0t7YYgPQ # client: diane
w27mu53v64gcpfru.onion fu2LxUfA5QWxuC5PgEDSaQ # client: edgar
Now you give each user their "cookie", no one can access the hidden service without a valid "cookie". Alice, for example, would edit her torrc to include this line:
HidServAuth w27mu53v64gcpfru.onion Bq1T05QWOWhZG5/EN5oqfQ
Now Alice can use w27mu53v64gcpfru.onion as normal, and you'd know that the visitor was authorized because without their cookie they'd be unable to connect. If at any time you want to revoke access, you can remove Alice from the client list in the HiddenServiceAuthorizeClient line and reload tor to invalidate their cookie.
This is "basic" authorization for onion services, there is a further "stealth" but it does not scale anywhere near as well as "basic" because it published a descriptor for every client, each client uses a different .onion address to access the site too. It might be of interest if your userbase is small and high risk or high security. It also has some interesting extra security properties too, but it's going a bit beyond just replacing client-side TLS certificates.
tor2web
"tor2web" is an SSL MITM. You make an https request to tor2web, it makes an http request to the .onion, it proxies the response back to you. It would follow a 301 to an https address but it would fail when it encountered a self-signed, or otherwise "untrusted" TLS cert.
In your case this would present problems.
Firstly the client certificate, if used, would be served to tor2web and wouldn't be carried to your httpd, it would break client cert based authentication.
Secondly the HidServAuth wouldn't work, tor2web wouldn't be able to connect to the .onion as it wouldn't have the required authorization cookie.
Thirdly tor2web represents the security anti-pattern of "SSL Added and Removed Here :¬)", tor2web can, and must, see all of the activity performed through it. Infact facebooks onion service explicitly recommends against tor2web for this very reason, as you can see from this example request:
$ curl https://facebookcorewwwi.onion/ -H 'x-tor2web: 1'
Using Facebook over Tor2web (or other SSL-intermediaries) is a bad idea; by using such services you may expose your account details to the service provider and thereby risk interception or account theft. Please instead connect to Facebook in a normal way.
The x-tor2web header is the header that tor2web should send to indicate it's in use, but it doesn't have to send it. You can use this header to detect it's use and handle it appropriately.
