问题[lets-encrypt](server)

我正在尝试使用 DNS 验证请求 LetsEncrypt 证书。我的 DNS 提供商是 Google DNS。无论我做什么，我都会不断收到以下错误：

 [EROR] File C:\LetsEncrypt\{GCP-ServiceAccountKey} does not exist

{GCP-ServiceAccountKey}我从 GCP Cloud 控制台生成的密钥在哪里？

以下是我正在运行的用于尝试生成证书请求的命令：

.\wacs.exe --target manual --host adfs.public-facing.com --installation script --script ".\Scripts\ImportADFS.ps1" --scriptparameters "'{CertThumbprint}'" --validation gcpdns --serviceaccountkey {Purposely-removed-ServiceAccountKey} --projectid {Purposely-removed-ProjectId} --verbose

我在这里拔掉我的头发。我做错了什么或错过了什么？

我有一个每天运行命令的脚本 certbot --nginx -d $DOMAIN

为许多域更新他们的证书

You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/****.conf)

What would you like to do?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Attempt to reinstall this existing certificate
2: Renew & replace the certificate (may be subject to CA rate limits)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): Cert not yet due for renewal

如果证书即将到期，我总是选择 1。是否有一个标志可以传递给命令以使其始终选择 1？

是否可以/建议通过 Nginx for https 注册和更新 Let's Encrypt 证书，并在同一域上的 websocket 连接 (wss://) 上共享相同的证书？websocket 服务器正在运行 node.js（具体来说是 Colyseus - 它内置了 Express）

如果没有，是否值得将 Nginx 设置为 websocket 服务器前面的反向代理并以这种方式设置证书？

最后，如果只使用一个证书并与 websocket 服务器共享是个好主意，那么当 certbot 更新证书时让 Express 重新加载文件的最佳方法是什么？certbot 可以通知服务器它更新了证书吗？或者文件是否需要重新加载

我们有一个服务器（在 Ubuntu 20.04 上运行）可从子域 myserver.university.country 访问，我想在服务器上安装 SSL/TLS 证书以加密与服务器的连接。这是我第一次管理服务器，当我四处询问（老板、队友）时，没有人有专业知识可以提供帮助。

我们目前为一些需要通过一些非标准端口（即不是 80 或 443，例如 myserver.university.country:8687）登录的网站提供服务，这些端口不通过 apache 或其他主要服务器软件提供服务（我们使用Shiny Server）。浏览器在没有锁的情况下显示不安全的连接。我们不希望登录凭据被盗或外人可以访问信息。

我们正在尝试使用 Let's encrypt via certbot来获取我们服务器的证书。根据 certbot 文档，这需要打开端口 80（我们不想访问它）。

安全团队不想向整个 Internet 开放端口 80，并且希望限制对某些 IP 范围的访问。此外，他们只想在短时间内打开它，我的理解是这会阻止证书的自动更新。但是，certbot没有指定范围，可能会使用多个 IP。

我们如何才能安全地连接到我们的服务器（使用免费资源）？

我已经超出了我的深度，不知道如何为此正确配置服务器并解决 IT 问题。

我有一个带有 Nginx Ingress 的自托管 Kubernetes 集群。Cert-manager 也在集群上运行，我尝试使用 Letsencrypt 获取有效的 SSL 证书。一切正常，我获得了 example.com、www.example.com或 app1.example.com 的有效证书，但不适用于通用通配符 *.example.com。如果我尝试以任何方式在 sec.tls.hosts 下的入口中输入通配符，则不会为我生成证书。我得到输出

kubectl get certificate

NAME              READY   SECRET            AGE
tls-test-cert     False   tls-electi-cert   20h

kubectl get CertificateRequest

NAME                    APPROVED   DENIED   READY   ISSUER                REQUESTOR                                         AGE
tls-test-cert-8jw75     True                False   letsencrypt-staging   system:serviceaccount:cert-manager:cert-manager   18m

kubectl describe CertificateRequest

[...]
Status:
  Conditions:
    Last Transition Time:  2022-02-27T13:54:38Z
    Message:               Certificate request has been approved by cert-manager.io
    Reason:                cert-manager.io
    Status:                True
    Type:                  Approved
    Last Transition Time:  2022-02-27T13:54:38Z
    Message:               Waiting on certificate issuance from order gateway/tls-test-cert-8jw75-1425588341: "pending"
    Reason:                Pending
    Status:                False
    Type:                  Ready
Events:
  Type    Reason           Age   From          Message
  ----    ------           ----  ----          -------
  Normal  cert-manager.io  18m   cert-manager  Certificate request has been approved by cert-manager.io
  Normal  OrderCreated     18m   cert-manager  Created Order resource gateway/tls-test-cert-8jw75-1425588341
  Normal  OrderPending     18m   cert-manager  Waiting on certificate issuance from order gateway/tls-test-cert-8jw75-1425588341: ""

我的 Nginx 入口：（我将我的域交换到 example.com 以获取这篇文章）

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-management
  namespace: gateway
  annotations:
    kubernetes.io/ingress.class: nginx
    cert-manager.io/cluster-issuer: "letsencrypt-staging"
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/backend-protocol: "HTTP"
spec:
  ingressClassName: nginx
  tls:
  - secretName: tls-test-cert
    hosts:
      - example.com
      - '*.example.com'
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: test-gateway
                port:
                  number: 80
    - host: '*.example.com'
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: test-gateway
                port:
                  number: 80

发行人：（我在这里编辑了我的电子邮件）

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt-staging
  namespace: cert-manager
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email: *******
    privateKeySecretRef:
      name: letsencrypt-staging
    solvers:
      - http01:
          ingress:
            class: nginx

我的反向代理（测试网关）肯定可以工作并将所有子域转发到我的网站。提前感谢您对可能导致此问题的任何想法。

我正在尝试为letsencrypt挑战调试我的DNS设置。

我知道 BIND9 可能没有收到请求，尽管它是在当天早些时候。不幸的是，.jnl 没有被创建。

我想知道的是如何从远程计算机发送请求以最终查看另一端发生了什么故障。letencrypt 如何向我们发送 TXT 字段更新？我可以运行哪些命令行命令？

这将等效于nsupdate命令，但来自远程计算机。

我在 Google Cloud CentOS 7 上有一个 Spring Boot 应用程序。我希望通过 Let's Encrypt 和 Certbot 安装 SSL 证书。当我使用certbot --apache -d mydomain.zone命令时，我收到一个错误：

我的域名在 Namecheap 上注册。我在 Google Cloud 上的 A 记录：

我还像本教程一样在 Namecheap 中提供了谷歌云名称服务器：https ://www.wpmentor.com/setup-domain-google-cloud-platform/

你能告诉我问题出在哪里吗？我也想知道我的应用程序中的 java 代码是否有问题。例如，有时在访问索引页时，会调用 error_page。当我的控制器中有一个方法时：

@RequestMapping(value = "/error_page", method = RequestMethod.GET)
public String homeError(Model model)
{
  return "/error_page";
}

我有一个不同的 certvbot 错误：

但是当我评论/删除错误页面的控制器方法时，我收到此错误：

可能是应用程序错误吗？还是apache的问题？

我试图关闭Tomcat。现在我收到此错误：

注意：我的 Apache 转发到 8080，不知道会不会有问题？

iptables -A PREROUTING -t nat -p tcp --dport 80 -j REDIRECT --to-port  8080

在我的服务器上，我拥有在 public_html 文件夹上设置的特殊权限。

首先是粘性位

chmod g+s /home/domain.com/public_html

也是默认组权限。

setfacl -m 'default:group::rwX' /home/domain.com/public_html

当我运行我的 certbot 命令时

certbot certonly \
        --webroot \
        -w /home/domain.com/public_html/ -d domain.com

certbot 将在 public_html 文件夹中创建一个具有正确权限的 .well-known/acme-challenge。它甚至保留正确的组名。但是，acme 挑战本身将具有以下内容。

-rw-r-----  1 root                 root                   87 Feb  7 17:27 ELnik5A0krJsKUsL2If1mVfd2pSzWJAiSSjhA6h-f5E

它由 root 拥有并且具有组 root 并且不能被 apache2 读取。所以整个操作失败了。

添加 --debug-challenges 将允许它暂停，以便我可以手动修复它，但我觉得更新可能是一个问题。

我有什么选择来解决这个问题？

这必须是重复的，但是我已经搜索了很长时间，但没有找到任何东西。

当我使用http输入我的网站地址时，我得到NginX 默认页面（https 可以正常工作）：

http://svija.love

NginX 配置文件最后包含：

server {
    if ($host = svija.love) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    server_name svija.love;
    listen 80;
    return 404; # managed by Certbot
}

这是由 Certbot 自动添加的。

我希望语句if ($host = svija.love)会捕获 http 请求并重定向到 HTTPS。

但它不是那样工作的。

不是专家，在我看来，从server_name svija.love开始的第二部分与第一部分直接矛盾：

• 如果主机是 svija.love，则第一个块重定向
• 如果主机是 svija.love，则第二个块返回 404

实际配置的服务器名称是live.svija.love，如果有区别的话。

任何澄清将不胜感激。

[更新]我删除了 NginX 默认配置文件，HTTP 现在按预期重定向到 HTTPS。

不过，如果有人能解释上面的两个配置块，我很想更好地理解他们在做什么。

[更新]这不是一个好的解决方案（见下文）。

[更新这是nginx -T给出的配置：

# configuration file /etc/nginx/nginx.conf:
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
    worker_connections 768;
    # multi_accept on;
}

http {

    ##
    # Basic Settings
    ##

    sendfile off;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    # server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ##
    # SSL Settings
    ##

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
    ssl_prefer_server_ciphers on;

    ##
    # Logging Settings
    ##

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    ##
    # Gzip Settings
    ##

    gzip on;

    # gzip_vary on;
    # gzip_proxied any;
    # gzip_comp_level 6;
    # gzip_buffers 16 8k;
    # gzip_http_version 1.1;
    # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

    ##
    # Virtual Host Configs
    ##

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

# configuration file /etc/nginx/modules-enabled/50-mod-http-image-filter.conf:
load_module modules/ngx_http_image_filter_module.so;

# configuration file /etc/nginx/modules-enabled/50-mod-http-xslt-filter.conf:
load_module modules/ngx_http_xslt_filter_module.so;

# configuration file /etc/nginx/modules-enabled/50-mod-mail.conf:
load_module modules/ngx_mail_module.so;

# configuration file /etc/nginx/modules-enabled/50-mod-stream.conf:
load_module modules/ngx_stream_module.so;

# configuration file /etc/nginx/mime.types:

server {

    # must match domain name or IP address
    # or else the default Nginx page will be shown
    server_name antretoise.svija.site;

    # directory of site's static elements
    location /static/ {
        root /home/antretoise;
    }

    access_log /opt/logs/access.antretoise;
    error_log /opt/logs/error.antretoise error;

    # pass all additional queries to our application
    location / {

        # parameters from /etc/nginx/uwsgi_params
        include uwsgi_params;

        # pass the traffic to the socket
        # that the uWSGI server sets up
        # SOCKETS MUST MATCH IN:
        # /etc/uwsgi/sites/antretoise.ini
        uwsgi_pass unix:/run/uwsgi/antretoise.sock;
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/antretoise.svija.site/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/antretoise.svija.site/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}


server {
    if ($host = antretoise.svija.site) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    server_name antretoise.svija.site;
    return 404; # managed by Certbot


}
# configuration file /etc/nginx/uwsgi_params:

uwsgi_param  QUERY_STRING       $query_string;
uwsgi_param  REQUEST_METHOD     $request_method;
uwsgi_param  CONTENT_TYPE       $content_type;
uwsgi_param  CONTENT_LENGTH     $content_length;

uwsgi_param  REQUEST_URI        $request_uri;
uwsgi_param  PATH_INFO          $document_uri;
uwsgi_param  DOCUMENT_ROOT      $document_root;
uwsgi_param  SERVER_PROTOCOL    $server_protocol;
uwsgi_param  REQUEST_SCHEME     $scheme;
uwsgi_param  HTTPS              $https if_not_empty;

uwsgi_param  REMOTE_ADDR        $remote_addr;
uwsgi_param  REMOTE_PORT        $remote_port;
uwsgi_param  SERVER_PORT        $server_port;
uwsgi_param  SERVER_NAME        $server_name;

ssl_session_cache shared:le_nginx_SSL:10m;
ssl_session_timeout 1440m;
ssl_session_tickets off;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

ssl_ciphers "EC-AES128-SHA";

#———————————————————————————————————————— default

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    root /var/www/html;

    # Add index.php to the list if you are using PHP
    index index.html index.htm index.nginx-debian.html;

    server_name _;

    location / {
        # First attempt to serve request as file, then
        # as directory, then fall back to displaying a 404.
        try_files $uri $uri/ =404;
    }

}

#———————————————————————————————————————— svija.love

server {

    server_name svija.love;

    # directory of site's static elements
    location /static/ {
        root /home/svijalove;
    }

    access_log /opt/logs/access.svijalove;
    error_log /opt/logs/error.svijalove error;

    # pass all additional queries to our application
    location / {

        # parameters from /etc/nginx/uwsgi_params
        include uwsgi_params;

        # pass the traffic to the socket
        # that the uWSGI server sets up
        # SOCKETS MUST MATCH IN:
        # /etc/uwsgi/sites/svijalove.ini
        uwsgi_pass unix:/run/uwsgi/svijalove.sock;
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/svija.love/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/svija.love/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

server {
    if ($host = svija.love) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    server_name svija.love;
    listen 80;
    return 404; # managed by Certbot
}

# 6 other sites at end, all configured the same way
# except that in the last two lines,
# listen 80; is sometimes listed BEFORE return 404;

我的情况是，我有一台在家庭网络内运行的服务器，可以通过 VPN（Zerotier）从外部连接。该网络通过 NAT 连接到 Internet，因此没有真正的公共 IP。

现在有一些服务需要 HTTPS。同样使用自签名证书也会很麻烦，因为其他一些服务正在容器内运行（并且为每个人添加根 CA 可能会很痛苦）。例如，我drone在一个容器内运行，它需要gitea通过 https 协议（或至少文档中提到的）与服务器通信。

所以我需要一个有效的证书来运行这些服务。

我确实拥有一些域名和几个由托管服务提供商运营的网站。

现在我想知道我有哪些选择来获得运行我的 Intranet 网站的证书？