/munetakaJupyterHub/Computer/2024/Nginx/upstream-xxx.md

# port 43410, 玉雪工作会報@h2nas03.yushei.com.tw 
upstream ysMeeting {
#       server h2nas03.yushei.com.tw:43410 weight=1;
        server 192.168.2.197:43410 weight=1;
}

server {
     server_name  munetaka.me:43410;
     charset utf-8;

     location / {
         proxy_pass http://ysMeeting;
     }

     listen 43410 ssl; # managed by Certbot
     ssl_certificate /etc/letsencrypt/live/munetaka.me/fullchain.pem; # managed by Certbot
     ssl_certificate_key /etc/letsencrypt/live/munetaka.me/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
}

# port 43889, h2jammy.yushei.net:43889 CaddyServer
upstream CaddyServer {
        server h2jammy.yushei.net:43889 weight=1;
}

server {
     server_name  munetaka.me:43889;
     charset utf-8;

     location / {
        proxy_pass http://CaddyServer;
        # proxy_set_header Host $host;
        # proxy_set_header X-Real-IP $remote_addr;
        # proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        # proxy_set_header X-Forwarded-Proto $scheme;

     }

     listen 43889 ssl; # managed by Certbot
     ssl_certificate /etc/letsencrypt/live/munetaka.me/fullchain.pem; # managed by Certbot
     ssl_certificate_key /etc/letsencrypt/live/munetaka.me/privkey.pem; # managed by Certbot

¶test set up

https://munetaka.me:43410

alexlai@opi58G:~$ curl -v https://munetaka.me:43410
* Host munetaka.me:43410 was resolved.
* IPv6: fe80::99ac:c8e9:8e35:ba39
* IPv4: 114.33.29.69
*   Trying 114.33.29.69:43410...
* Connected to munetaka.me (114.33.29.69) port 43410
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: CN=munetaka.me
*  start date: Apr 21 03:37:59 2024 GMT
*  expire date: Jul 20 03:37:58 2024 GMT
*  subjectAltName: host "munetaka.me" matched cert's "munetaka.me"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/1.x
> GET / HTTP/1.1
> Host: munetaka.me:43410
> User-Agent: curl/8.5.0
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/1.1 404 Not Found
< Server: nginx/1.26.0
< Date: Sat, 04 May 2024 00:06:30 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 27312
< Connection: keep-alive
< accept-ranges: bytes
< last-modified: Thu, 02 May 2024 08:18:42 GMT

GPT,

Based on the Curl output you provided, it appears that the site "munetaka.me" is indeed secured using HTTPS. Here's why:

- HTTPS Protocol: The URL you accessed starts with "https://", indicating that the communication between your Curl command and the server is encrypted.
TLS Handshake: The Curl output shows that a TLS handshake was successfully completed, using TLSv1.3 protocol. This handshake establishes a secure connection between the client (your Curl command) and the server.
Server Certificate: The output includes information about the SSL certificate used by the server. It states that the certificate is issued by Let's Encrypt, which is a widely recognized certificate authority, and it verifies that the SSL connection is okay.
SSL Connection: The SSL connection is using strong encryption algorithms, including TLS_AES_256_GCM_SHA384.
HTTP Response: Finally, the HTTP response from the server includes headers indicating that the server is running nginx/1.26.0 and returns a 404 Not Found status, but the fact that it responds via HTTPS confirms that the site is indeed secured.
So yes, based on the provided Curl output, the website "munetaka.me" is secured using HTTPS.

alexlai@opi58G:~$ curl -v https://munetaka.me:43889
* Host munetaka.me:43889 was resolved.
* IPv6: fe80::99ac:c8e9:8e35:ba39
* IPv4: 114.33.29.69
*   Trying 114.33.29.69:43889...
* Connected to munetaka.me (114.33.29.69) port 43889
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: CN=munetaka.me
*  start date: Apr 21 03:37:59 2024 GMT
*  expire date: Jul 20 03:37:58 2024 GMT
*  subjectAltName: host "munetaka.me" matched cert's "munetaka.me"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/1.x
> GET / HTTP/1.1
> Host: munetaka.me:43889
> User-Agent: curl/8.5.0
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/1.1 200 OK
< Server: nginx/1.26.0
< Date: Sat, 04 May 2024 00:09:50 GMT
< Content-Length: 0
< Connection: keep-alive
< 
* Connection #0 to host munetaka.me left intact
alexlai@opi58G:~$ curl -v https://munetaka.me:43889
* Host munetaka.me:43889 was resolved.
* IPv6: fe80::99ac:c8e9:8e35:ba39
* IPv4: 114.33.29.69
*   Trying 114.33.29.69:43889...
* Connected to munetaka.me (114.33.29.69) port 43889
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: CN=munetaka.me
*  start date: Apr 21 03:37:59 2024 GMT
*  expire date: Jul 20 03:37:58 2024 GMT
*  subjectAltName: host "munetaka.me" matched cert's "munetaka.me"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/1.x
> GET / HTTP/1.1
> Host: munetaka.me:43889
> User-Agent: curl/8.5.0
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
^C
alexlai@opi58G:~$ curl -v https://munetaka.me:43889
* Host munetaka.me:43889 was resolved.
* IPv6: fe80::99ac:c8e9:8e35:ba39
* IPv4: 114.33.29.69
*   Trying 114.33.29.69:43889...
* Connected to munetaka.me (114.33.29.69) port 43889
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: CN=munetaka.me
*  start date: Apr 21 03:37:59 2024 GMT
*  expire date: Jul 20 03:37:58 2024 GMT
*  subjectAltName: host "munetaka.me" matched cert's "munetaka.me"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/1.x
> GET / HTTP/1.1
> Host: munetaka.me:43889
> User-Agent: curl/8.5.0
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/1.1 200 OK
< Server: nginx/1.26.0
< Date: Sat, 04 May 2024 00:10:07 GMT
< Content-Length: 0
< Connection: keep-alive
< 
* Connection #0 to host munetaka.me left intact

Based on the Curl output you provided, it seems that the website "munetaka.me" on port 43889 is not responding with any HTTP content. The output terminates abruptly without any HTTP response status or headers, which suggests that the server may not be configured to serve content on this particular port or it may not be reachable.

Since there's no HTTP response to analyze, we cannot determine if the site is secured or not based solely on this Curl output.

To verify if the site is secured, you would typically look for the same indicators mentioned earlier, such as HTTPS in the URL, successful TLS handshake, and valid SSL certificate. However, in this case, there's no HTTP response to inspect.

You might want to verify if the port number (43889) is correct and if the server is configured to serve content on that port. Additionally, ensure that there are no firewall rules or network configurations blocking access to the server on that port.