Nginx on Wayne's blog | 偉恩的部落格 | 技術博客

在 CentOS 上安裝 ASP.NET Core + Nginx 的筆記

Tue, 06 Dec 2022 00:00:00 +0000

ASP.NET Core 內建的 Kestrel 伺服器輕巧但功能陽春，實務上需搭配 Reverse Proxy 對外提供服務，Linux 有兩大 Reverse Proxy 選擇：Apache 及 Nginx，這邊筆記一下使用這幾年如日中天的 Nginx。

相較於 Apache、lighttpd，Nginx 標榜單一執行緒、記憶耗用少、穩定性高，強調效能取向，在熱門網站間獨霸一方(參考：維基百科)，與強調效能的 ASP.NET Core 搭配，相得益彰。

以下是我的 CentOS Nginx 安裝設定筆記：

安裝 Nginx。參考：How To Install Nginx on CentOS 7

1
2


sudo yum install epel-release
sudo yum install nginx

發現 CentOS 預設沒裝 telnet 客戶端，檢測查修不便，安裝一下 telnet：

1

sudo yum install telnet

啟動 Nginx

1

sudo systemctl start nginx

啟動後 telnet localhost 80 如有連上就是成功了。如從外部連不上多是防火牆緣故，需額外設定：

1
2
3


sudo firewall-cmd --permanent --zone=public --add-service=http
sudo firewall-cmd --permanent --zone=public --add-service=https
sudo firewall-cmd --reload

設好防火牆，從 Windows 開 Chrome 連上 CentOS 主機 80 Port，如果看到 Nginx 歡迎網頁即代表大功告成。

ASP.NET Core 文件有詳細的Nginx 設定教學，做法是直接修改 /etc/nginx/nginx.conf，在 http 區塊加入 server 設定。

但較模組化的做法是為每個站台寫獨立 conf 檔放在 /etc/nginx/conf.d 下。例如：/etc/nginx/conf.d/default.conf

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


server {
 listen 80;
 server_name linux.darkblog.net; #測試用的自訂網域名稱
 location / {
 proxy_pass http://localhost:5000;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection keep-alive;
 proxy_set_header Host $host;
 proxy_cache_bypass $http_upgrade;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 }
}

設定完畢先用 sudo nginx -t 測試設定檔有沒有被改壞，若 OK 就執行 sudo nginx -s reload 重新載入。

試連時我遇到 502 Bad Gateway 錯誤：

1
2


2018/09/24 15:37:53 [crit] 60137#0: *7 connect() to 127.0.0.1:5000 failed (13: Permission denied) while connecting to upstream, client: 192.168.50.159, server: linux.darkblog.net, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:5000/", host: "linux.darkblog.net"
2018/09/24 15:37:53 [error] 60137#0: *7 no live upstreams while connecting to upstream, client: 192.168.50.159, server: linux.darkblog.net, request: "GET /favicon.ico HTTP/1.1", upstream: "http://localhost/favicon.ico", host: "linux.darkblog.net", referrer: "http://linux.darkblog.net/"

爬文是 Security-Enhanced Linux (SELinux) 作祟，它是 RHEL 6.6+/CentOS 6.6+ 新加的安全鎖，需下指令解除封印：

1

sudo setsebool -P httpd_can_network_connect on

接著要設定 SSL：

有個很威的工具叫 Certbot，可以自動申請、驗證、下載、安裝並定期更新 Let’s Enrypt 憑證。但這部分要將網站正式掛上 Internet 才好測試，真實憑證留待未來再玩，我先做一張自發憑證驗證 SSL 功能。

1
2
3
4


sudo mkdir /etc/ssl/private
sudo chmod 700 /etc/ssl/private
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/nginx-selfsigned.key -out /etc/ssl/certs/nginx-selfsigned.crt
sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

建立一個 /var/nginx/conf.d/ssl.conf

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


