[{"_1":2,"_168":-5,"_169":-5},"loaderData",{"_3":4,"_13":14,"_21":22,"_143":144},"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,"_20":11},"username","isAskGordonEnabled",true,"isUsingNewTemplate","showMinimalLanding","showHoneypotTrap","routes/_layout.r.$namespace.$reponame",{"_23":24,"_25":-5,"_26":11,"_27":11,"_28":29,"_30":31,"_32":-5,"_33":11,"_34":35,"_84":-5,"_85":86,"_134":-5,"_135":11,"_136":17,"_137":11,"_138":-5,"_139":11,"_140":-5,"_141":142},"canonicalUrl","https://hub.docker.com/r/tenrero/https-tls-testtool/tags","mcpServer","canSeeDockerfile","canSeeAutobuilds","namespace","tenrero","reponame","https-tls-testtool","cloudBuildSource","isAutobuildsAvailable","repo",{"_36":37,"_38":39,"_41":42,"_43":44,"_45":11,"_46":47,"_48":49,"_50":51,"_53":31,"_28":29,"_54":55,"_56":40,"_57":58,"_59":60,"_61":62,"_63":-5,"_64":58,"_65":66,"_67":11,"_68":29,"_69":70,"_75":11,"_76":77,"_81":29,"_82":83},"categories",[],"content_types",[40],"image","date_registered","2021-08-24T19:57:29.327938Z","description","","is_private","last_updated","2021-08-24T20:13:41.377677Z","last_modified","2024-10-16T13:48:34.145251Z","media_types",[52],"application/vnd.docker.container.image.v1+json","name","pull_count",294,"repository_type","star_count",0,"status",1,"status_description","active","source","collaborator_count","full_description","# HTTPS-TLS TEST TOOL\n\nThis Fork is intended for HTTP(s) / TLS / mTLS testing. It allows you to specify TLS protocols.\n\nIt also has an extended logging configuration, which is very useful for debugging the connections received by the server\n\n```bash\nhttps-portal_1 | 172.240.0.1 - - [24/Aug/2021:19:53:21 +0000] \"GET / HTTP/2.0\" TLSv1.3/TLS_AES_256_GCM_SHA384 200 1033 \"-\" \"curl/7.78.0\" \"-\"\n```\n\nHTTPS-PORTAL is a fully automated HTTPS server powered by\n[Nginx](http://nginx.org), [Let's Encrypt](https://letsencrypt.org) and\n[Docker](https://www.docker.com). By using it, you can run any existing web\napplication over HTTPS, with only one extra line of configuration.\n\nThe SSL certificates are obtained, and renewed from Let's Encrypt\nautomatically.\n\n\nFORKED FROM:\n\nDocker Hub page:\n[https://hub.docker.com/r/tenrero/https-tls-testtool/](https://hub.docker.com/r/tenrero/https-tls-testtool/)\n\n## Table of Contents\n\n- [HTTPS-PORTAL](#https-portal)\n - [Prerequisite](#prerequisite)\n - [See It Work](#see-it-work)\n - [Quick Start](#quick-start)\n - [Features](#features)\n - [Test Locally](#test-locally)\n - [Redirections](#redirections)\n - [Automatic Container Discovery](#automatic-container-discovery)\n - [Hybrid Setup with Non-Dockerized Apps](#hybrid-setup-with-non-dockerized-apps)\n - [Multiple Domains](#multiple-domains)\n - [Multiple Upstreams](#multiple-upstreams)\n - [Serving Static Sites](#serving-static-sites)\n - [Share Certificates with Other Apps](#share-certificates-with-other-apps)\n - [HTTP Basic Auth](#http-basic-auth)\n - [Access Restriction](#access-restriction)\n - [Logging configuration](#logging-configuration)\n - [Debugging](#debugging)\n - [Other configurations](#other-configurations)\n - [Advanced Usage](#advanced-usage)\n - [Configure Nginx through Environment Variables](#configure-nginx-through-environment-variables)\n - [Change Configuration Dynamically](#change-configuration-dynamically)\n - [Override Nginx Configuration Files](#override-nginx-configuration-files)\n - [Manually Set Private Key Length/Type](#manually-set-private-key-length-type)\n - [How It Works](#how-it-works)\n - [About Rate Limits of Let's Encrypt](#about-rate-limits-of-lets-encrypt)\n - [Troubleshooting](#troubleshooting)\n - [Credits](#credits)\n\n## Prerequisite\n\nHTTPS-PORTAL is shipped as a Docker image. To use it, you need a Linux machine\n(either local or remote host) which:\n\n* Has 80 and 443 port available and exposed.\n* Has [Docker Engine](https://docs.docker.com/engine/installation/) installed.\n In addition, [Docker Compose](https://docs.docker.com/compose/) is highly\n recommended, for it makes your life easier. Examples in our documents are\n mainly in Docker Compose format.\n* Has all domains you're going to use in the following examples resolving to\n it.\n\nThough it is good to have, knowledge about Docker is not required to use\nHTTPS-PORTAL.\n\n## See It Work\n\nCreate a `docker-compose.yml` file with the following content in any directory\nof your choice:\n\n```yaml\nversion: '3'\n\nservices:\n https-portal:\n image: tenrero/https-tls-testtool\n ports:\n - '80:80'\n - '443:443'\n environment:\n DOMAINS: 'example.com'\n # STAGE: 'production' # Don't use production until staging works\n volumes:\n - https-portal-data:/var/lib/https-portal\n\nvolumes:\n https-portal-data: # Recommended, to avoid re-signing when upgrading HTTPS-PORTAL\n```\n\nRun the `docker-compose up` command in the same directory. A moment later you'll\nhave a welcome page running in\n[https://example.com](https://example.com).\n\n## Quick Start\n\nHere is a more real-world example: Create the file `docker-compose.yml` in another\ndirectory:\n\n```yaml\nversion: '3'\n\nhttps-portal:\n image: tenrero/https-tls-testtool \n ports:\n - '80:80'\n - '443:443'\n links:\n - wordpress\n restart: always\n environment:\n DOMAINS: 'wordpress.example.com -> http://wordpress:80'\n # STAGE: 'production' # Don't use production until staging works\n # FORCE_RENEW: 'true'\n volumes: \n - https-portal-data:/var/lib/https-portal\n\nwordpress:\n image: wordpress\n links:\n - db:mysql\n\ndb:\n image: mariadb\n environment:\n MYSQL_ROOT_PASSWORD: ''\n\nvolumes:\n https-portal-data:\n```\n\nRun the `docker-compose up -d` command. A moment later you'll get a WordPress\nrunning on [https://wordpress.example.com](https://wordpress.example.com).\n\nIn the example above, only the environment variables under the `https-portal`\nsection are HTTPS-PORTAL specific configurations. This time we added an extra\nparameter `-d`, which will tell Docker Compose to run the apps defined in\n`docker-compose.yml` in the background.\n\nNote: \n\n- `STAGE` is `staging` by default, which results in a test\n(untrusted) certificate from Let's Encrypt.\n- `wordpress` is the hostname of WordPress container within HTTPS-PORTAL container. Usually you can use the service name of your WordPress container.\n\n## Features\n\n### Test Locally\n\nYou can test HTTPS-PORTAL with your application stack locally.\n\n```yaml\nhttps-portal:\n # ...\n environment:\n STAGE: local\n DOMAINS: 'example.com'\n```\n\nBy doing this, HTTPS-PORTAL will create a self-signed certificate.\nThis certificate is not likely to be trusted by your browser, but you can\nuse it to test your docker-compose file. Make sure it works with your application\nstack.\n\nNote that HTTPS-PORTAL only listens to `example.com`, as you specified in the compose file.\nIn order to make HTTPS-PORTAL respond to your connection, you need to either:\n\n* modify your `hosts` file to have `example.com` resolving to your docker host,\n\nor\n\n* set up DNSMasq on your computer/router. This method provides more flexibility.\n\nOnce you are done testing, you can deploy your application stack to the server.\n\n### Redirections\n\nHTTPS-PORTAL support quick setup for redirections.\n\n```yaml\nhttps-portal:\n # ...\n environment:\n DOMAINS: 'example.com => https://target.example.com' # Notice it's \"=>\" instead of the normal \"->\"\n```\n\nAll paths will be redirected to the target. E.g. `https://example.com/foo/bar` will be 301 redirected to `https://target.example.com/foo/bar`.\n\nA common use case is to redirect `www.example.com` to `example.com`. Configure your DNS, make both `www.example.com` and `example.com` resolve to the HTTPS-PORTAL host, and use the following compose:\n\n```yaml\nhttps-portal:\n # ...\n environment:\n DOMAINS: 'www.example.com => https://example.com' # Notice it's \"=>\" instead of the normal \"->\"\n```\n\n### Automatic Container Discovery\n\n**WARNING: WE STRONGLY RECOMMEND AGAINST USING THIS FEATURE UNLESS ABSOLUTELY NECESSARY** as exposing Docker socket to a container (even with `:ro`) essentially gives the container root access to your host OS. If you insist, verify the source code carefully. [Read more](https://dev.to/petermbenjamin/docker-security-best-practices-45ih)\n\nHTTPS-PORTAL is capable of discovering other Docker containers running on the\nsame host, as long as the Docker API socket is accessible within the container.\n\nIn order to make it so, launch HTTPS-PORTAL using the following `docker-compose.yml`.\n\n```yaml\nversion: '2'\n\nservices:\n https-portal:\n # ...\n volumes:\n - /var/run/docker.sock:/var/run/docker.sock:ro # DANGEROUS, see the warning above\n```\n\nand launch one or more web applications with:\n\n```yaml\nversion: '2'\n\nservices:\n a-web-application:\n # ...\n environment:\n # tell HTTPS-PORTAL to set up \"example.com\"\n VIRTUAL_HOST: example.com\n```\n\n**Caveat**: Your web application must be created in the same network as HTTPS-PORTAL.\n\nNote that here is **no need** to link your web service to HTTPS-PORTAL, and you **shouldn't** put `example.com` in environment variable `DOMAINS` of HTTPS-PORTAL.\n\nThis feature allows you to deploy multiple web applications on the same host\nwithout restarting HTTPS-PORTAL itself or interrupting any other application while\nadding/removing web applications.\n\nIf your web service has more than one port exposed (mind that ports can be exposed in your web service Dockerfile),\nuse the environment variable `VIRTUAL_PORT` to specify which port accepts HTTP requests:\n\n```yaml\na-multi-port-web-application:\n # ...\n expose:\n - '80'\n - '8080'\n environment:\n VIRTUAL_HOST: example.com\n VIRTUAL_PORT: '8080'\n```\n\nOf course container discovery works in combination with ENV specified domains:\n\n```yaml\nhttps-portal:\n # ...\n volumes:\n - /var/run/docker.sock:/var/run/docker.sock:ro # DANGEROUS, see the warning above\n environment:\n DOMAINS: 'example.com -> http://upstream'\n```\n\n### Hybrid Setup with Non-Dockerized Apps\n\nWeb applications that run directly on the host machine instead of in Docker\ncontainers are available at `host.docker.internal`. It also works with *Docker for Mac* and *Docker for Windows*.\n\nFor instance, if an application accepts HTTP requests on port 8080 of the host\nmachine, you can start HTTPS-PORTAL by:\n\n```yaml\nhttps-portal:\n # ...\n environment:\n DOMAINS: 'example.com -> http://host.docker.internal:8080'\n```\n\n#### Firewall settings ####\n\nIf you use a firewall like [ufw](https://help.ubuntu.com/community/UFW), you\nmight need to allow communication from the container to your docker host machine.\nYou can check if ufw is active by executing `ufw status`.\n\nIf the command returns `active`, add the ufw rule to allow communication on port 8080 from HTTPS-PORTAL's container IP to the docker host IP on the port where the web application is reachable:\n\n```\nDOCKER_HOST_IP=`docker network inspect code_default --format='{{ .IPAM.Config}}' |awk '{print $2}'` # Assumes that the network is named code_default\nHTTPS_PORTAL_IP=`docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' code_https-portal_1` # Assumes that the container has the name code_https-portal_1\nufw allow from $HTTPS_PORTAL_IP to $DOCKER_HOST_IP port 8080\n```\n\n### Multiple Domains\n\nYou can specify multiple domains by splitting them with commas:\n\n```yaml\nhttps-portal:\n # ...\n environment:\n DOMAINS: 'wordpress.example.com -> http://wordpress:80, gitlab.example.com\n -> http://gitlab'\n```\n\nYou can also specify the stage (`local`, `staging`, or `production`) for each individual site, note that stages of individual sites overrides the global stage:\n\n```yaml\nDOMAINS: 'wordpress.example.com -> http://wordpress #local, gitlab.example.com #staging'\n```\n\n### Multiple Upstreams\n\nIt's possible to define multiple upstreams for a domain for the purpose of load-balancing and/or HA.\nJust add additional upstreams separated by a pipe separator. Each upstream can have custom parameters.\n\n```yaml\nhttps-portal:\n # ...\n environment:\n DOMAINS: 'wordpress.example.com -> http://wordpress1:80|wordpress2:80[weight=2 max_conns=100]\n```\n\n\nSee [Nginx Upstream-Module](http://nginx.org/en/docs/http/ngx_http_upstream_module.html#server) for possible parameters.\n\n### Serving Static Sites\n\nInstead of forwarding requests to web applications, HTTPS-PORTAL can also serve\n(multiple) static sites directly:\n\n```yaml\nhttps-portal:\n # ...\n environment:\n DOMAINS: 'hexo.example.com, octopress.example.com'\n volumes:\n - https-portal-data:/var/lib/https-portal\n - /data/https-portal/vhosts:/var/www/vhosts\n```\n\nAfter HTTPS-PORTAL is started, it will create corresponding sub-directories for\neach virtual host in the `/data/https-portal/vhosts` directory on the host machine:\n\n```yaml\n/data/https-portal/vhosts\n├── hexo.example.com\n│ └── index.html\n└── octopress.example.com\n └── index.html\n```\n\nYou can place your own static files in this directory hierarchy, they will not\nbe overwritten. You need an `index.html` to be served as the homepage.\n\n### Share Certificates with Other Apps\n\nYou can mount an arbitrary host directory to `/var/lib/https-portal` as a\n[data volume](https://docs.docker.com/engine/userguide/dockervolumes/).\n\nFor instance:\n\n```yaml\nhttps-portal:\n # ...\n volumes:\n - /data/ssl_certs:/var/lib/https-portal\n```\n\nNow your certificates are available in `/data/ssl_certs` on your host.\n\n### HTTP Basic Auth\n\nYou can set up an HTTP Basic Auth easily. It is useful when you put the website\nonline but don't want to open it to public until ready.\n\nIn your docker-compose file:\n\n```yaml\nhttps-portal:\n # ...\n environment:\n DOMAINS: 'username:password@example.com -> '\n```\n\n### Access Restriction\n\n**Notice: Access Restriction might not work as intended with Docker for Mac and Docker for Windows. In those systems, Docker essentially runs in VMs, so the requesting IP would be the IP of the proxy service.**\n\nYou can enable IP access restrictions to protect your website. Specify global restrictions with the environment variable `ACCESS_RESTRICTION`. In addition each website can have individual restrictions.\n\nExample with global restriction:\n\n```yaml\nhttps-portal:\n # ...\n environment:\n ACCESS_RESTRICTION: \"1.2.3.4/24 4.3.2.1\"\n```\n\nExample with individual restrictions:\n\n```yaml\nhttps-portal:\n # ...\n environment:\n DOMAINS: \"[1.2.3.4/24] a.example.com -> , [1.2.3.4/24 4.3.2.1] b.example.com\"\n```\n\nExample for auto discovery:\n\n```yaml\nhttps-portal:\n # ...\nmy_app:\n image: ...\n environment:\n VIRTUAL_HOST: \"[1.2.3.4] example.com\"\n```\n\nFor valid IP values see [Nginx allow](http://nginx.org/en/docs/http/ngx_http_access_module.html#allow)\n\n### Logging configuration\n\nBy default no Nginx access logs are written, and error logs are written to stdout, which will be captured by Docker. There are few options to configure them:\n\n* Redirect error/access logs to stdout/stderr:\n \n ```yaml\n https-portal:\n # ...\n environment:\n ERROR_LOG: stdout\n ACCESS_LOG: stderr\n ```\n\n* Write logs to default locations:\n\n ```yaml\n https-portal:\n # ...\n environment:\n ERROR_LOG: default\n ACCESS_LOG: default\n volumes:\n - https-portal-data:/var/lib/https-portal\n - /path/to/log/directory:/var/log/nginx/\n - /path/to/logrotate/state/directory:/var/lib/logrotate/\n ```\n\n Default log files pathes are `/var/log/nginx/access.log` and `/var/log/nginx/error.log`.\n\n Log files within default location `/var/log/nginx/*.log` are rotated on daily basis.\n HTTPS-PORTAL will keep up to 30 log files and will compress files older than 2 days\n (so current day log and previous day log are both available in plain text while all older ones are compresses).\n\n If you want to alter log rotation configuration, you can overwrite `/etc/logrotate.d/nginx`.\n\n* Write logs to custom locations:\n\n ```yaml\n https-portal:\n # ...\n environment:\n ERROR_LOG: /var/log/custom-logs/error.log\n ACCESS_LOG: /var/log/custom-logs/access.log\n volumes:\n - https-portal-data:/var/lib/https-portal\n - /path/to/log/directory:/var/log/custom-logs/\n ```\n\n Note that no automatic log rotation will be performed in this case.\n\n* Other env variables:\n\n There are some other configurable environment variables regarding logging:\n\n * `ACCESS_LOG_BUFFER` - controls buffer size of access log. Example: 16k.\n * `ERROR_LOG_LEVEL` - controls error log level. Default value is `error`\n\n### Debugging\n\nWith the environment variable `DEBUG=true` you can see more info printed about domain parsing, such as:\n\n```\nDEBUG: name:'example.com' upstreams:'' redirect_target:''\n```\n\n### Other Configurations\n\nBy default, HTTPS-PORTAL renews the certificate about 30 days before the expiry. You can customize it by:\n```\nRENEW_MARGIN_DAYS=30\n```\n\n## Advanced Usage\n\n### Configure Nginx through Environment Variables\n\nIn case you need to change Nginx's default parameters, \nthere are several additional environment variables that you can use to config Nginx.\nThey correspond to the configuration options that you would normally put in `nginx.conf`.\nThe following are the available params with their default values:\n\n```\nWORKER_PROCESSES=1\nWORKER_CONNECTIONS=1024\nKEEPALIVE_TIMEOUT=65\nGZIP=on # can be 'off' (you need quotes)\nSERVER_TOKENS=off\nSERVER_NAMES_HASH_MAX_SIZE=512\nSERVER_NAMES_HASH_BUCKET_SIZE=32 # defaults to 32 or 64 based on your CPU\nCLIENT_MAX_BODY_SIZE=1M # 0 disables checking request body size\nPROXY_BUFFERS=\"8 4k\" # Either 4k or 8k depending on the platform\nPROXY_BUFFER_SIZE=\"4k\" # Either 4k or 8k depending on the platform\nRESOLVER=\"Your custom solver string\"\nPROXY_CONNECT_TIMEOUT=60;\nPROXY_SEND_TIMEOUT=60;\nPROXY_READ_TIMEOUT=60;\nACCESS_LOG=off;\nACCESS_LOG_INCLUDE_HOST=off; # include vhost in access log (useful for goaccess => use log-format=VCOMBINED)\n```\n\n#### Websocket\n\nYou can add\n\n```\nWEBSOCKET=true\n```\n\nto make HTTPS-PORTAL proxy WEBSOCKET connections.\n\n#### DNS caching\n\nTo avoid nginx DNS caching, activate dynamic upstream\n\n```\nRESOLVER=\"127.0.0.11 ipv6=off valid=30s\"\nDYNAMIC_UPSTREAM=true\n```\n\n#### HSTS Header\n\nYou can use the follow environment variable to set HSTS header.\n\n**WARNING:** Please test with a low value before you set it to a desired high max_age value. Once you send the header out, all visited clients would refuse to downgrade to HTTP. It would then be impossible to fallback your website to HTTP. \n\n```\nHSTS_MAX_AGE=60 # in seconds\n```\n\n#### IPv6 connectivity\n\n**Notice:** IPv6 is only supported on Linux hosts.\n\nYou can enable IPv6 connection using the following variable:\n\n```\nLISTEN_IPV6=true\n```\n#### Other server block level configurations\n\nYou can add additional `server` block level configurations to each domain:\n\n```yaml\n environment:\n ...\n CUSTOM_NGINX_SERVER_CONFIG_BLOCK: add_header Strict-Transport-Security \"max-age=60\" always;\n```\nYou can also make it multi-line:\n\n```yaml\n environment:\n ...\n CUSTOM_NGINX_SERVER_CONFIG_BLOCK: |\n \tadd_header Strict-Transport-Security \"max-age=60\" always;\n \tauth_basic \"Password\";\t\n```\n\nThe `CUSTOM_NGINX_SERVER_CONFIG_BLOCK` will be inserted after all other configuration blocks listed in section \"Configure Nginx through Environment Variables\", and it might conflict with other configurations.\n\nIn addition to the global `CUSTOM_NGINX_SERVER_CONFIG_BLOCK`, which applies to all configurations, there are `CUSTOM_NGINX__CONFIG_BLOCK`s, which are inserted after the `CUSTOM_NGINX_SERVER_CONFIG_BLOCK`, but only into the configuration file for a specific site. **For instance**, To make specific changes to `example.com` only, create an environment variable `CUSTOM_NGINX_EXAMPLE_COM_CONFIG_BLOCK`.\n\n```\n# generated Nginx config:\nserver {\n\tlisten 443 ssl http2;\n\t... # (other configurations)\n\t<%= CUSTOM_NGINX_SERVER_CONFIG_BLOCK %>\n\t<%= CUSTOM_NGINX__CONFIG_BLOCK %>\n\tlocation / {\n\t\t...\n\t}\n}\n```\n\n### Change Configuration Dynamically\n\nEnvironment variables may be dynamically overridden by modifying files\n`/var/lib/https-portal/dynamic-env`. The file's name and contents will create\nan environment variable with that name and contents, respectively. About 1s\nafter the last modification, the configuration will be updated to reflect the\nnew configuration. This allows modifying the configuration without downtime.\n\n### Override Nginx Configuration Files\n\nYou can override default nginx settings by providing a config segment of\nnginx.conf containing a valid `server` block. The custom nginx configurations\nare [ERB](http://www.stuartellis.eu/articles/erb/) templates and will be\nrendered before usage.\n\nYou can either just override one single site's config or all sites' configs.\n\n#### Override just one single site's config\n\nIn this case, you provide `.conf.erb` and `.conf.ssl.erb`. The former one takes care of the ownership verification from Let's Encrypt, and redirection to https URL. The latter one handles https connections.\n\nFor instance, to override both HTTPS and HTTP settings for `my.example.com`,\nyou can launch HTTPS-PORTAL by:\n\n```yaml\nhttps-portal:\n # ...\n volumes:\n - https-portal-data:/var/lib/https-portal\n - /path/to/http_config:/var/lib/nginx-conf/my.example.com.conf.erb:ro\n - /path/to/https_config:/var/lib/nginx-conf/my.example.com.ssl.conf.erb:ro\n```\n\n[This file](https://github.com/tenrero/https-tls-testtool/blob/master/fs_overlay/var/lib/nginx-conf/default.conf.erb) and [this file](https://github.com/tenrero/https-tls-testtool/blob/master/fs_overlay/var/lib/nginx-conf/default.ssl.conf.erb) are the default configuration files used by HTTPS-PORTAL.\nYou can probably start by copying these files. You can either keep the variables or just hard-code the domain and upstream, etc.\n\nAnother example can be found [here](/examples/custom_config).\n\n#### Override All sites' default config\n\nIf you want to make an Nginx configuration that will be used by all sites, you can overwrite `/var/lib/nginx-conf/default.conf.erb` or `/var/lib/nginx-conf/default.ssl.conf.erb`. These two files will be propagated to each site if the site-specific configuration files are not provided.\n\nSince the config files will be used on all your sites, please keep using the variables already in the file and don't hard-code anything.\n\n### Manually Set Private Key Length/Type\n\nBy default, HTTPS-PORTAL generate `2048` bits long RSA private key. \nHowever, you can manually set RSA private key length (`numbits` of `openssl genrsa` command) through `NUMBITS` environment variable.\n\n```yaml\nhttps-portal:\n # ...\n environment:\n NUMBITS: '4096'\n```\n\nAlternatively, you can set the `CERTIFICATE_ALGORITHM` environment variable to `prime256v1`, as [recommended by Mozilla](https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility). Note however, that this setting prevents some older clients/systems from connecting.\n\nBoth settings apply to newly generated keys only. If you would like to update existing keys, remove the existing keys stored under `/var/lib/https-portal` and restart `https-portal`.\n\n## How It Works\n\nIt:\n\n* obtains an SSL certificate for each of your subdomains from\n [Let's Encrypt](https://letsencrypt.org).\n* configures Nginx to use HTTPS (and force HTTPS by redirecting HTTP to HTTPS)\n* sets up a cron job that checks your certificates every week, and renew them.\n if they expire in 30 days.\n\n## About Rate Limits of Let's Encrypt\n\nLet's Encrypt's service is rate limited to ensure fair usage. Please familiarize\nyourself with [the various rate\nlimits](https://letsencrypt.org/docs/rate-limits/). This documentation page is\nthe authoritative source for the current rate limit values.\n\nFor most people the most important rate limits are:\n\n* 5 failed validation attempts per hour\n* 50 certificates per registered domain per week\n* 5 duplicated certificate per week (for renewal)\n\nIf you want to use HTTPS for multiple sub-domains with a single certificate\nLet's Encrypt supports putting up to 100 domains in one certificate, however it\ncan require careful planning and is hard to automate. So in HTTPS-PORTAL we only\ndeal with single domain name certificates.\n\nHTTPS-PORTAL stores your certificates in a data volume and will not re-sign\ncertificates until 30 days before expiration if a valid certificate is found\n(you can force renew certificates by using `FORCE_RENEW: 'true'` environment\nvariable). However if you play around with the image a lot, you can hit the\nlimit. That's why `STAGE` is `staging` by default, and thus we use the\nLet's Encrypt staging server. When you have finished your experiments and feel\neverything is good, you can switch to production mode with `STAGE:\n'production'`.\n\n### TLS Protocols\n\nSpecify the environment variable `SSL_PROTOCOLS`. The default values are `TLSv1.2 TLSv1.3`\n\n## Troubleshooting\n\n### Force renew\n\nIf you find your certificates are not chained correctly, please run the container\nagain with the follow setting once:\n\n```yaml\nhttps-portal:\n # ...\n environment:\n # ...\n FORCE_RENEW: 'true' # <-- here\n```\n\nThis is because with ACME v2 returns the full chain instead of a partial chain \nwith ACME v1. If you have old certificates stored, HTTPS-PORTAL may not be able \nto handle the case correctly. If you run into this issue, just `FORCE_RENEW` to \nobtain a new set of certificates.\n\n### Reset the data volume\n\nIf you find HTTPS-PORTAL is not behaving as expected, try to reset the data volume:\n\n```\ndocker-compose down -v\ndocker-compose up\n```\n\n## Credits\n\n* [acme-tiny](https://github.com/diafygi/acme-tiny) by Daniel Roesler.\n* [docker-gen](https://github.com/jwilder/docker-gen) by Jason Wilder.\n* [s6-overlay](https://github.com/just-containers/s6-overlay).\n","has_starred","hub_user","immutable_tags_settings",{"_71":11,"_72":73},"enabled","rules",[74],".*","is_automated","permissions",{"_78":17,"_79":11,"_80":11},"read","write","admin","user","storage_size",180643969,"orgData","recentTags",[87,124],{"_88":40,"_89":90,"_91":92,"_93":94,"_95":96,"_46":113,"_114":90,"_115":29,"_116":52,"_53":117,"_118":119,"_120":104,"_121":113,"_122":62,"_123":17},"content_type","creator",2461563,"full_size",95951048,"id",164093889,"images",[97],{"_98":99,"_100":101,"_102":44,"_103":104,"_105":106,"_107":108,"_109":44,"_110":-5,"_111":92,"_59":62,"_112":-5},"architecture","amd64","digest","sha256:097988f5112f36081e9b7fe980d225eaaa9edc465996491aba9a8a1ce53af509","features","last_pulled","2026-09-22T19:43:40.216102475Z","last_pushed","2021-08-24T19:57:30Z","os","linux","os_features","os_version","size","variant","2021-08-24T19:57:29.158133Z","last_updater","last_updater_username","media_type","latest","repository",15215670,"tag_last_pulled","tag_last_pushed","tag_status","v2",{"_88":40,"_89":90,"_91":125,"_93":126,"_95":127,"_46":132,"_114":90,"_115":29,"_116":52,"_53":133,"_118":119,"_120":130,"_121":132,"_122":62,"_123":17},95950968,164095694,[128],{"_98":99,"_100":129,"_102":44,"_103":130,"_105":131,"_107":108,"_109":44,"_110":-5,"_111":125,"_59":62,"_112":-5},"sha256:35cf3564e52fe1aed7d610132840c8937085653cc7f1033fc48f4994994d7211","2026-09-14T01:42:07.030150872Z","2021-08-24T20:13:37Z","2021-08-24T20:13:36.781213Z","master","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","showSbxLogoOverride","sbxTrademarkText","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"routes/_layout.r.$namespace.$reponame.tags",{"_34":145,"_152":153,"_141":166,"_167":11},{"_36":146,"_38":147,"_41":42,"_43":44,"_45":11,"_46":47,"_48":49,"_50":148,"_53":31,"_28":29,"_54":55,"_56":40,"_57":58,"_59":60,"_61":62,"_63":-5,"_64":58,"_65":66,"_67":11,"_68":29,"_69":149,"_75":11,"_76":151,"_81":29,"_82":83},[],[40],[52],{"_71":11,"_72":150},[74],{"_78":17,"_79":11,"_80":11},"tags",{"_154":155,"_156":-5,"_157":-5,"_158":159},"count",2,"next","previous","results",[160,163],{"_88":40,"_89":90,"_91":125,"_93":126,"_95":161,"_46":132,"_114":90,"_115":29,"_116":52,"_53":133,"_118":119,"_120":130,"_121":132,"_122":62,"_123":17},[162],{"_98":99,"_100":129,"_102":44,"_103":130,"_105":131,"_107":108,"_109":44,"_110":-5,"_111":125,"_59":62,"_112":-5},{"_88":40,"_89":90,"_91":92,"_93":94,"_95":164,"_46":113,"_114":90,"_115":29,"_116":52,"_53":117,"_118":119,"_120":104,"_121":113,"_122":62,"_123":17},[165],{"_98":99,"_100":101,"_102":44,"_103":104,"_105":106,"_107":108,"_109":44,"_110":-5,"_111":92,"_59":62,"_112":-5},[],"canDeleteTags","actionData","errors"]

tenrero/https-tls-testtool

Tags for tenrero/https-tls-testtool