Some User had leaked the private key un-password protected in the internet, so our certificated had GlobalSign had revoke our cert. Re-issuing is pending.

[Upinel]

Please do not store the private key in any un-password protected place which can access in the internet.

[Upinel]

The domain will still pointing to your localhost so your development work should be still working. just maybe some error message. HTTP will works as always. I am actively contacting GlobalSign to see if it is possible to whitelist our domain name. I will keep everyone posted here.

[Upinel]

We will use a short-term certificate at the moment. The good news is it can reduce our annual fee; the bad news is we need to renew the certificate every 3 months. If this issue continues, we might need to develop a new system to issue individual certificates to every user, but that means registration will become necessary, and I really don't want to. It will also incur development costs, and we might need your donation.

[marchenko1985]

oh my gosh

really sorry for that, I do believe I am not only one who did that, but still want to write that, just to give you some feedback - project and idea are awesome, indeed helped a lot and from time to time, when https is required almost always it is easier to use localhost.direct rather than fight with cert-manager, let's encrypt, you name it

and each time, personally I want to write some notes, so hopefully next time it will be easier, and notes are publicly available and indeed have keys

my thinking was something like - ok, it is already publicly available, probably it should not be a problem

but now I realize there are 3rd parties watching for this 🤔

BTW I do like how you have changed the password 💪 it should naturally fix the problem but from what I see inside last archine file names are little bit unusual, not a huge deal, but to just let you know (may be private key name should also be something like please_do_not_share_me_otherwise_whole_localhost_direct_cert_may_be_revoked.key - no one will miss it ever

Once again sorry for messing with keys, and thank you for your idea and project

[Master-Hash]

https://crt.sh/?id=15227323293&opt=ocsp

I believe it was revoked again (?

[Upinel]

I believe so....
I think we need to develop a new portal to distribute different key for different emails address.

[wklaebe]

Then you can go the last step further: set up an ACME service like Lets Encrypt did, let the owners of the mail address create the private(!) key themselves and have them obtain their certificate via ACME.

[Upinel]

I am currently maintaining 5 sets of cert bundles, and assigning users to groups, so if one user does anything wrong, at least only the user in the same group will be affected. Donators will have the individual cert bundles so they will never be revoked by others’ fault.
But for the long run, yes, an automation system should solve this, but I need some time (and cost) to develop it.

[vadym-dudar]

Crappy replacement: Get a free 90-day Wildcard SSL from Lets Encrypt for YOUR domain and point its DNS to 127.0.0.1
Yeah, 4x smaller time, but better then nothing...

For example: https://sslfree.io/index.html (DNS check through TXT record)

If you know any other free wildcard services or acme-scripts - share please :)

[Upinel]

@vadym-dudar In fact, I totally agree with you. I personally don't think it’s difficult to obtain a public CA cert by yourself. I am using cert bot to automate Cert issuing as well.
But in the real world, if you are capable of obtaining your own cert, you won't use localhost.direct anyway from the beginning. (It’s just like a professional chef won't need to attend cooking lessons for beginners.) But there are people who need it for many reasons. Although I can't see what the users are developing. But if there are users who need it, it is the reason I should try to maintain this service as long as I can.

[Upinel]

Originally localhost.direct is using one year long wildcard cert, but it seems not feasible to do so anymore, at least at the moment. I don't know, just trying my best.

[marchenko1985]

Not everyone are experts, think of some frontend/ios/android developers for example, who are forced to have https to test some oidc flows or something like that - should they really jump into this rabbit hole 🤔

Projects like this must exist, they help a lot for many people

---

BTW: not sure if that helps, in work projects, we have dedicated github action that does create lets encryp certs by schedule every month and just pushes them to repository, under the hood, certs are verified via cloudflare api, so there is no need to have dedicated server/deployment, and as a result teammates know where they can find fresh certs

not perfect, not saying it worth looking, but may be will give some ideas, here is the snippet

ssl.yml

name: ssl

on:
  schedule:
    - cron: 0 8 1 * *
  workflow_dispatch:

env:
  CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}

jobs:
  ssl:
    timeout-minutes: 60
    runs-on: ubuntu-latest
    strategy:
      matrix:
        domain:
          # domains that have 127.0.0.1 A record
          - local.example.com
          - local.dev.example.com
    steps:
      - uses: actions/checkout@v3

      - name: cloudflare
        working-directory: ssl
        run: echo "dns_cloudflare_api_token = $CLOUDFLARE_API_TOKEN" > cloudflare.ini

      - name: certbot
        working-directory: ssl
        run: |
          docker run --rm \
            -v $PWD/cloudflare.ini:/cloudflare.ini \
            -v $PWD/letsencrypt:/etc/letsencrypt \
            certbot/dns-cloudflare certonly \
            --non-interactive \
            --domains ${{ matrix.domain }} \
            --dns-cloudflare \
            --dns-cloudflare-credentials /cloudflare.ini \
            --dns-cloudflare-propagation-seconds 60 \
            --agree-tos \
            --manual-public-ip-logging-ok \
            --preferred-challenges dns \
            -m username@example.com

      - name: chown
        working-directory: ssl
        # whoami - uid=1001 gid=121, user: runner, group: docker
        run: sudo chown -R 1001:121 letsencrypt

      - name: mv
        working-directory: ssl
        run: |
          mv letsencrypt/archive/${{ matrix.domain }}/fullchain1.pem ${{ matrix.domain }}.crt
          mv letsencrypt/archive/${{ matrix.domain }}/privkey1.pem ${{ matrix.domain }}.key

      # will store certs as built artifacts, commit part is removed to keep example small
      - name: artifacts
        uses: actions/upload-artifact@v4
        with:
          name: ${{ matrix.domain }}
          path: ssl/${{ matrix.domain }}.*

[Upinel]

@mac2000 That's really nice. Let me have a look at this. Currently, I am trying to use a Linux VPS to do the auto-cert bot and deploy to the download server. Let me see if GitHub Actions can make it smoother.

thxxx.

[Upinel]

hmmm, I think we found (one of) the reason why the key leaked.....lol
https://github.com/khcrysalis/Feather/blob/main/Shared/Server/localhost.direct.key
The key should be always password protected and never should be able to download directly.

[Upinel]

We are now reissuing the General Certificate Bundle without registration. However, we also offer the Cert Bundle by request and the Cert Bundle by Sponsorship for users who prefer not to share the certificate bundle with a large number of users. Let’s consider this issue closed for now.