How to manually create acme.json from .crt and .key files?

I'm trying to get Souin up and running on my local dev machine, but I'm encountering a situation similar to the one outlined in this topic.

(I first tried setting it up as a plugin but was getting GoLang panics. :slightly_frowning_face:)

Anyway, I used mkcert to generate a local dev certificate, so I have no acme.json. Instead, my dynamic config looks like so...

tls:
   stores:
      default:
         defaultCertificate:
            certFile: /etc/traefik/ssl/all.localhost.crt
            keyFile: /etc/traefik/ssl/all.localhost.key
   certificates:
      - certFile: /etc/traefik/ssl/all.localhost.crt
        keyFile: /etc/traefik/ssl/all.localhost.key
        stores:
         - default

...which works just fine without Souin. But when I configure as described in the Souin docs and wget http://traefik from the Souin terminal, I get a certificate validation failure. I've tried manually reconstructing an acme.json file and pointing Souin to it, but without success. Maybe I'm not specifying the JSON values correctly.

Anyone have any idea how to proceed? I'm at my wit's end. :weary:

You need to

  1. define your custom TLS certs in a dynamic config file
  2. load the file with providers.file in static config
  3. enable plain TLS on entrypoint or router

When connecting with the browser (or curl/wget) to Traefik, you should get a warning and see your custom TLS cert.

So your service accessing Traefik needs to trust your local TLS cert.

Thanks for the reply, @bluepuma77, but everything works perfectly (and has been for years) without Souin in the loop.

As noted in the referenced post, Souin “fronts” Traefik when used as a container (instead of as a plugin), and therein lies the issue.

I’d prefer to use it as a plug-in, but then I get Go lang errors (which, according to the docs, is not uncommon because Traefik uses their own interpreter, which breaks things frequently).

So the issue boils down to how to properly configure TLS to appease Souin when it’s sitting in front of Traefik. I’m at a loss as to how to proceed.

Ok, so I learned that the certificate and key properties in acme.json are just the base64-encoded contents of the PEM files; but still no joy.

The acme.json is of the form...

{
    "ttCertResolver" : {
        "Account"      : {
            "Email"        : "email@domain.net",
            "Registration" : {
                "body" : {
                    "status"  : "valid",
                    "contact" : [
                        "mailto:email@domain.net"
                    ]
                },
                "uri"  : "(let's encrypt url)"
            },
            "PrivateKey"   : "(let's encrypt account key)",
            "KeyType"      : "4096"
        },
        "Certificates" : [
            {
                "domain"      : {
                    "main" : "my.domain.local"
                },
                "certificate" : "xxx",
                "key"         : "xxx",
                "Store"       : "default"
            }
        ]
    }
}

...so I base64-encoded the contents of the PEM files, but it didn't help. I have a feeling I should be using something other than Account as the ttCertResolver since I'm not actually using Let's Encrypt in my dev environment. Maybe what I'm trying to do just isn't possible.

What I get at the Souin terminal is a failure to verify the certificate...

/ # wget http://traefik
Connecting to traefik (172.20.0.100:80)
Connecting to traefik (172.20.0.100:443)
08FB89483B7F0000:error:0A000086:SSL routines:tls_post_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1889:
ssl_client: SSL_connect
wget: error getting response: Connection reset by peer

Anyway, I'm at a loss and just shooting in the dark at this point. :confused:

Load the custom TLS certs in Traefik, then check directly via browser if they are served.

If that works, then it’s up to your fronting container to accept those custom TLS certs when sending requests to Traefik, it’s up to the app how to configure it.

The certs have been working in Traefik for years. They are not the issue per se.

That's precisely the issue. As depicted and described in the Souin docs, there's only ONE way to configure Souin as a container, and it seems to assume the use of Let's Encrypt, which is not the case on my dev machine.

At this point, I guess I'll just wait for plugin mode to be fixed. It's my preferred way to use Souin anyway.

Hey @shot the standalone server is deprecated and won't be maintained in the future. :frowning:
If you want to not use Souin in front of Træfik, I suggest you to use the Caddy integration with Souin as middleware in it

You will have something like that:
incoming request -> caddy (+ souin as module) -> traefik -> app

Caddy will handle the TLS certs for you and you will get better cache performances because Træfik don't allow developers to use low level code so caddy with souin is more efficient than Traefik with souin.

Thanks for the reply, @darkweak, but I definitely DON'T want to use Souin in front of Traefik. I originally wanted to use it as Traefik middleware via Docker.

The attempt outlined in this thread was an act of desperation when I couldn't get Souin working as Traefik middleware. However, since this post, I have been successful getting Souin to work as middleware. I've invested a ton of time and effort learning the ropes with Traefik (and it's been working out well), so I have no intention of moving from Traefik.

I've also been really pleased with the performance of Souin as Traefik middleware, although I've encountered some issues related to viewing keys and purging the cache which seem like bugs. I'll be reporting issues via Github and trying the next release, so hopefully, those cache-related kinks can be worked out.

Would be lovely if you would share with the community how it works as middleware.

The actual setup is straightforward. It's just a plugin, and once you install and configure it, just reference the middleware in your routers, and you're off to the races.

My hurdles were due mostly to a lack of familiarity with some of the concepts and terminology and with understanding how best to integrate it into my "chain" of other middleware (which does various header and body rewrites).

The good news is that I was able to get up to speed [enough] technically through online resources; and the bugs I did identify were quickly resolved by the developer.

I would recommend giving it a go if you're looking for a cache solution.

1 Like