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 *danger*net 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 *danger*net 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.