คำถามติดแท็ก lets-encrypt

Let's Encrypt เป็นผู้ออกใบรับรองที่ให้ใบรับรอง X.509 ฟรีสำหรับการเข้ารหัส TLS

7
จะใช้การตรวจสอบความท้าทาย Let's Encrypt DNS ได้อย่างไร
Let's Encrypt ประกาศว่าพวกเขามี: เปิดการรองรับความท้าทาย ACME DNS ฉันจะ./letsencrypt-autoสร้างใบรับรองใหม่โดยใช้การตรวจสอบความถูกต้องของโดเมน DNS ได้อย่างไร แก้ไข ฉันหมายถึง: ฉันจะหลีกเลี่ยงการhttp/httpsผูกพอร์ตได้อย่างไรโดยใช้คุณสมบัติประกาศใหม่ (2015-01-20) ที่ช่วยให้คุณพิสูจน์ความเป็นเจ้าของโดเมนโดยการเพิ่มระเบียน TXT เฉพาะในโซน DNS ของโดเมนเป้าหมาย
160 lets-encrypt 


2
ให้เข้ารหัสด้วยพร็อกซีย้อนกลับ nginx
บทนำ ฉันมีเซิร์ฟเวอร์ dev (ปัจจุบันใช้งาน Ubuntu 14.04 LTS) ซึ่งฉันใช้มาระยะหนึ่งแล้วเพื่อใช้เป็นเครื่องมือในการพัฒนาบนพอร์ตต่างๆ เนื่องจากพอร์ตอาจจำยากฉันจึงตัดสินใจใช้พอร์ต 80 สำหรับบริการทั้งหมดของฉันและทำการส่งต่อพอร์ตภายในโดยใช้ชื่อโฮสต์ แทนที่จะเขียน domain.com:5432 ฉันสามารถเข้าถึงผ่าน sub.domain.com ตัวอย่างเช่นแอ็พพลิเคชัน X ซึ่งใช้พอร์ต 7547 และกำลังรันบน sub.domain.com มีการกำหนดค่า nginx ต่อไปนี้: upstream sub { server 127.0.0.1:7547; } server { listen 80; server_name sub.domain.com www.sub.domain.com; access_log /var/log/nginx/sub.log combined; location / { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header …

5
SSL & Ngnix: ไม่มี“ ssl_certificate” ถูกกำหนดในการฟังเซิร์ฟเวอร์บนพอร์ต SSL ในขณะที่จับมือ SSL
ฉันจัดการเพื่อสร้างใบรับรองด้วย LE โดยไม่มีข้อผิดพลาดฉันยังจัดการเปลี่ยนเส้นทางปริมาณการใช้งานของฉันจากพอร์ต 80 ไปยังพอร์ต 443 แต่เมื่อฉันรีโหลดเซิร์ฟเวอร์ nginx ของฉันฉันไม่สามารถเข้าถึงเว็บไซต์ของฉันได้ บันทึกข้อผิดพลาด Ngnix แสดงบรรทัดนี้: 4 no "ssl_certificate" is defined in server listening on SSL port while SSL handshaking, client: 192.168.0.104, server: 0.0.0.0:443 ฉันคิดว่านี่หมายความว่าไม่ได้หาใบรับรองที่ฉันไปแล้วไปที่เส้นทางของใบรับรองและทั้งคู่อยู่ที่นั่นสิ่งที่อาจเป็นปัญหา นี่คือลักษณะการกำหนดค่า Ngnix ของฉัน: server { listen 80; server_name pumaportal.com www.pumaportal.com; return 301 https://$server_name$request_uri; } server { listen 443 ssl; …

5
ฉันจะเปลี่ยนอีเมลผู้ดูแลระบบสำหรับเข้ารหัสได้อย่างไร
ที่อยู่อีเมลที่ใช้เป็นอีเมลของผู้ดูแลระบบเมื่อเราเริ่มต้นใช้งานการเข้ารหัสขอให้ต้องมีการแก้ไข (อดีตพนักงานใช้ที่อยู่อีเมลส่วนตัวของเขาเป็นอีเมลผู้ดูแลระบบและเขาไม่ได้อยู่กับ บริษัท อีกต่อไป) ขั้นตอนใดที่ต้องดำเนินการเพื่อแก้ไข (เราสามารถรับอดีตพนักงานเพื่อยืนยันสิ่งนี้) เราจำเป็นต้องลบที่อยู่อีเมลส่วนตัวของเขาและแทนที่ด้วยที่อยู่อีเมลใหม่ สิ่งนี้จะถูกใช้สำหรับการดำเนินการกู้คืนที่สำคัญ ไม่ว่าในกรณีใดฉันต้องการลบที่อยู่อีเมลส่วนตัวของอดีตพนักงาน ขั้นตอนใดที่ฉันต้องดำเนินการเพื่อให้บรรลุเป้าหมายนี้ (หากความเข้าใจในกระบวนการไม่ถูกต้องโปรดนำฉันไปในทิศทางที่ถูกต้อง) ขอบคุณล่วงหน้า.

2
เหตุใดจึงไม่ตรวจสอบใบรับรองที่ลงนามด้วยตนเองผ่านบันทึก DNS แทนที่จะเป็น letsencrypt
ฉันแค่สงสัย เราใช้ใบรับรอง SSL จำนวนมาก ทุกวันนี้เราเกือบจะใช้ letsencrypt (ขอบคุณ!) บรรทัดล่างสุดของใบรับรองเหล่านี้คือหลักฐานการเป็นเจ้าของชื่อโดเมนในใบรับรองนั้นมาจากอำนาจในการจัดการระเบียน DNS หรือเว็บไซต์ภายใต้โดเมนเหล่านี้ หลักฐาน DNS มาจากการเพิ่มคีย์ (ที่ได้รับจาก allowencrypt) เป็นระเบียน TXT ไปยัง DNS ดังนั้นหากมีหลักฐานเพียงพอที่จะสามารถเปลี่ยนระเบียน DNS สำหรับโดเมนทำไมไม่ใช้ใบรับรองที่ลงชื่อด้วยตนเองด้วยลายนิ้วมือใน DNS ฉันจะบอกว่าสิ่งนี้ให้ความเชื่อมั่นในปริมาณเท่ากันกับขั้นตอนการใช้ DNS ของ allowencrypt (และ CA อื่น ๆ ): สร้าง CA ที่เซ็นชื่อด้วยตนเอง (เพียงทำตามขั้นตอนของวิธีการต่างๆ) สร้างใบรับรองสำหรับบางโดเมน เซ็นชื่อใบรับรองจากขั้นตอนที่ 2 ด้วย CA จากขั้นตอนที่ 1 ตอนนี้คุณมีใบรับรองพื้นฐานที่ลงชื่อโดย CA ที่ไม่น่าเชื่อถือ เพิ่มระเบียน TXT (หรือเฉพาะ) ไปยัง …

1
มาเข้ารหัสการตรวจสอบ certbot ผ่าน HTTPS
จากเอกสารของปลั๊กอินเว็บรูท Certbot ปลั๊กอิน webroot ทำงานได้โดยการสร้างไฟล์ชั่วคราวสำหรับแต่ละโดเมนที่คุณขอ${webroot-path}/.well-known/acme-challengeมา จากนั้นเซิร์ฟเวอร์การตรวจสอบความถูกต้องของ Let's Encrypt จะทำการร้องขอ HTTP เพื่อตรวจสอบว่า DNS สำหรับแต่ละโดเมนที่ร้องขอแก้ไขไปยังเซิร์ฟเวอร์ที่ใช้ certbot บนเซิร์ฟเวอร์ภายในบ้านที่ใช้ส่วนตัวฉันปิดใช้งานพอร์ต 80 นั่นคือไม่มีการส่งต่อพอร์ตในเราเตอร์ ฉันไม่มีความตั้งใจที่จะเปิดพอร์ตนั้น ฉันจะบอก certbot ว่าเซิร์ฟเวอร์การตรวจสอบความถูกต้องไม่ควรทำการร้องขอ HTTP แต่เป็นการร้องขอ HTTPS (พอร์ต 443) เพื่อตรวจสอบความเป็นเจ้าของโดเมน เซิร์ฟเวอร์การตรวจสอบไม่ควรมีความจำเป็นในการตรวจสอบใบรับรองของโฮมเซิร์ฟเวอร์เนื่องจากใช้ HTTP เป็นค่าเริ่มต้นแล้ว ฉันอาจมีใบรับรองที่ลงนามเองหรือใบรับรองที่ต่ออายุได้ แต่ไม่ควรสำคัญ ขณะนี้ฉันอยู่ในสถานการณ์ที่ฉันจำเป็นต้องเปิดใช้งานการส่งต่อพอร์ต 80 เช่นเดียวกับเซิร์ฟเวอร์ในนั้นเพื่อสร้าง / ต่ออายุใบรับรอง สิ่งนี้ไม่ให้ฉันใช้ cronjob เพื่อต่ออายุใบรับรอง มันก็เพียงพอแล้วสำหรับการทำงาน แต่ฉันมีเซิร์ฟเวอร์ที่ฟังใน 443 อยู่แล้วซึ่งสามารถทำงานได้เช่นกัน
16 ssl  lets-encrypt 

5
Nginx ปิดใช้งาน. htaccess และไฟล์ที่ซ่อน แต่อนุญาตให้ใช้ไดเรกทอรีที่รู้จักกันดี
ฉันมีเซิร์ฟเวอร์ Nginx และปิดการใช้งานไฟล์ที่ซ่อนอยู่ใน nginx_vhost.conf ## Disable .htaccess and other hidden files location ~ /\. { deny all; access_log off; log_not_found off; } แต่ LetsEncrypt ต้องการการเข้าถึง .well-knownไดเรกทอรี ฉันจะอนุญาตให้.well-knownไดเรกทอรีและปฏิเสธไฟล์ที่ซ่อนอื่น ๆ ได้อย่างไร

1
เปลี่ยนเส้นทางคำขอทั้งหมดไปยัง HTTPS ยกเว้นไดเรกทอรีย่อยเดียว
ฉันกำลังพยายามย้ายจากใบรับรองที่ลงชื่อด้วยตนเองไปเป็น Let's เข้ารหัสใบรับรองบนเว็บเซิร์ฟเวอร์ nginx ของฉัน ขณะนี้ฉันเปลี่ยนเส้นทางคำขอทั้งหมดไปhttp/80ยังhttps/443ซึ่งใช้ใบรับรองที่ลงชื่อด้วยตนเองที่ฉันสร้างขึ้นเมื่อไม่นานมานี้ ตอนนี้ - จากสิ่งที่ฉันเข้าใจ Let's Encrypt ส่งคำขอไปที่พอร์ต 80 (เนื่องจากฉันใช้webrootตัวเลือกcertbot) คำขอเหล่านี้จะถูกเปลี่ยนเส้นทางซึ่งทำให้การสร้างใบรับรองไม่สำเร็จ ฉันพยายามทำสิ่งนี้ด้วยบล็อกเซิร์ฟเวอร์ต่อไปนี้ฟังที่พอร์ต 80: server { listen 80; server_name sub.domain.tld; server_tokens off; location /.well-known { root /var/www/letsencrypt; } location / { return 301 https://$host$request_uri; } } แต่คำขอจะ/.well-knownถูกเปลี่ยนเส้นทางไปยังhttps/443ใด ๆ ฉันจะเปลี่ยนเส้นทางคำขอทั้งหมดจากhttp/80ไปยังhttps/443ยกเว้นคำขอไปยังได้/.well-known/อย่างไร

3
Certbot อนุญาตให้เข้ารหัสบนพอร์ตที่แตกต่างจาก 443
ฉันต้องการตั้งค่า certbot สำหรับเว็บเซิร์ฟเวอร์ในพอร์ตอื่นที่ไม่ใช่ 443 ฉันได้รับข้อผิดพลาดต่อไปนี้เมื่อทำงาน certbot --apache -d <sub>.<domain>.<ext> ขั้นตอนการอนุมัติที่ล้มเหลว sub.domain.ext (tls-sni-01): โกศ: acme: ข้อผิดพลาด: การเชื่อมต่อ: เซิร์ฟเวอร์ไม่สามารถเชื่อมต่อกับลูกค้าเพื่อตรวจสอบโดเมน :: ไม่สามารถเชื่อมต่อกับ external_ip: 443 สำหรับความท้าทาย TLS-SNI-01 หลังจากข้อผิดพลาดนี้ฉันได้อ่าน man man ที่ฉันพบสิ่งนี้: --tls-sni-01-port TLS_SNI_01_PORT หมายเลขพอร์ตเพื่อดำเนินการท้าทาย tls-sni-01 โบลเดอร์ในโหมดทดสอบเริ่มต้นที่ 5001 (ค่าเริ่มต้น: 443) จากนั้นฉันลองต่อไปนี้เพื่อแก้ไขข้อผิดพลาดนี้: certbot --apache --tls-sni-01-port 14831 -d <sub>.<domain>.<ext> หลังจากเพิ่ม tls-sni-01-port ฉันได้รับข้อผิดพลาดเดียวกัน เป็นไปได้หรือไม่ที่จะติดตั้งใบรับรองที่มีพอร์ตอื่นหรือฉันทำอะไรผิดพลาด?

1
คะแนน A + ยังไม่ปลอดภัยตามความเห็นของ Google Chrome
ฉันกำลังเตรียมเซิร์ฟเวอร์ของฉันในDigitalOceanและแม้ว่าฉันจะได้รับคะแนน A + จาก ssllabs https://www.ssllabs.com/ssltest/analyze.html?d=zandu.biz เมื่อฉันเชื่อมต่อกับเว็บไซต์ของฉันhttps://www.zandu.bizหรือhttps://zandu.bizฉันจะได้รับการแจ้งเตือนที่ไม่ปลอดภัยภายใน Chrome ฉันจะแก้ปัญหานี้ได้อย่างไร

1
ต่ออายุใบรับรองการเข้ารหัสลับบน Apache httpd
ฉันใช้certbot --webrootปลั๊กอินและcertbot renewต่ออายุใบรับรองซึ่งใช้งานได้ แต่ดูเหมือนว่าhttpdแคชใบรับรองและไม่ "เห็น" ว่ามีการอัปเดต มีสัญญาณhttpdให้โหลดใบรับรองซ้ำหรือไม่ ps ฉันไม่ต้องการรีสตาร์ทhttpdเพื่อหลีกเลี่ยงการหยุดทำงาน

1
Poste.io - ไม่สามารถเข้าสู่ระบบด้วยแอปพลิเคชันอีเมล - ใบรับรอง SSL ไม่ถูกต้อง
ฉันมีปัญหากับ poste.io และการกำหนดค่าด้วย nginx-proxy DOMAIN เป็นโดเมนที่ถูกต้อง :) นี่คือนักเทียบท่าของฉันเขียนสำหรับ poste.io: version: '3' volumes: mailserver_posteio: services: mailserver: image: analogic/poste.io container_name: poste-io restart: always ports: - "25:25" - "110:110" - "143:143" - "587:587" - "993:993" - "995:995" - "4190:4190" environment: - LETSENCRYPT_EMAIL=ssl@DOMAIN - LETSENCRYPT_HOST=mail.DOMAIN - VIRTUAL_HOST=mail.DOMAIN - HTTPS=OFF volumes: - /etc/localtime:/etc/localtime:ro - mailserver_posteio:/data …
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.