server {
 listen 443 http2 ssl;
 listen [::]:443 http2 ssl;

 server_name linux.darkblog.net;

 ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
 ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
 ssl_dhparam /etc/ssl/certs/dhparam.pem;

 location / {
 proxy_pass http://localhost:5000;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection keep-alive;
 proxy_set_header Host $host;
 proxy_cache_bypass $http_upgrade;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 }
}

參考：

NLog.config 路徑配合作業系統要改 "/var/log/Darkblog/$/$.log"
在 Reverse Proxy 模式下 HttpContext.Connection.RemoteIpAddress 會抓到 ::1，而 HttpContext.Connection.RemotePort 則是 5000，並非真實客戶端 IP 及對外 Port。在 Startup.cs 加入 app.UseForwardedHeaders() 可解決問題，但啟用 UseForwardedHeaders() 若未搭配 Reverse Proxy 會有來源 IP 偽造風險，不想冒險也不想針對 IIS / Nginx 調整設定，我想到一招讓程式自動依 OS 決定要不要啟用，一勞永逸：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
 //運行於 Linux 時啟用 Reverse Proxy 模式 
 if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
 {
 app.UseForwardedHeaders(new ForwardedHeadersOptions
 {
 ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
 });
 }
}

線上主機當然不好每次靠手動輸入 dotnet Blah.dll 啟動網站，ASP.NET Core 文件展示了將程式包成服務的方法。先建立 /etc/systemd/system/kestrel-darkblog.service，內容如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


[Unit]
Description=Darkblog.Core Server

[Service]
WorkingDirectory=/var/www/Darkblog
ExecStart=/usr/bin/dotnet /var/www/Darkblog/Darkblog.Core.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
SyslogIdentifier=darkblog-core
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy=multi-user.target

設好 kestrel-darkblog.service 後註冊並啟動服務

1
2
3


sudo systemctl enable kestrel-darkblog.service
sudo systemctl start kestrel-darkblog.service
sudo systemctl status kestrel-darkblog.service

馬上遇到錯誤：

1

(code=exited, status=217/USER) Process: 66571 ExecStart=/usr/bin/dotnet /var/www/Darkblog/Darkblog.Core.dll (code=exited, status=1/FAILURE)

原因是服務模式使用 www-data 身分執行，沒有權限存取 ASP.NET Core 網站所在目錄與檔案。這部分我不是很確定做法，找到的解法是用 chown 將 /var/www/Darkblog 目錄的擁有者及群組都設成 www-data，建立 www-data 帳號及群組，並將我的管理帳號也加入 www-data 群組，如此服務可以存取該目錄，而我也有權限部署檔案。(註：) 以下指令建立 www-data 使用者及群組，將 jeffrey 加入群組，並授與 www-data 群組可以寫入：

1
2
3
4


sudo groupadd www-data
sudo useradd -g www-data www-data
sudo usermod -a -G www-data jeffrey
sudo chmod g+w -R /var/www/Darkblog

有一則小訣竅，以服務方式執行 ASP.NET Core 看不到主控台顯示的錯誤訊息，可改用這個指令來查看：

1

sudo journalctl -fu kestrel-darkblog.service

以上，ASP.NET Core + Nginx on CentOS 執行成功。

附上 CPU / Memory 使用狀況，這是在開瀏覽器狂按 F5 下的數字，總記憶體 1GB，dotnet CPU 在 5% 以下，RAM 耗用不到 10%，有個 kworker CPU 偏高，爬文與硬碟有關，推測與 Win10 Hyper-V VM 不怎麼的虛擬磁碟效能有點關係。但整體數字讓我很滿意，遷都 CentOS 計劃繼續挺進。

nginx CORS 跨域與反向代理

Tue, 23 Aug 2022 00:00:00 +0000

參考文章

CORS跨域

跨域資源共享 - CORS

跨域資源共享(CORS)是一種機制，它使用額外的 HTTP 頭來告訴瀏覽器，讓運行在一個 origin (domain) 上的Web應用被准許訪問來自不同源服務器上的指定的資源。當一個資源從與該資源本身所在的服務器不同的域、協議或端口請求一個資源時，資源會發起一個跨域 HTTP 請求。

