[{"_1":2,"_152":-5,"_153":-5},"loaderData",{"_3":4,"_13":14,"_20":21,"_131":132},"root",{"_5":-5,"_6":-7,"_7":8,"_9":-7,"_10":11,"_12":-7},"currentUser","primaryEmail","siteVerification","6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI","toast","enableDev",false,"incidentStatus","routes/_layout",{"_15":-5,"_16":17,"_18":17,"_19":11},"username","isAskGordonEnabled",true,"isUsingNewTemplate","showMinimalLanding","routes/_layout.r.$namespace.$reponame",{"_22":23,"_24":-5,"_25":11,"_26":11,"_27":28,"_29":30,"_31":-5,"_32":11,"_33":34,"_83":-5,"_84":85,"_124":-5,"_125":11,"_126":17,"_127":11,"_128":-5,"_129":130},"canonicalUrl","https://hub.docker.com/r/markdumay/certbot-sakuracloud/tags","mcpServer","canSeeDockerfile","canSeeAutobuilds","namespace","markdumay","reponame","certbot-sakuracloud","cloudBuildSource","isAutobuildsAvailable","repo",{"_35":36,"_37":38,"_40":41,"_42":43,"_44":11,"_45":46,"_47":48,"_49":50,"_52":30,"_27":28,"_53":54,"_55":39,"_56":57,"_58":59,"_60":61,"_62":-5,"_63":57,"_64":65,"_66":11,"_67":28,"_68":69,"_74":11,"_75":76,"_80":28,"_81":82},"categories",[],"content_types",[39],"image","date_registered","2020-10-30T05:09:51.398872Z","description","Unprivileged Certbot with Sakura Cloud DNS Plugin","is_private","last_updated","2020-11-09T18:46:42.312866Z","last_modified","2024-10-16T13:48:34.145251Z","media_types",[51],"application/vnd.docker.container.image.v1+json","name","pull_count",355,"repository_type","star_count",0,"status",1,"status_description","active","source","collaborator_count","full_description","# nginx-certbot (work in progress)\n\n\n

\n Automatically Renew Certificates For an Unprivileged Nginx Web Server\n
\n

\n\n\n\n

\n \n \n \n \n \n \n \n \n \n \n \n \n

\n\n\n

\n About •\n Built With •\n Prerequisites •\n Testing •\n Deployment •\n Usage •\n Contributing •\n Credits •\n Donate •\n License\n

\n\n\n## About\n[Nginx][nginx_url] is a popular open-source web server and reverse proxy. This repository sets up Nginx as an unprivileged Docker container to make it more secure. Furthermore, it uses [certbot][certbot_url] to automatically install and renew Let's Encrypt certificates, enabling Nginx to act as an HTTPS server. Certbot is run as a root-less container too. The script uses a DNS-01 challenge to support automated installation and renewal of wildcard certificates. More than 10 different DNS providers are supported, or any DNS server supporting RFC 2136 Dynamic Updates.\n\n\n\n## Built With\nThe project uses the following core software components:\n* [Certbot][certbot_url] - Open-source software tool for automatically using Let’s Encrypt certificates on manually-administrated websites to enable HTTPS.\n* [Docker][docker_url] - Open-source container platform.\n* [Nginx][nginx_url] - Open-source web server and reverse proxy.\n\n## Prerequisites\n*Nginx-certbot* can run on any Docker-capable host. The setup has been tested locally on macOS Catalina and in production on a server running Ubuntu 20.04 LTS. DNS integration has been tested with Cloudflare, although other DNS plugins are supported too. Additional prerequisites are:\n\n* **A registered domain name is required** - A domain name is required to configure SSL certificates that will enable secure traffic to your web server.\n\n* **Docker Engine and Docker Compose are required** - *nginx-certbot* is to be deployed as Docker container using Docker Compose for convenience. Docker Swarm is a prerequisite to enable Docker *secrets*, however, the use of Docker secrets itself is optional. This [reference guide][swarm_init] explains how to initialize Docker Swarm on your host.\n\n* **A DNS provider supported by certbot is required** - *nginx-certbot* uses a DNS-01 challenge to issue and renew wildcard certificates automatically. As such, an account and token for a supported DNS provider is required. Supported DNS providers and protocols are: [Cloudflare][certbot-dns-cloudflare], [CloudXNS][certbot-dns-cloudxns], [Digital Ocean][certbot-dns-digitalocean], [DNSimple][certbot-dns-dnsimple], [DNS Made Easy][certbot-dns-dnsmadeeasy], [Gehirn][certbot-dns-gehirn], [Google][certbot-dns-google], [Linode][certbot-dns-linode], [LuaDNS][certbot-dns-luadns], [NS1][certbot-dns-nsone], [OVH][certbot-dns-ovh],\n[RFC 2136 Dynamic Updates][certbot-dns-rfc2136], [AWS Route 53][certbot-dns-route53], and [Sakura Cloud DNS][certbot-dns-sakuracloud]. Click on each link to identify the required account and/or token information.\n\n\n## Testing\nIt is recommended to test the services locally before deploying them in a production environment. Running the services with `docker-compose` greatly simplifies validating everything is working as expected. Below four steps will allow you to run the services on your local machine and validate they are working correctly.\n\n### Step 1 - Clone the Repository\nThe first step is to clone the repository to a local folder. Assuming you are in the working folder of your choice, clone the repository files with `git clone`. Git automatically creates a new folder `nginx-certbot` and copies the files to this directory. The option `--recurse-submodules` ensures the embedded submodules are fetched too. Change your working folder to be prepared for the next steps. The code examples use `example.com` as the domain name and `cloudflare` as the DNS provider, replace them with the correct values.\n\n```console\ngit clone --recurse-submodules https://github.com/markdumay/nginx-certbot.git\ncd nginx-certbot\n```\n\n### Step 2 - Update the Environment Variables\nThe `docker-compose.yml` file uses environment variables to simplify the configuration. You can use the sample file in the repository as a starting point.\n\n```console\nmv sample.env .env\n```\n\nThe `.env` file specifies eight variables. Adjust them as needed:\n\n\n| Variable | Mandatory | Example | Description |\n|-------------------------------------|-----------|--------------------|-------------|\n| **CERTBOT_DOMAIN** | Yes | `example.com` | Domain for which certbot will issue a wildcard certificate. Both `*.example.com` and `example.com` are issued. This means that, for example, `www.example.com` is covered by the certificate. However, `thisisa.subdomain.example.com` is not covered, as this requires a wildcard certificate for `*.subdomain.example.com`. |\n| **CERTBOT_EMAIL** | Yes | `mail@example.com` | An administrative email account to receive notifications from Let's Encrypt on.\n| **CERTBOT_DNS_PLUGIN** | Yes | `cloudflare` | A DNS provider supported by certbot. Supported values are [cloudflare][certbot-dns-cloudflare], [cloudxns][certbot-dns-cloudxns], [digitalocean][certbot-dns-digitalocean], [dnsimple][certbot-dns-dnsimple], [dnsmadeeasy][certbot-dns-dnsmadeeasy], [gehirn][certbot-dns-gehirn], [google][certbot-dns-google], [linode][certbot-dns-linode], [luadns][certbot-dns-luadns], [nsone][certbot-dns-nsone], [ovh][certbot-dns-ovh], [rfc2136][certbot-dns-rfc2136], [route53][certbot-dns-route53], and [sakuracloud][certbot-dns-sakuracloud]. Click on each link to identify the required account and/or token information. \n| **CERTBOT_DNS_PROPAGATION_SECONDS** | No | `30` | The duration in seconds for which certbot will await the DNS provider to have propagated the DNS-01 challenge text records. Adjust the value if needed, as the default value for each DNS provider might be too short, resulting in a validation error.\n| **CERTBOT_DEPLOYMENT** | Yes | `test` | Options are `test` or `production`. Use `test` for testing purposes to avoid hitting rate limits from Let's Encrypt. In test mode, no actual certificates are installed. |\n| **HOST_PORT_HTTP** | Yes | `80` | The host port to map the nginx web server to for HTTP traffic. The default value for HTTP traffic is port 80, which needs to be available on your host.\n| **HOST_PORT_HTTPS** | Yes | `443` | The host port to map the nginx web server to for secure, HTTPS traffic. The default value for HTTPS traffic is port 443, which needs to be available on your host.\n| **NGINX_PORT_HTTP** | Yes | `8080` | The internal port for HTTP traffic within the nginx container. The value needs to be greater than 1023, as the container runs in unprivileged (non-root) mode.\n| **NGINX_PORT_HTTPS** | Yes | `4430` | The internal port for HTTPS traffic within the nginx container. The value needs to be greater than 1023, as the container runs in unprivileged (non-root) mode.\n\n### Step 3 - Specify DNS Credentials\nPending on your selected DNS provider, you will need to specify the API token and/or account credentials to connect with the DNS provider for the automated DNS-01 challenge. You can either specify the credentials as environment variables or as Docker secrets. Docker secrets are a bit more secure and are more suitable for a production environment. Please check the documentation of your DNS provider in the Prerequisites section. \n\n#### Option 3a - Using Environment Variables\nFollowing the recommended [cloudflare][certbot-dns-cloudflare] configuration, you will need to add an API token `dns_cloudflare_api_token`. Add the following line to `docker-compose.yml`:\n```yml\n[...]\nservices:\n certbot:\n [...]\n environment:\n - dns_cloudflare_api_token=${dns_cloudflare_api_token}\n```\n\nNow add the token to your `.env` file, replacing the token with the real value:\n```\n[...]\ndns_cloudflare_api_token=0123456789abcdef0123456789abcdef01234567\n```\n\n#### Option 3b - Using Docker Secrets\nAs Docker Compose does not support external Swarm secrets, we will create local secret files for testing purposes. The credentials are stored as plain text, so this is not recommended for production. Add the secret to `docker-compose.yml` first, and authorize the certbot service.\n```yml\nversion: \"3\"\n\nsecrets:\n dns_cloudflare_api_token:\n file: secrets/dns_cloudflare_api_token\n\n[...]\n\nservices:\n certbot:\n [...]\n secrets:\n - dns_cloudflare_api_token\n```\n\nNow create the file-based secret:\n```console\nmkdir secrets\nprintf 0123456789abcdef0123456789abcdef01234567 > secrets/dns_cloudflare_api_token\n```\n\n### Step 4 - Run Docker Containers\nTest the Docker containers with the below commands. Be sure to have set the value of `CERTBOT_DEPLOYMENT` to `test` first.\n\n```console\ndocker-compose build --no-cache\ndocker-compose up\n```\n\nThe images for Nginx and Certbot need to be created first, as they instruct the containers to run in unprivileged mode. Both images use the base images provided by Certbot and Nginx respectively. Certbot provides base images for each specific DNS plugin to minimize the image size. Run the containers in interactive mode with `docker-compose up` once the building has finished successfully. You should see several messages now. The below excerpt shows the key messages per section.\n\n#### Initializing Certbot Configuration\nDuring boot, the custom Certbot container initializes the environment variables and Docker secrets, if applicable. The following environment variables need to be present and have to conform to the expected format:\n* CERTBOT_DOMAIN\n* CERTBOT_EMAIL\n* CERTBOT_DNS_PLUGIN\n* CERTBOT_DEPLOYMENT\n\nThe following environment variable is optional:\n* CERTBOT_DNS_PROPAGATION_SECONDS\n\nAlso, at least one token variable for the DNS plugin needs to be provided as either environment variable or Docker secret. Secrets that start with a prefix of the specified DNS plugin are initialized automatically. For example, `dns_cloudflare_api_token` is initialized if the `CERTBOT_DNS_PLUGIN` is set to `cloudflare`.\n\n```\ncertbot_1 | Step 1 from 3: Initializing configuration\n```\n\nThe container terminates with an exit code if variables are missing or incorrect.\n\n#### Updating Certbot Configuration\nOnce the environment variables have been initialized successfully, the container generates a configuration file for the specified DNS plugin. This file contains the credentials to connect with the DNS provider, and as such, should be protected. The file is put in the home directory of the default (non-root) `certbot` user. The file has the name of the specified DNS plugin, in this case, `cloudflare`.\n```\ncertbot_1 | Step 2 from 3: Updating certbot configuration\ncertbot_1 | Generating certbot configuration file ('/home/certbot/.secrets/certbot/cloudflare.ini')\n```\n\n#### Issuing Certificates\nIn test mode, Certbot performs a test run with the staging server of Let's Encrypt. This allows you to test the configuration without hitting rate limits.\n\n```\ncertbot_1 | Step 3 from 3: Issuing certificate for 'example.com'\ncertbot_1 | Running in test mode\ncertbot_1 | Executing certbot\ncertbot_1 | Saving debug log to /var/log/certbot/letsencrypt.log\ncertbot_1 | Plugins selected: Authenticator dns-cloudflare, Installer None\ncertbot_1 | Obtaining a new certificate\n```\n\nThe Certbot container uses a DNS-01 challenge for Let's Encrypt to validate ownership of your domain. The DNS configuration is automated using the provided credentials. By default, `nginx-certbot` requests the main certificate and a wildcard certificate for your domain. Two TXT records are published to your DNS server, one for the main domain and one for the wildcard domain. Certbot waits for a specific interval to allow the DNS changes to propagate. The interval is tailored for each supported DNS plugin and can be overwritten with the `CERTBOT_DNS_PROPAGATION_SECONDS` environment variable. In this example, the delay is set to 30 seconds.\n\n```\ncertbot_1 | Performing the following challenges:\ncertbot_1 | dns-01 challenge for example.com\ncertbot_1 | dns-01 challenge for example.com\ncertbot_1 | Waiting 30 seconds for DNS changes to propagate\n```\n\nCertbot notifies you the dry run was successful or not. `Nginx-certbot` uses the following non-standard paths, at it runs in unprivileged mode:\n* `/var/lib/certbot` - Core folder used for signaling locking of files by Certbot.\n* `/var/log/certbot` - Log files of Certbot (with log rotation). `nginx-certbot` appends its messages to these log files too. The log files contain sensitive information, such as the DNS token.\n* `/etc/certbot` - The main folder containing the DNS account settings and issued certificates.\n\n```\ncertbot_1 | Waiting for verification...\ncertbot_1 | Cleaning up challenges\ncertbot_1 | Non-standard path(s), might not work with crontab installed by your operating system package manager\ncertbot_1 | IMPORTANT NOTES:\ncertbot_1 | - The dry run was successful.\n```\n\n#### Initializing Nginx\nThe custom Nginx container uses a default configuration with SSL settings recommended by the [Mozilla SSL Configuration Generator][mozilla-ssl]. Next to that, a default HTTP server is configured using a template (see `config/nginx/templates/default.conf.template`). During initialization, nginx uses this template and the environment variables to generate a default HTTP server. The generated file is put at the location `/etc/nginx/conf.d/default.conf`.\n\n```\nnginx_1 | /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration\nnginx_1 | /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/\nnginx_1 | /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh\nnginx_1 | 10-listen-on-ipv6-by-default.sh: Getting the checksum of /etc/nginx/conf.d/default.conf\nnginx_1 | 10-listen-on-ipv6-by-default.sh: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf\nnginx_1 | /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh\nnginx_1 | 20-envsubst-on-templates.sh: Running envsubst on /etc/nginx/templates/default.conf.template to /etc/nginx/conf.d/default.conf\nnginx_1 | /docker-entrypoint.sh: Configuration complete; ready for start up\n```\n\n#### Installing Certificates\nDuring testing, no actual certificates are installed. Nginx waits for the files `fullchain.pem` and `privkey.pem` to become available in the certificates folder, e.g. `/etc/letsencrypt/live/example.com/`. The files are polled every 30 seconds until they are available.\n```\nnginx_1 | /docker-entrypoint.sh: Waiting for certificates ('/etc/letsencrypt/live/example.com')\n```\n\nCancel execution of the containers with `ctrl-c` to proceed to the production configuration.\n\n\n## Deployment\nThe steps for deploying in production are slightly different than for local testing. The next four steps highlight the changes.\n\n### Step 1 - Clone the Repository\n*Unchanged*\n\n### Step 2 - Update the Environment Variables\n*Unchanged, however, set CERTBOT_DEPLOYMENT to production once everything is working properly*\n\n### Step 3 - Specify DNS Credentials\n#### Option 3a - Using Environment Variables\n*Unchanged*\n\n#### Option 3b - Using Docker Secrets\nInstead of file-based secrets, you will now create more secure secrets. Docker secrets can be easily created using pipes. Do not forget to include the final `-`, as this instructs Docker to use piped input. Update the token as needed.\n\n```console\nprintf 0123456789abcdef0123456789abcdef01234567 | docker secret create dns_cloudflare_api_token -\n```\n\nIf you do not feel comfortable copying secrets from your command line, you can use the wrapper `create_secret.sh`. This script prompts for a secret and ensures sensitive data is not displayed on your console. The script is available in the folder `/docker-secret` of your repository.\n\n```console\n./create_secret.sh dns_cloudflare_api_token\n```\n\nSet `external` to `true` in the `secrets` section of `docker-compose.yml` to use Docker secrets instead of local files.\n\n```Dockerfile\n[...]\nsecrets:\n dns_cloudflare_api_token:\n external: true\n```\n\n### Step 4 - Run Docker Service\nPending your choice to use environment variables or Docker secrets, you can deploy your service using Docker Compose or Stack Deploy.\n\n#### Option 4a - Using Environment Variables\n*Unchanged, however, use `docker-compose up -d` to run the containers in the background*\n\n#### Option 4b - Using Docker Secrets\nDocker Swarm is needed to support external Docker secrets. As such, the services will be deployed as part of a Docker Stack in production. Deploy the stack using `docker-compose` as input. This ensures the environment variables are parsed correctly.\n\n```console\ndocker-compose config | docker stack deploy -c - nginx-certbot\n```\n\nRun the following command to inspect the status of the Docker Stack.\n\n```console\ndocker stack services nginx-certbot\n```\n\nYou should see the value `1/1` for `REPLICAS` for the certbot and nginx services if the stack was initialized correctly. It might take a while before the services are up and running, so simply repeat the command after a few minutes if needed.\n\n```\nID NAME MODE REPLICAS IMAGE PORTS\n*** nginx-certbot_certbot replicated 1/1 markdumay/certbot-cloudflare:latest \n*** nginx-certbot_nginx replicated 1/1 markdumay/nginx-unprivileged:latest *:443->4430/tcp, *:80->8080/tcp\n\n```\n\nYou can view the service logs with `docker service logs nginx-certbot_certbot` or `docker service logs nginx-certbot_nginx` once the services are up and running. Refer to the paragraph Step 4 - Run with Docker Compose for validation of the logs.\n\nDebugging swarm services can be quite tedious. If for some reason your service does not initiate properly, you can get its task ID with `docker service ps nginx-certbot_certbot` or `docker service ps nginx-certbot_nginx`. Running `docker inspect ` might give you some clues to what is happening. Use `docker stack rm nginx-certbot` to remove the docker stack entirely.\n\n\n## Usage\n### Testing Basic Functionality\nHaving followed the steps in this guide, you should have a default HTTP server running on port `80` of your host by now. Test the availability with the following command from your host. Replace the port if needed to reflect the configuration in your `.env` file. If all goes well, the web server should return a page based on `config/nginx/index.html`.\n```\ncurl localhost\n```\n\nIn case of errors, test if the web server is available from within the `nginx` container. Run the following command from your host, updating the internal port `8080` if needed.\n```\ndocker exec -it nginx-certbot_nginx curl localhost:8080\n```\n\n### Configuring a Secure Web Server\nAdd support for an encrypted server once the basic web server is up and running. Create a new file `nginx/templates/example.com.conf.template`, renaming `example.com` to your domain. Below configuration redirects all HTTP traffic to HTTPS, and redirects `www.example.com` to `example.com`. Restart the Docker services/stack to initialize the new server.\n\n```\n# Redirect all non-encrypted to encrypted traffic\nserver {\n server_name ${CERTBOT_DOMAIN};\n listen ${NGINX_PORT_HTTP};\n listen [::]:${NGINX_PORT_HTTP};\n\n location / {\n return 301 https://$server_name$request_uri;\n }\n}\n\n# Redirect all www to non-www\nserver {\n server_name www.${CERTBOT_DOMAIN};\n listen ${NGINX_PORT_HTTP};\n listen [::]:${NGINX_PORT_HTTP};\n listen ${NGINX_PORT_HTTPS} ssl http2;\n listen [::]:${NGINX_PORT_HTTPS} ssl http2;\n\n # Configure certificate and session\n ssl_certificate /etc/certbot/live/${CERTBOT_DOMAIN}/fullchain.pem;\n ssl_certificate_key /etc/certbot/live/${CERTBOT_DOMAIN}/privkey.pem;\n\n return 301 https://${CERTBOT_DOMAIN}$request_uri;\n}\n\n# Handle HTTPS requests\nserver {\n server_name ${CERTBOT_DOMAIN};\n listen ${NGINX_PORT_HTTPS} ssl http2;\n listen [::]:${NGINX_PORT_HTTPS} ssl http2;\n\n # Configure certificate and session\n ssl_certificate /etc/certbot/live/${CERTBOT_DOMAIN}/fullchain.pem;\n ssl_certificate_key /etc/certbot/live/${CERTBOT_DOMAIN}/privkey.pem;\n\n\t# Add index.php to the list if you are using PHP\n\troot /var/www/html;\n\tindex index.html index.htm;\n\n\tlocation / {\n\t\t# First attempt to serve request as file, then\n\t\t# as directory, then fall back to displaying a 404.\n\t\ttry_files $uri $uri/ =404;\n\t}\n}\n```\n\nTesting the secure web server requires you have either configured your DNS server or adjusted your local host database. The DNS server requires two `A` type records for the names `www` and `example.com` that point to your hosts' IP address. The local host database can be found at `/etc/hosts` on most Linux and macOS systems. Add the following entry:\n```\n127.0.0.1 www.example.com example.com\n```\n\n### Renewing Certificates\nThe custom Certbot service validates the installed certificates every 12 hours (see `config/certbot/docker_entrypoint.sh`). The certificate itself is renewed every 60 days. Nginx is reloaded every 6 hours to pick up any renewed certificates automatically (see `config/nginx/docker_entrypoint.sh`).\n\n\n## Contributing\n1. Clone the repository and create a new branch \n ```console\n git checkout https://github.com/markdumay/nginx-certbot.git -b name_for_new_branch\n ```\n2. Make and test the changes\n3. Submit a Pull Request with a comprehensive description of the changes\n\n## Credits\n*Nginx-certbot* is inspired by the following blog article:\n* MikesBytes - [Hosting a site with docker + nginx + certbot + wildcard certs][article_mikesbytes]\n\n## Donate\n $\"Buy$ \n\n## License\n\n

\n\n\nCopyright © [Mark Dumay][blog]\n\n\n\n\n[docker_url]: https://docker.com\n[certbot_url]: https://certbot.eff.org\n[certbot-dns-cloudflare]: https://certbot-dns-cloudflare.readthedocs.io\n[certbot-dns-cloudxns]: https://certbot-dns-cloudxns.readthedocs.io\n[certbot-dns-digitalocean]: https://certbot-dns-digitalocean.readthedocs.io\n[certbot-dns-dnsimple]: https://certbot-dns-dnsimple.readthedocs.io\n[certbot-dns-dnsmadeeasy]: https://certbot-dns-dnsmadeeasy.readthedocs.io\n[certbot-dns-gehirn]: https://certbot-dns-gehirn.readthedocs.io\n[certbot-dns-google]: https://certbot-dns-google.readthedocs.io\n[certbot-dns-linode]: https://certbot-dns-linode.readthedocs.io\n[certbot-dns-luadns]: https://certbot-dns-luadns.readthedocs.io\n[certbot-dns-nsone]: https://certbot-dns-nsone.readthedocs.io\n[certbot-dns-ovh]: https://certbot-dns-ovh.readthedocs.io\n[certbot-dns-rfc2136]: https://certbot-dns-rfc2136.readthedocs.io\n[certbot-dns-route53]: https://certbot-dns-route53.readthedocs.io\n[certbot-dns-sakuracloud]: https://certbot-dns-sakuracloud.readthedocs.io\n[mozilla-ssl]: https://ssl-config.mozilla.org\n[nginx_url]: https://nginx.org\n[swarm_init]: https://docs.docker.com/engine/reference/commandline/swarm_init/\n\n\n[article_mikesbytes]: https://mikesbytes.org/web/2020/02/29/docker-nginx-letsencrypt.html\n\n\n\n[blog]: https://github.com/markdumay\n[repository]: https://github.com/","has_starred","hub_user","immutable_tags_settings",{"_70":11,"_71":72},"enabled","rules",[73],".*","is_automated","permissions",{"_77":17,"_78":11,"_79":11},"read","write","admin","user","storage_size",16366689,"orgData","recentTags",[86],{"_87":39,"_88":89,"_90":91,"_92":93,"_94":95,"_45":113,"_114":89,"_115":28,"_116":51,"_52":117,"_118":119,"_120":104,"_121":113,"_122":61,"_123":17},"content_type","creator",9595884,"full_size",9571336,"id",123774268,"images",[96],{"_97":98,"_99":100,"_101":102,"_103":104,"_105":106,"_107":108,"_109":102,"_110":-5,"_111":91,"_58":61,"_112":-5},"architecture","amd64","digest","sha256:909c22da3d6b9fc7dafd7c7120faf674b8184c168a7e6664a5e71e448e38e151","features","","last_pulled","2026-09-02T10:10:49.153964305Z","last_pushed","2020-11-06T09:20:55Z","os","linux","os_features","os_version","size","variant","2020-11-09T18:46:41.931639Z","last_updater","last_updater_username","media_type","latest","repository",10129303,"tag_last_pulled","tag_last_pushed","tag_status","v2","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"routes/_layout.r.$namespace.$reponame.tags",{"_33":133,"_140":141,"_129":150,"_151":11},{"_35":134,"_37":135,"_40":41,"_42":43,"_44":11,"_45":46,"_47":48,"_49":136,"_52":30,"_27":28,"_53":54,"_55":39,"_56":57,"_58":59,"_60":61,"_62":-5,"_63":57,"_64":65,"_66":11,"_67":28,"_68":137,"_74":11,"_75":139,"_80":28,"_81":82},[],[39],[51],{"_70":11,"_71":138},[73],{"_77":17,"_78":11,"_79":11},"tags",{"_142":59,"_143":-5,"_144":-5,"_145":146},"count","next","previous","results",[147],{"_87":39,"_88":89,"_90":91,"_92":93,"_94":148,"_45":113,"_114":89,"_115":28,"_116":51,"_52":117,"_118":119,"_120":104,"_121":113,"_122":61,"_123":17},[149],{"_97":98,"_99":100,"_101":102,"_103":104,"_105":106,"_107":108,"_109":102,"_110":-5,"_111":91,"_58":61,"_112":-5},[],"canDeleteTags","actionData","errors"]

markdumay/certbot-sakuracloud

Tags for markdumay/certbot-sakuracloud