Caddy, the only web server to use HTTPS automatically and by default, written in Go language

A web server is either a web resource service software (HTTP server) or a computer server (computer) that responds to requests over a public or private network using primarily the HTTP protocol, or HTTPS. Caddy is a web server written in Go, open source and available with HTTPS automatically. It will work just as well as any other web server in Go. For local HTTPS, Caddy may require a password to install its unique root certificate. This only happens once per root; and it can be deleted at any time. Any client accessing the site without trusting the Caddy root will display security errors. Caddy and public domain names These are common requirements for any basic production website, not just Caddy. The main difference is to properly configure the DNS records before launching Caddy so that it can provide certificates. So, as said before, the sites will automatically be served in HTTPS. The administrator does not need to do anything else about it. Since HTTPS uses a shared and public infrastructure, the server administrator should properly understand how Caddy works in order to avoid unnecessary problems, troubleshoot them when they occur, and properly configure advanced deployments. Local HTTPS To serve non-public sites over HTTPS, Caddy generates its own Certificate Authority (CA) and uses it to sign certificates. The chain of trust consists of a root certificate and an intermediate certificate. Leaf certificates are signed by the intermediary. They are stored in Caddy's data directory at pki/authorities/local. Caddy's local AC is powered by Smallstep libraries. Local HTTPS does not use ACME and does not perform DNS validation. It only works on the local machine and is only trusted where the root CA certificate is installed. CA Root The root private key is uniquely generated using a cryptographically secure pseudo-random source and persisted in storage with limited permissions. It is loaded into memory only to perform signing tasks, after which it leaves the scope to be collected. Although Caddy can be configured to sign with root directly (to support non-compliant clients), this is disabled by default, and the root key is only used to sign intermediaries. After installing Root CA from Caddy, you'll see it in your local trust store as Caddy Local Authority (unless you've configured a different name). You can uninstall it anytime you want (the caddy untrust command makes this easy). Note that automatic certificate installation in local trust stores is only for convenience and is not guaranteed to work, particularly if containers are used or if Caddy is run as an unprivileged system service. Ultimately, if you're relying on an internal PKI, it's the system administrator's responsibility to ensure that the Caddy root CA is properly added to the necessary trust stores (this is outside the scope of the web server). The first time a root key is used, Caddy will attempt to install it into the system's local trust store(s). If he does not have permission to do so, he will ask for a password. This behavior can be disabled in the configuration if it is not desired. On-Demand TLS Caddy pioneered a new technology we call On-Demand TLS, which dynamically obtains a new certificate on the first TLS handshake that requires it, rather than when the configuration is loaded. It is important to note that this does not require you to specify domain names in your configuration in advance. Many enterprises rely on this unique feature to scale their TLS deployments cost-effectively and without operational headaches when serving tens of thousands of sites. TLS on-demand is useful if: When TLS on-demand is enabled, you do not need to specify domain names in your configuration in order to obtain certificates for them. Instead, when a TLS handshake is received for a server name (SNI) for which Caddy does not yet have a certificate, the handshake is suspended while Caddy obtains a certificate to use to complete the hand shake. The delay is usually only a few seconds, and only the first handshake is slow. All subsequent handshakes are fast because certificates are cached and reused, and renewals happen in the background. Future handshakes can trigger certificate maintenance to renew it, but this maintenance happens in the background if the certificate hasn't expired yet. Storage Caddy will store public certificates, private keys, and other assets in its configured storage facility. The main thing to know using the default configuration is that the $HOME folder must be writable and persistent. To help troubleshoot, Caddy prints its environment variables on startup if the --environ option is specified. All instances of Caddy that are configured to use the same storage will automatically share these resources and coordinate certificate management as a cluster. Before attempting any ACME transaction, Caddy will test the configured storage to ensure that it is writable and has sufficient capacity. This helps reduce unnecessary lock contention. Performance Compared to Nginx NGINX is a freeware web server and reverse proxy written by Igor Sysoev, whose development began in 2002 for the needs of a very high traffic Russian site. Recognized today for its high performance, stability, advanced feature set, simple configuration, and low resource consumption, Nginx was initially designed as an answer to the performance problem associated with handling 10,000 concurrent connections referred to as the C10k problem. . The latter relates to a desire to optimize network connections to manage a large number of clients at the same time; Nginx uses an asynchronous and event-driven architecture to manage these huge amounts of connections. In terms of performance, Matt Holt, the author of Caddy's web server, seems to have a hard time presenting a convincing result. Indeed, one of the curious responses following research into Caddy's performance is a Caddy forum thread with a response from the author of Caddy: "Caddy is written in Go. It will work just as well as any any other Go web server. Google, Netflix, Cloudflare, Fastly and other large network companies deploy Go on their edge”. the most robust means of ensuring this speed on current processors while making maintenance easy by separating simple tasks executed independently. This design also enables rewrite-free operation on multi-core architectures by immediately exploiting the corresponding power boost. Here are some observations from Matt: For Francis Lavoie, programmer, "official benchmarks for servers don't make sense, not that performance doesn't matter." “Do your own testing, for your own use case. But still, a server should rarely be your bottleneck. Your application's database I/O will be,” says the developer. Source: Caddy And you? Nginx, Apache or Caddy, which of these web servers do you use? What is your opinion on Caddy? Do you have an idea about the performance of Caddy? Do you think Caddy can be an alternative to Nginx? See also: Caddy 2 released, web server supports TLS automatically and by default and reportedly has stronger memory security guarantees than OpenSSL Nginx is now the most used web server by the world's busiest sites, ahead Apache and Microsoft IIS, according to W3Tech Go 1.18, the open source programming language developed by Google, arrives with genericity by default, it will open up new solutions, approaches and paradigms Web servers: Nginx now owns a third share of market while Apache drops below 50%, according to W3Tech