比如，站點 http://domain-a.com 的某 HTML 頁面通過 <img> 的 src 請求 http://domain-b.com/image.jpg。網絡上的許多頁面都會加載來自不同域的CSS樣式表，圖像和腳本等資源。

出於安全原因，瀏覽器限制從腳本內發起的跨源HTTP請求。例如，XMLHttpRequest和Fetch API遵循同源策略。這意味著使用這些API的Web應用程序只能從加載應用程序的同一個域請求HTTP資源，除非響應報文包含了正確CORS響應頭。

跨域時部分瀏覽器預設不攜帶cookie，因此為了攜帶cookie需要在前端設定xmlhttprequest的withCrendetalls屬性。

「同源」定義

「同源」定義很簡單，以下三個參數都相同：

1

[protocol]://[domain]:[port]

白話說，當你在 https://www.example.com/product.html 頁面

嘗試對以下路徑發出請求，都違反同源：

http://www.example.com/api/products/40.json
https://www.example2.com/api/products/40.json
https://www.example.com:8080/api/products/40.json

乖孩子遵守同源，不會被打：

https://www.example.com/api/products/40.json

簡單請求和複雜請求

簡單請求與複雜請求的差別是複雜請求會自動發出一個 OPTIONS 的預檢請求，當請求得到確認後，才開始真正發送請求。
綜上，我們要解決兩個問題：

OPTIONS 請求的正確響應
跨域請求正確響應

`OPTIONS` 請求的正確響應

參考網址

解決的方式有多種，既可以在Web Server解決，也可以在源碼層解決。因為問題比較普遍，故我們選擇在Web Server解決，下面我們以 Nginx 為例，說明解決方案。

假設訪問的地址為 `/example` , Nginx 配置如下:

1
2
3
4
5
6
7


location /example {
 proxy_redirect off;
 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_pass http://127.0.0.1:8080/;
}

為了解決跨域問題，添加如下內容:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


location /example {
+ if ($request_method = 'OPTIONS') {
+ add_header Access-Control-Allow-Origin *;
+ add_header Access-Control-Max-Age 1728000;
+ add_header Access-Control-Allow-Methods GET,POST,OPTIONS;
+ add_header Access-Control-Allow-Headers 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
+ add_header Content-Type' 'text/plain; charset=utf-8';
+ add_header Content-Length 0 ;
+ return 204;
+ }


 proxy_redirect off;
 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_pass http://127.0.0.1:8080/;
}

說明：

if ($request_method = 'OPTIONS') {...} 當請求方法為 OPTIONS 時:

添加允許源 Access-Control-Allow-Origin 為 * (可根據業務需要更改)
添加緩存時長 Access-Control-Max-Age，當下次請求時，無需再發送 OPTIONS 請求
添加允許的方法，允許的首部
添加一個內容長度為0，類型為 text/plain; charset=utf-8 , 返回狀態碼為 204 的首部

至此，完成 OPTIONS 請求的正確響應。

跨域請求正確響應

添加如下內容:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


location /example {
 if ($request_method = 'OPTIONS') {
 add_header Access-Control-Allow-Origin *;
 add_header Access-Control-Max-Age 1728000;
 add_header Access-Control-Allow-Methods GET,POST,OPTIONS;
 add_header Access-Control-Allow-Headers 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
 add_header Content-Type' 'text/plain; charset=utf-8';
 add_header Content-Length 0 ;
 return 204;
 }

+ if ($http_origin ~* (https?://(.+\.)?(example\.com$))) {
+ add_header Access-Control-Allow-Origin $http_origin;
+ add_header Access-Control-Allow-Credentials true;
+ add_header Access-Control-Allow-Methods GET,POST,OPTIONS;
+ add_header Access-Control-Expose-Headers Content-Length,Content-Range;
+ }

 proxy_redirect off;
 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_pass http://127.0.0.1:8080/;
}

說明：

if ($http_origin ~* (https?://(.+\.)?(example\.com$))) {...}，當 origin 為合法域名(可根據業務調整或去除合法域名驗證)時:

添加允許源 Access-Control-Allow-Origin 為 $http_origin (可根據業務需要更改)
添加允許認證 Access-Control-Allow-Credentials 為 true ，允許接收客戶端 Cookie(可根據業務需要更改。但要注意，當設置為true時，Access-Control-Allow-Origin 不允許設置為 *)
添加允許的方法，暴露的首部

至此，完成跨域請求正確響應。

以上，是對跨域請求在Web Server的解決方案，主要是通過響應 OPTIONS 方法和添加允許源來解決。

當然，如果本地開發中，可以在利用 webpack-dev-server 的 proxy 選項來快速解決跨域問題：

示例如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// webpack.congf.js

module.exports = {
 //...
 devServer: {
 proxy: {
 '/api': {
 target: 'http://localhost:3000',
 pathRewrite: {'^/api' : ''}
 }
 }
 }
}

當訪問地址如 /api/foo?q=bar 時，則通過代理訪問的實際地址是: http://localhost:3000/foo?q=bar。

Nginx反向代理

nginx反向代理，通過修改nginx配置檔案實現反向代理，請求統一通過nginx分發請求

Nginx配置（192.168.75.139）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


# 負載均衡
 upstream my_site {
 server 192.168.75.138:8080;
 server 192.168.75.137:8080;
 server 192.168.75.136:8080;
 }

 server {
 listen 8081;
 server_name localhost;
 location ^~ /api/ {
 proxy_pass http://my_site/;
 proxy_set_header Host $host;
 proxy_set_header X-Real-ip $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 }
 location = / {
 proxy_pass http://my_site/nginx/indexNginxCrossQuest.jsp;
 }
 location = /nginx/ {
 proxy_pass http://my_site/nginx/;
 proxy_set_header Host $host;
 proxy_set_header X-Real-ip $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 }
 location ~ \.(html|htm|ico|png|jpg|jpeg|js|css|bmp)$ {
 proxy_pass http://my_site;
 }
 error_page 500 502 503 504 /50x.html;
 location = /50x.html {
 root html;
 }
 }

瀏覽器請求（192.168.75.1）

綜合對比

	CORS	Nginx反向代理
前端程式碼配置	credentials=true	無
後端程式碼配置	setHeader：Allow-Origin、Allow-Methods等	無
服務端配置	無	Nginx配置
移植靈活性	高、無額外配置	低、每增加一個環境都需要增加配置
安全性	高、來源可控、直接追溯	X-Forwarded-For追溯多級來源
安全控制	黑白名單	更新配置

nginx 設定 ssl ＋自動續約 Let’s Encrypt 免費域名證書

Tue, 23 Aug 2022 00:00:00 +0000

參考文章

版本一

步驟 1 - 下載安裝及執行的腳本

1
2
3


wget https://dl.eff.org/certbot-auto --no-check-certificate
chmod +x ./certbot-auto
./certbot-auto -n

生成證書，只需要輸入郵件地址和網站根目錄，提示以下內容，說明安裝完成

1
2
3


Saving debug log to /var/log/letsencrypt/letsencrypt.log

Missing command line flags. For non-interactive execution, you will need to specify a plugin on the command line. Run with '--help plugins' to see a list of options, and see https://eff.org/letsencrypt-plugins for more detail on what the plugins do and how to use them.

步驟 2 - nginx設定隱藏目錄訪問

1
2
3


location ~ /.well-known {
 allow all;
}

步驟 3 - 生成域名證書

1

./certbot-auto certonly --email tony@hack.idv.tw --agree-tos --no-eff-email --webroot -w /var/www/ -d hack.idv.tw

到目錄內查看

1

cd /etc/letsencrypt/live/

萬用字元的申請指令 (需要驗證dns)

1

certbot-auto certonly -d *.manpc.tk --manual --preferred-challenges dns

步驟 4 - 設定nginx

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


server {
 listen 80; # IPv4
 listen [::]:80;
 server_name hack.idv.tw ;
 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;
 #rewrite ^(.*) https://$host$1 permanent;
 return 301 https://www.itnotetk.com$request_uri; #跳轉到Https
}

server {
 listen 443 ssl http2;
 server_name hack.idv.tw ;
 ssl on;
 ssl_certificate /etc/letsencrypt/live/hack.idv.tw/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/hack.idv.tw/privkey.pem;
 client_max_body_size 256m;
 ssl_dhparam /etc/nginx/certs/dhparam.pem;
 ssl_session_cache shared:SSL:10m;
 ssl_session_timeout 10m;
 ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
 ssl_stapling on;
 ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA";
 ssl_prefer_server_ciphers on;
 #add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains;preload" always;
 # ...

Let’s Encrypt憑證只有90天需要手動續約

1

0 1 * * * /root/certbot-auto renew --disable-hook-validation --renew-hook "/etc/init.d/nginx reload"

版本二

網路出處

Let’s Encrypt 是一家新的證書頒發機構（Certificate Authority，簡稱 CA），其提供免費的 TLS/SSL 憑證再配合 Certbot 這個自動化工具，讓一般的網站可以很容易地使用 HTTPS 的安全加密網頁，設定很簡單，憑證的更新也可以自動處理。
以下我以 Ubuntu Linux 14.04 的系統為例，示範 nginx 伺服器使用 Let’s Encrypt 憑證設定 HTTPS 安全加密網頁的方法。

步驟 1 - 從 `Certbot` 官方網站下載 `certbot-auto` 指令稿，並設定其執行權限

1
2


wget https://dl.eff.org/certbot-auto
chmod a+x certbot-auto

`certbot-auto` 要放在哪裡都可以，建議一開始就找一個適合的地方放好，例如建立一個 `/opt/letsencrypt` 目錄，把 `certbot-auto` 放在這裡

1
2


mkdir /opt/letsencrypt
mv certbot-auto /opt/letsencrypt/

步驟 2 - 執行 `certbot-auto` ，讓它自動安裝所有相依套件

1

/opt/letsencrypt/certbot-auto

執行 `certbot-auto` 時，會需要輸入密碼取得 root 權限

步驟 3：

安裝完成所有需要的系統套件後，接著我們要透過 webroot 的方式，使用既有的 nginx 網頁伺服器來向 Let’s Encrypt 取得憑證，而在認證的過程會需要在網頁根目錄中建立一個 .well-known/acme-challenge/ 目錄，讓 Let’s Encrypt 的伺服器來讀取其中的內容。
一般的 nginx 伺服器通常會設定把句點開頭的隱藏檔案都擋掉，遇到這樣的狀況就會無法進行認證，這時候可以再加一小段設定，讓 .well-known/acme-challenge/ 目錄可以被正常讀取。

1
2
3
4
5
6


location ^~ /.well-known/acme-challenge/ {
# the usual settings
}
location ~ /\. {
deny all;
}

步驟 4 - 使用 `certonly` 功能下載憑證

1

/opt/letsencrypt/certbot-auto certonly --webroot -w /var/www/blog.gtwang.org/ -d blog.gtwang.org -d gtwang.org

步驟 5 - 輸入自己的 Email 信箱

步驟 6 - 閱讀使用條款，選擇「Agree」繼續

步驟 7 - 下載完成後，會出現類似這樣的成功訊息

1
2
3
4
5
6
7
8


IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/blog.gtwang.org/fullchain.pem. Your cert will
expire on 2016-08-13. To obtain a new version of the certificate in
the future, simply run Certbot again.
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

這樣就成功取得 Let’s Encrypt 的憑證了，而 nginx 用的憑證就儲存在 /etc/letsencrypt/live/blog.gtwang.org/ 目錄之下，其中 fullchain.pem 就是 nginx 需要憑證，而 privkey.pem 則是需要保護好的私鑰，關於憑證檔案的詳細說明，請參考 Certbot 的說明文件。
Certbot 還有提供另外一個 standalone 的方式來向 Let’s Encrypt 取得憑證，這種方式是由 Certbot 建立一個獨立的網頁伺服器，提供 Let’s Encrypt 讀取驗證用的資料，不過這樣的做法需要綁定 80 或 443 連接埠，所以通常還會需要暫停既有的網頁伺服器，對於一般的網站而言，會造成網站有幾秒鐘的斷線現象，所以我個人不喜歡這樣的方式。
接下來要設定 nginx 伺服器，使用這個新憑證來提供 HTTPS 的安全加密網頁。

步驟 8 - 要讓 `nginx` 啟用 `HTTPS` 安全加密網頁，只要加上 `SSL` 相關的幾行設定即可，其餘的設定保持不變，以下是我個人使用的 `nginx` 伺服器設定

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


server {
 # 傾聽 HTTPS 標準埠號 443
 listen 443;

 # 同時啟用 IPv6 的 HTTPS 安全加密網頁
 listen [::]:443;

 server_name blog.gtwang.org;
 root /var/www/blog.gtwang.org/;
 index index.php index.html index.htm;

 # 啟用 SSL
 ssl on;

 # 設定 SSL 憑證
 ssl_certificate /etc/letsencrypt/live/blog.gtwang.org/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/blog.gtwang.org/privkey.pem;

 # 其他 SSL 選項
 ssl_session_timeout 5m;
 ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # omit SSLv3 because of POODLE (CVE-2014-3566)
 ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
 ssl_prefer_server_ciphers on;

 # ...
}

`ssl_protocols` 的部分記得要把SSLv3拿掉，避免 `POODLE` 攻擊（CVE-2014-3566）。

步驟 9 - 設定好之後，檢查一下設定檔是否正確

1

service nginx configtest

步驟 10 - 確認無誤之後，重新載入設定檔

1

service nginx reload

這樣就完成 nginx 伺服器的設定了，接著就可以開啟 HTTPS 加密的網址來測試了，正常來說，使用 Google Chrome 瀏覽器開啟自己主機的 HTTPS 加密網址，應該就會顯示一個綠色的鎖頭，這樣就代表我們安裝的 SSL 憑證是有效的。

`Let’s Encrypt` 的憑證使用期限只有三個月，在憑證到期前的一個月可以使用 `certbot-auto` 來更新憑證，在實際更新之前我們可以加入 `--dry-run` 參數，先進行測試。

1

/opt/letsencrypt/certbot-auto renew --dry-run

若測試沒問題，就可以使用正式指令來更新

1

/opt/letsencrypt/certbot-auto renew --quiet --no-self-upgrade

而為了方便起見，可以將這個更新指令寫在 /opt/letsencrypt/renew.sh 指令稿中

1
2


#!/bin/sh
/opt/letsencrypt/certbot-auto renew --quiet --no-self-upgrade --post-hook "service nginx reload"

這裡我又加上一個 --post-hook 的設定，讓憑證更新完後，可以自動重新載入 nginx 伺服器的設定，讓憑證生效。
接著把這個 /opt/letsencrypt/renew.sh 指令稿寫進 crontab 中

1
2


# m h dom mon dow command
30 2 * * 0 /opt/letsencrypt/renew.sh

Nginx on Wayne's blog | 偉恩的部落格 | 技術博客

在 CentOS 上安裝 ASP.NET Core + Nginx 的筆記

nginx CORS 跨域與反向代理

參考文章

CORS跨域

跨域資源共享 - CORS

跨域時部分瀏覽器預設不攜帶cookie，因此為了攜帶cookie需要在前端設定xmlhttprequest的withCrendetalls屬性。

「同源」定義

簡單請求和複雜請求

OPTIONS 請求的正確響應

解決的方式有多種，既可以在Web Server解決，也可以在源碼層解決。因為問題比較普遍，故我們選擇在Web Server解決，下面我們以 Nginx 為例，說明解決方案。

假設訪問的地址為 /example , Nginx 配置如下:

為了解決跨域問題，添加如下內容:

說明：

跨域請求正確響應

說明：

Nginx反向代理

Nginx配置（192.168.75.139）

瀏覽器請求（192.168.75.1）

綜合對比

nginx 設定 ssl ＋ 自動續約 Let’s Encrypt 免費域名證書

參考文章

版本一

步驟 1 - 下載安裝及執行的腳本

生成證書，只需要輸入郵件地址和網站根目錄，提示以下內容，說明安裝完成

步驟 2 - nginx設定隱藏目錄訪問

步驟 3 - 生成域名證書

到目錄內查看

萬用字元的申請指令 (需要驗證dns)

步驟 4 - 設定nginx

Let’s Encrypt憑證只有90天 需要手動續約

版本二

步驟 1 - 從 Certbot 官方網站下載 certbot-auto 指令稿，並設定其執行權限

certbot-auto 要放在哪裡都可以，建議一開始就找一個適合的地方放好，例如建立一個 /opt/letsencrypt 目錄，把 certbot-auto 放在這裡

步驟 2 - 執行 certbot-auto ，讓它自動安裝所有相依套件

執行 certbot-auto 時，會需要輸入密碼取得 root 權限

步驟 3：

步驟 4 - 使用 certonly 功能下載憑證

步驟 5 - 輸入自己的 Email 信箱

步驟 6 - 閱讀使用條款，選擇「Agree」繼續

步驟 7 - 下載完成後，會出現類似這樣的成功訊息

步驟 8 - 要讓 nginx 啟用 HTTPS 安全加密網頁，只要加上 SSL 相關的幾行設定即可，其餘的設定保持不變，以下是我個人使用的 nginx 伺服器設定

ssl_protocols 的部分記得要 把SSLv3拿掉 ，避免 POODLE 攻擊（CVE-2014-3566）。

步驟 9 - 設定好之後，檢查一下設定檔是否正確

步驟 10 - 確認無誤之後，重新載入設定檔

Let’s Encrypt 的憑證使用期限只有三個月，在憑證到期前的一個月可以使用 certbot-auto 來更新憑證，在實際更新之前我們可以加入 --dry-run 參數，先進行測試。

`OPTIONS` 請求的正確響應

假設訪問的地址為 `/example` , Nginx 配置如下:

nginx 設定 ssl ＋自動續約 Let’s Encrypt 免費域名證書

Let’s Encrypt憑證只有90天需要手動續約

步驟 1 - 從 `Certbot` 官方網站下載 `certbot-auto` 指令稿，並設定其執行權限

`certbot-auto` 要放在哪裡都可以，建議一開始就找一個適合的地方放好，例如建立一個 `/opt/letsencrypt` 目錄，把 `certbot-auto` 放在這裡

步驟 2 - 執行 `certbot-auto` ，讓它自動安裝所有相依套件

執行 `certbot-auto` 時，會需要輸入密碼取得 root 權限

步驟 4 - 使用 `certonly` 功能下載憑證

步驟 8 - 要讓 `nginx` 啟用 `HTTPS` 安全加密網頁，只要加上 `SSL` 相關的幾行設定即可，其餘的設定保持不變，以下是我個人使用的 `nginx` 伺服器設定

`ssl_protocols` 的部分記得要把SSLv3拿掉，避免 `POODLE` 攻擊（CVE-2014-3566）。

`Let’s Encrypt` 的憑證使用期限只有三個月，在憑證到期前的一個月可以使用 `certbot-auto` 來更新憑證，在實際更新之前我們可以加入 `--dry-run` 參數，先進行測試。