บทความ
เริ่ม
เริ่มเรียนรู้
JavaRush /จาวาบล็อก /Random-TH /จาก HTTP เป็น HTTPS
Viacheslav
ระดับ

จาก HTTP เป็น HTTPS

เผยแพร่ในกลุ่ม
จาก HTTP ถึง HTTPS - 1
เนื้อหา:

การแนะนำ

ในโลกสมัยใหม่ คุณไม่สามารถอยู่ได้โดยปราศจากเว็บแอปพลิเคชัน และเราจะเริ่มต้นด้วยการทดลองเล็กๆ ตอนเป็นเด็ก ฉันจำได้ว่าแผงขายหนังสือพิมพ์ทุกแห่งขายหนังสือพิมพ์ชื่อ “ข้อโต้แย้งและข้อเท็จจริง” ได้อย่างไร ฉันจำมันได้เพราะตามการรับรู้ส่วนตัวของฉันในวัยเด็ก หนังสือพิมพ์เหล่านี้ดูแปลกอยู่เสมอ และฉันตัดสินใจว่าเราควรไปที่เว็บไซต์ของพวกเขาหรือไม่:
จาก HTTP ถึง HTTPS - 2
หากเราไปที่ความช่วยเหลือของ Google Chrome เราจะอ่านว่าไซต์นี้ไม่ได้ใช้การเชื่อมต่อที่ปลอดภัย และข้อมูลที่คุณแลกเปลี่ยนกับไซต์อาจสามารถเข้าถึงได้โดยบุคคลที่สาม ลองตรวจสอบข่าวอื่นๆ เช่น ข่าวเซนต์ปีเตอร์สเบิร์กจาก Fontanka สื่ออิเล็กทรอนิกส์:
จาก HTTP เป็น HTTPS - 3
อย่างที่คุณเห็น เว็บไซต์ Fontanka ไม่มีปัญหาด้านความปลอดภัยตามข้อมูลเหล่านี้ ปรากฎว่าแหล่งข้อมูลบนเว็บอาจจะปลอดภัยหรือไม่ก็ได้ เรายังเห็นว่าการเข้าถึงทรัพยากรที่ไม่ได้รับการป้องกันเกิดขึ้นผ่านโปรโตคอล HTTP และหากทรัพยากรได้รับการปกป้อง การแลกเปลี่ยนข้อมูลจะดำเนินการโดยใช้โปรโตคอล HTTPS โดยที่ S ต่อท้ายหมายถึง “ปลอดภัย” โปรโตคอล HTTPS อธิบายไว้ในข้อกำหนด rfc2818: " HTTP Over TLS " มาลองสร้างเว็บแอปพลิเคชันของเราเองและดูว่ามันทำงานอย่างไร และระหว่างทางเราจะเข้าใจเงื่อนไข
จาก HTTP เป็น HTTPS - 4

เว็บแอปพลิเคชันใน Java

ดังนั้นเราจึงจำเป็นต้องสร้างเว็บแอปพลิเคชันที่เรียบง่ายใน Java ขั้นแรก เราต้องการแอปพลิเคชัน Java เอง ในการทำเช่นนี้ เราจะใช้ระบบสร้างอัตโนมัติของโปรเจ็กต์ Gradle สิ่งนี้จะช่วยให้เราไม่สร้างโครงสร้างไดเร็กทอรีที่จำเป็นด้วยตนเอง + Gradle จะจัดการไลบรารีทั้งหมดที่จำเป็นสำหรับโปรเจ็กต์ให้เราและรับรองว่าไลบรารีเหล่านั้นจะพร้อมใช้งานเมื่อรันโค้ด คุณสามารถอ่านเพิ่มเติมเกี่ยวกับ Gradle ได้ในบทวิจารณ์สั้น ๆ: " A Brief Introduction to Gradle " ลองใช้Gradle Init Pluginแล้วรันคำสั่ง: 
gradle init --type java-application
หลังจากนี้ เรามาเปิด build script กันbuild.gradleซึ่งอธิบายว่าไลบรารีใดที่โปรเจ็กต์ของเราประกอบด้วย ซึ่ง Gradle จะมอบให้เรา มาเพิ่มการพึ่งพาเว็บเซิร์ฟเวอร์ที่เราจะทดสอบ: 
dependencies {
    // Web server
    implementation 'io.undertow:undertow-core:2.0.20.Final'
     // Use JUnit test framework
     testImplementation 'junit:junit:4.12'
}
เพื่อให้เว็บแอปพลิเคชันทำงานได้ เราจำเป็นต้องมีเว็บเซิร์ฟเวอร์ที่จะโฮสต์แอปพลิเคชันของเราอย่างแน่นอน มีเว็บเซิร์ฟเวอร์หลากหลายประเภท แต่เซิร์ฟเวอร์หลักคือ: Tomcat, Jetty, Undertow ครั้งนี้เราจะเลือก Undertow เพื่อทำความเข้าใจว่าเราสามารถทำงานกับเว็บเซิร์ฟเวอร์ของเราได้อย่างไร ให้ไปที่เว็บไซต์ทางการของUndertow และไปที่ ส่วน เอกสารประกอบ คุณและฉันได้เชื่อมต่อการพึ่งพา Undertow Core ดังนั้นเราจึงสนใจในส่วนเกี่ยวกับCore นี้เอง นั่นคือคอร์ซึ่งเป็นพื้นฐานของเว็บเซิร์ฟเวอร์ วิธีที่ง่ายที่สุดคือการใช้ Builder API สำหรับ Undertow: 
public static void main(String[] args) {
	Undertow server = Undertow.builder()
            .addHttpListener(8080, "localhost")
            .setHandler(new HttpHandler() {
                @Override
                public void handleRequest(final HttpServerExchange exchange) throws Exception {
                    exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain");
                    exchange.getResponseSender().send("Hello World");
                }
            }).build();
    server.start();
}
หากเรารันโค้ด เราสามารถนำทางไปยังแหล่งข้อมูลบนเว็บต่อไปนี้:
จาก HTTP ถึง HTTPS - 5
มันใช้งานได้ง่าย ต้องขอบคุณ Undertow Builder API เราจึงเพิ่มตัวฟัง HTTP ให้กับ localhost และพอร์ต 8080 ตัวฟังนี้รับคำขอจากเว็บเบราว์เซอร์และส่งกลับสตริง "Hello World" เป็นการตอบกลับ แอปพลิเคชั่นเว็บที่ยอดเยี่ยม แต่อย่างที่เราเห็น เราใช้โปรโตคอล HTTP เช่น การแลกเปลี่ยนข้อมูลประเภทนี้ไม่ปลอดภัย มาดูกันว่าการแลกเปลี่ยนดำเนินการอย่างไรโดยใช้โปรโตคอล HTTPS
Java-университет
จาก HTTP เป็น HTTPS - 6

ข้อกำหนดสำหรับ HTTPS

เพื่อให้เข้าใจถึงวิธีเปิดใช้งาน HTTPS ให้เรากลับไปที่ข้อกำหนด HTTPS กัน: " RFC-2818: HTTP Over TLS " ตามข้อกำหนด ข้อมูลในโปรโตคอล HTTPS จะถูกส่งผ่านโปรโตคอลการเข้ารหัส SSL หรือ TLS ผู้คนมักถูกเข้าใจผิดโดยแนวคิดของ SSL และ TLS ในความเป็นจริงแล้ว SSL ได้พัฒนาและเปลี่ยนแปลงเวอร์ชันของมัน ต่อมา TLS กลายเป็นก้าวต่อไปในการพัฒนาโปรโตคอล SSL นั่นคือ TLS เป็นเพียง SSL เวอร์ชันใหม่ ข้อกำหนดระบุเช่นนั้น: “SSL และ TLS ตัวตายตัวแทน” ดังนั้นเราจึงได้เรียนรู้ว่ามีโปรโตคอลการเข้ารหัส SSL/TLS SSLเป็นตัวย่อของ Secure Sockets Layer และแปลว่า "secure socket layer" ซ็อกเก็ตที่แปลจากภาษาอังกฤษเป็นตัวเชื่อมต่อ ผู้เข้าร่วมในการส่งข้อมูลผ่านเครือข่ายใช้ซ็อกเก็ตเป็นอินเทอร์เฟซการเขียนโปรแกรม (นั่นคือ API) เพื่อสื่อสารระหว่างกันผ่านเครือข่าย เบราว์เซอร์ทำหน้าที่เป็นไคลเอนต์และใช้ซ็อกเก็ตไคลเอนต์ และเซิร์ฟเวอร์ที่ได้รับคำขอและตอบกลับจะใช้ซ็อกเก็ตเซิร์ฟเวอร์ และระหว่างซ็อกเก็ตเหล่านี้มีการแลกเปลี่ยนข้อมูลเกิดขึ้น นั่นเป็นสาเหตุที่เดิมทีโปรโตคอลนี้เรียกว่า SSL แต่เวลาผ่านไปและโปรโตคอลก็พัฒนาขึ้น และเมื่อถึงจุดหนึ่ง โปรโตคอล SSL ก็กลายเป็นโปรโตคอล TLS TLS ย่อมาจาก Transport Layer Security โปรโตคอล TLS จะขึ้นอยู่กับข้อกำหนดโปรโตคอล SSL เวอร์ชัน 3.0 โปรโตคอล TLS เป็นหัวข้อของบทความและบทวิจารณ์แยกกัน ดังนั้นฉันจะระบุเนื้อหาที่ฉันพบว่าน่าสนใจ: กล่าวโดยสรุป พื้นฐานของ HTTPS คือการจับมือ TLS และการตรวจสอบ “ข้อมูลประจำตัวเซิร์ฟเวอร์” (เช่น การระบุเซิร์ฟเวอร์) โดยใช้ใบรับรองดิจิทัล มันเป็นสิ่งสำคัญ จำไว้นะเพราะว่า... เราจะกลับมาที่ข้อเท็จจริงนี้ในภายหลัง ดังนั้น ก่อนหน้านี้เราใช้ HttpListener เพื่อบอกเซิร์ฟเวอร์ถึงวิธีดำเนินการผ่านโปรโตคอล HTTP หากในตัวอย่างด้านบนเราได้เพิ่ม HttpListener เพื่อทำงานบน HTTP ดังนั้นในการทำงานบน HTTPS เราจำเป็นต้องเพิ่ม HttpsListener:
จาก HTTP เป็น HTTPS - 7
แต่เพื่อเพิ่มเข้าไปเราจำเป็นต้องมี SSLContext สิ่งที่น่าสนใจ SSLContext ไม่ใช่คลาสจาก Undertow แต่เป็นjavax.net.ssl.SSLContext. คลาส SSLContext เป็นส่วนหนึ่งของสิ่งที่เรียกว่า " Java Secure Socket Extension " (JSSE) ซึ่งเป็นส่วนขยาย Java สำหรับรับรองความปลอดภัยของการเชื่อมต่ออินเทอร์เน็ต ส่วนขยายนี้มีอธิบายไว้ใน " คู่มืออ้างอิง Java Secure Socket Extension (JSSE) " ดังที่คุณเห็นจากส่วนเบื้องต้นของเอกสารประกอบ JSSE จัดเตรียมเฟรมเวิร์กและการใช้งาน Java ของโปรโตคอล SSL และ TLS เราจะรับ SSLContext ได้อย่างไร เปิด JavaDoc SSLContext และค้นหาเมธอดgetInstance อย่างที่คุณเห็น ในการรับ SSLContext เราจำเป็นต้องระบุชื่อ "Secure Socket Protocol" คำอธิบายของพารามิเตอร์ระบุว่าชื่อเหล่านี้สามารถพบได้ใน " เอกสารประกอบชื่ออัลกอริทึมมาตรฐานสถาปัตยกรรมการเข้ารหัส Java " ดังนั้นเรามาทำตามคำแนะนำและไปที่เอกสารประกอบ และเราเห็นว่าเราสามารถเลือกได้ระหว่าง SSL และ TLS:
จาก HTTP ถึง HTTPS - 8
ตอนนี้เราเข้าใจแล้วว่าเราต้องสร้าง SSLContext ดังนี้: 
public SSLContext getSSLContext() {
	// 1. Получаем контекст, в рамках которого будем работать по TLS протоколу
	SSLContext context = null;
	try {
		context = SSLContext.getInstance("TLS");
	} catch (NoSuchAlgorithmException e) {
		throw new IllegalStateException(e);
	}
	return context;
}
หลังจากสร้างบริบทใหม่แล้ว เราจำได้ว่า SSLContext ได้รับการอธิบายไว้ใน " คู่มืออ้างอิง Java Secure Socket Extension (JSSE) " เราอ่านและเห็นว่า “ควรเริ่มต้น SSLContext ที่สร้างขึ้นใหม่โดยการเรียกเมธอด init” นั่นคือการสร้างบริบทยังไม่เพียงพอ มันจะต้องมีการเริ่มต้น และนี่คือตรรกะเพราะว่า เกี่ยวกับความปลอดภัย เราเพียงแต่บอกคุณว่าเราต้องการใช้โปรโตคอล TLS ในการเริ่มต้น SSLContext เราจำเป็นต้องจัดเตรียมสามสิ่ง: KeyManager, TrustManager, SecureRandom
จาก HTTP เป็น HTTPS - 9

ผู้จัดการคีย์

KeyManagerเป็นผู้จัดการคีย์ เขามีหน้าที่รับผิดชอบในสิ่งที่ “ข้อมูลรับรองความถูกต้อง” ที่จะมอบให้กับผู้ที่ติดต่อเรา ข้อมูลประจำตัวสามารถแปลเป็นตัวตนได้ จำเป็นต้องมีข้อมูลประจำตัวเพื่อให้ลูกค้าแน่ใจว่าเซิร์ฟเวอร์คือบุคคลที่เขาอ้างว่าเป็นและสามารถเชื่อถือได้ สิ่งที่จะถูกนำมาใช้เป็นบัตรประจำตัว? อย่างที่เราจำได้ Server Identity ได้รับการตรวจสอบโดยใบรับรองดิจิทัลของเซิร์ฟเวอร์ กระบวนการนี้สามารถแสดงได้ดังนี้:
จาก HTTP ถึง HTTPS - 10
นอกจากนี้ " คู่มืออ้างอิง JSSE: วิธีการทำงานของ SSL " ระบุว่า SSL ใช้ "การเข้ารหัสแบบอสมมาตร" ซึ่งหมายความว่าเราต้องการคู่คีย์: คีย์สาธารณะและคีย์ส่วนตัว เนื่องจากเรากำลังพูดถึงการเข้ารหัส จึงมีการใช้ “Java Cryptography Architecture” (JCA) Oracle จัดเตรียมเอกสารที่ยอดเยี่ยมเกี่ยวกับสถาปัตยกรรมนี้: " คู่มืออ้างอิง Java Cryptography Architecture (JCA) " นอกจากนี้ คุณสามารถอ่านภาพรวมโดยย่อของ JCA บน JavaRush ได้ที่: " สถาปัตยกรรมการเข้ารหัส Java: การรู้จักครั้งแรก " ดังนั้น ในการเริ่มต้น KeyManager เราจำเป็นต้องมี KeyStore ซึ่งจะเก็บใบรับรองของเซิร์ฟเวอร์ของเรา วิธีทั่วไปในการสร้างที่เก็บคีย์และใบรับรองคือยูทิลิตี้ keytool ซึ่งรวมอยู่ใน JDK ตัวอย่างสามารถดูได้ในเอกสารประกอบ JSSE: " การสร้างที่เก็บคีย์เพื่อใช้กับ JSSE " ดังนั้นเราจำเป็นต้องใช้ยูทิลิตี้ KeyTool เพื่อสร้างที่เก็บคีย์และเขียนใบรับรองที่นั่น สิ่งที่น่าสนใจคือ ก่อนหน้านี้การสร้างคีย์ถูกระบุโดยใช้ -genkey แต่ตอนนี้แนะนำให้ใช้ -genkeypair เราจะต้องกำหนดสิ่งต่อไปนี้:
  • นามแฝง : นามแฝงหรือเพียงแค่ชื่อที่รายการจะถูกบันทึกไว้ใน Keystore
    • keyalg : อัลกอริธึมการเข้ารหัสคีย์ เรามาเลือกอัลกอริทึม RSA ซึ่งเป็นโซลูชันมาตรฐานสำหรับวัตถุประสงค์ของเรา
  • ขนาดคีย์ : ขนาดคีย์ (เป็นบิต) ขนาดขั้นต่ำที่แนะนำคือ 2048 เนื่องจาก... ขนาดที่เล็กกว่าก็แตกแล้ว คุณสามารถอ่านเพิ่มเติมได้ที่นี่: " ใบรับรอง SSL ใน 2048 บิต "
  • dname : ชื่อเฉพาะ, ชื่อเด่น.
    •
สิ่งสำคัญคือต้องเข้าใจว่าทรัพยากรที่ร้องขอ (เช่น https://localhost) จะถูกเปรียบเทียบกับทรัพยากรนั้น สิ่งนี้เรียกว่า "การจับคู่หัวเรื่อง cn"
  • ความถูกต้อง : ระยะเวลาเป็นวันที่ใบรับรองที่สร้างขึ้นนั้นถูกต้อง เช่น ถูกต้อง.
  • ต่อ : ส่วนขยายใบรับรองที่ระบุใน " ส่วนขยายที่มีชื่อ "
สำหรับใบรับรองที่ลงนามด้วยตนเอง (เช่น สำหรับใบรับรองที่สร้างขึ้นอย่างอิสระ) คุณต้องระบุส่วนขยายต่อไปนี้:
  • -ext san:critical=dns:localhost,ip:127.0.0.1 > เพื่อทำการจับคู่หัวเรื่องโดย SubjectAlternativeName
  • -ext bc=ca:false > เพื่อระบุว่าใบรับรองนี้ไม่ได้ใช้เพื่อลงนามใบรับรองอื่น
มารันคำสั่งกัน (ตัวอย่างสำหรับ Windows OS): 
keytool -genkeypair -alias ssl -keyalg RSA -keysize 2048 -dname "CN=localhost,OU=IT,O=Javarush,L=SaintPetersburg,C=RU,email=contact@email.com" -validity 90 -keystore C:/keystore.jks -storepass passw0rd -keypass passw0rd -ext san:critical=dns:localhost,ip:127.0.0.1 -ext bc=ca:false
เพราะ ไฟล์จะถูกสร้างขึ้น ตรวจสอบให้แน่ใจว่าคุณมีสิทธิ์ทั้งหมดในการสร้างไฟล์ คุณยังอาจเห็นคำแนะนำเช่นนี้:
จาก HTTP ถึง HTTPS - 11
ที่นี่เราได้รับแจ้งว่า JKS เป็นรูปแบบที่เป็นกรรมสิทธิ์ กรรมสิทธิ์หมายความว่าเป็นทรัพย์สินส่วนตัวของผู้เขียนและมีไว้สำหรับใช้ในภาษา Java เท่านั้น เมื่อทำงานกับยูทิลิตี้ของบุคคลที่สาม อาจมีข้อขัดแย้งเกิดขึ้น ซึ่งเป็นสาเหตุที่เราถูกเตือน นอกจากนี้ เราอาจได้รับข้อผิดพลาด: The destination pkcs12 keystore has different storepass and keypass. ข้อผิดพลาดนี้เกิดขึ้นเนื่องจากรหัสผ่านสำหรับรายการในที่เก็บคีย์และสำหรับที่เก็บคีย์นั้นแตกต่างกัน ตามที่เอกสารประกอบ ของ keytoolระบุว่า "ตัวอย่างเช่น เครื่องมือของบุคคลที่สามส่วนใหญ่กำหนดให้ storepass และ keypass ในที่เก็บคีย์ PKCS #12 เหมือนกัน" เราสามารถระบุคีย์ได้เอง (เช่น -destkeypass entrypassw) แต่เป็นการดีกว่าที่จะไม่ละเมิดข้อกำหนดและตั้งรหัสผ่านเดียวกัน ดังนั้นการนำเข้าอาจมีลักษณะดังนี้: 
keytool -importkeystore -srckeystore C:/keystore.jks -destkeystore C:/keystore.jks -deststoretype pkcs12
ตัวอย่างความสำเร็จ:
จาก HTTP ถึง HTTPS - 12
หากต้องการส่งออกใบรับรองเป็นไฟล์ คุณสามารถเรียกใช้: 
keytool -export -alias ssl -storepass passw0rd -file C:/server.cer -keystore C:/keystore.jks
นอกจากนี้ เรายังสามารถรับเนื้อหา Keystore ดังนี้: 
keytool -list -v -keystore C:/keystore.jks -storepass passw0rd
เยี่ยมเลย ตอนนี้เรามีที่เก็บคีย์ที่มีใบรับรองแล้ว ตอนนี้คุณสามารถรับได้จากรหัส: 
public KeyStore getKeyStore() {
	// Согласно https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#KeyStore
	try(FileInputStream fis = new FileInputStream("C:/keystore.jks")){
		KeyStore keyStore = KeyStore.getInstance("pkcs12");
		keyStore.load(fis, "passw0rd".toCharArray());
		return keyStore;
	} catch (IOException ioe) {
		throw new IllegalStateException(ioe);
	} catch (KeyStoreException | NoSuchAlgorithmException | CertificateException e) {
		throw new IllegalStateException(e);
	}
}
หากมี KeyStore เราสามารถเริ่มต้น KeyManager ได้: 
public KeyManager[] getKeyManagers(KeyStore keyStore) {
	String keyManagerAlgo = KeyManagerFactory.getDefaultAlgorithm();
	KeyManagerFactory keyManagerFactory = null;
	try {
		keyManagerFactory = KeyManagerFactory.getInstance(keyManagerAlgo);
		keyManagerFactory.init(keyStore, "passw0rd".toCharArray());
		return keyManagerFactory.getKeyManagers();
	} catch (NoSuchAlgorithmException e) {
		throw new IllegalStateException(e);
	} catch (UnrecoverableKeyException | KeyStoreException e) {
		throw new IllegalStateException(e);
	}
}
เป้าหมายแรกของเราสำเร็จแล้ว ยังคงต้องพิจารณาว่า TrustManager คืออะไร TrustManager อธิบายไว้ในเอกสารประกอบ JSSE ในส่วน " The TrustManager Interface " มันคล้ายกับ KeyManager มาก แต่มีวัตถุประสงค์เพื่อตรวจสอบว่าบุคคลที่ร้องขอการเชื่อมต่อสามารถเชื่อถือได้หรือไม่ พูดตรงๆ นี่คือ KeyManager ในแบบย้อนกลับ =) เราไม่ต้องการ TrustManager ดังนั้นเราจะผ่านค่าว่าง TrustManager เริ่มต้นจะถูกสร้างขึ้นซึ่งไม่ได้ตรวจสอบผู้ใช้ที่ส่งคำขอไปยังเซิร์ฟเวอร์ของเรา เอกสารระบุเช่นนั้น: "การใช้งานเริ่มต้นจะถูกใช้" เช่นเดียวกับ SecureRandom หากเราระบุเป็นโมฆะ การใช้งานเริ่มต้นจะถูกใช้ โปรดจำไว้ว่า SecureRandom เป็นคลาส JCA และมีคำอธิบายอยู่ในเอกสารประกอบ JCA ในส่วน " The SecureRandom Class " โดยรวมแล้วการเตรียมการโดยคำนึงถึงวิธีการทั้งหมดที่อธิบายไว้ข้างต้นอาจมีลักษณะดังนี้: 
public static void main(String[] args) {
	// 1. Подготавливаем приложение к работе по HTTPS
	App app = new App();
	SSLContext sslContext = app.getSSLContext();
	KeyStore keyStore = app.getKeyStore();
	KeyManager[] keyManagers = app.getKeyManagers(keyStore);
	try {
		sslContext.init(keyManagers, null, null);
	} catch (KeyManagementException e) {
		throw new IllegalStateException(e);
	}
สิ่งที่เหลืออยู่คือการเริ่มเซิร์ฟเวอร์: 
// 2. Поднимаем server
 	int httpsPort = 443;
	Undertow server = Undertow.builder()
            .addHttpsListener(httpsPort, "localhost", sslContext)
            .setHandler(new HttpHandler() {
                @Override
                public void handleRequest(final HttpServerExchange exchange) throws Exception {
                    exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain");
                    exchange.getResponseSender().send("Hello World");
                }
            }).build();
	server.start();
}
เวลานี้เซิร์ฟเวอร์ของเราจะพร้อมใช้งานตามที่อยู่https://localhost:443 อย่างไรก็ตาม เราจะยังคงได้รับข้อผิดพลาดว่าทรัพยากรนี้ไม่สามารถเชื่อถือได้:
จาก HTTP ถึง HTTPS - 13
เรามาดูกันว่ามีอะไรผิดปกติกับใบรับรองและต้องทำอย่างไร
จาก HTTP ถึง HTTPS - 14

การจัดการใบรับรอง

ดังนั้นเซิร์ฟเวอร์ของเราจึงพร้อมที่จะทำงานผ่าน HTTPS แล้ว แต่ลูกค้าไม่เชื่อถือ ทำไม มาดูกันดีกว่า:
จาก HTTP ถึง HTTPS - 15
เหตุผลก็คือใบรับรองนี้เป็นใบรับรองที่ลงนามด้วยตนเอง ใบรับรอง SSL ที่ลงนามด้วยตนเองหมายถึงใบรับรองคีย์สาธารณะที่ออกและลงนามโดยบุคคลเดียวกันกับที่ระบุ นั่นคือไม่ได้ออกโดยหน่วยงานออกใบรับรองใดๆ ที่ได้รับความเคารพ (CA หรือที่เรียกว่าผู้ออกใบรับรอง) ผู้ออกใบรับรองทำหน้าที่เป็นผู้ดูแลผลประโยชน์และคล้ายกับทนายความในชีวิตประจำวัน เขารับรองว่าใบรับรองที่เขาออกมีความน่าเชื่อถือ จะมีการชำระค่าบริการออกใบรับรองโดย CA ดังกล่าว ดังนั้นจึงไม่มีใครจำเป็นต้องสูญเสียความไว้วางใจและความเสี่ยงด้านชื่อเสียง ตามค่าเริ่มต้น มีผู้ออกใบรับรองหลายรายที่เชื่อถือได้ รายการนี้สามารถแก้ไขได้ และแต่ละระบบปฏิบัติการก็มีการจัดการรายชื่อหน่วยงานออกใบรับรองของตนเอง ตัวอย่างเช่น การจัดการรายการนี้ใน Windows สามารถอ่านได้ที่นี่: " จัดการใบรับรองหลักที่เชื่อถือได้ใน Windows " มาเพิ่มใบรับรองให้กับใบรับรองที่เชื่อถือได้ตามที่ระบุไว้ในข้อความแสดงข้อผิดพลาด เมื่อต้องการทำเช่นนี้ ขั้นแรก ให้ดาวน์โหลดใบรับรอง:
จาก HTTP ถึง HTTPS - 16
ใน OS Windows ให้กด Win+R แล้วดำเนินการmmcเพื่อเรียกคอนโซลควบคุม จากนั้นกด Ctrl+M เพื่อเพิ่มส่วน “ใบรับรอง” ลงในคอนโซลปัจจุบัน ถัดไป ในส่วนย่อย "ผู้ออกใบรับรองหลักที่เชื่อถือได้" เราจะดำเนินДействия / Все задачи / Импортการ มานำเข้าไฟล์ที่ดาวน์โหลดมาก่อนหน้านี้ลงในไฟล์กันดีกว่า เบราว์เซอร์อาจจดจำสถานะความน่าเชื่อถือในอดีตของใบรับรองได้ ดังนั้นก่อนเปิดหน้าคุณต้องรีสตาร์ทเบราว์เซอร์ก่อน chrome://restartตัวอย่างเช่นใน Google Chrome คุณต้องเรียกใช้ในแถบที่อยู่ ใน OS Windows คุณยังสามารถใช้ยูทิลิตีเพื่อดูใบรับรองได้certmgr.msc:
จาก HTTP ถึง HTTPS - 17
หากเราทำทุกอย่างถูกต้อง เราจะเห็นการเรียกไปยังเซิร์ฟเวอร์ของเราผ่าน HTTPS ได้สำเร็จ:
จาก HTTP ถึง HTTPS - 18
อย่างที่คุณเห็น ตอนนี้ใบรับรองถือว่าถูกต้อง มีทรัพยากรพร้อมใช้งาน และไม่มีข้อผิดพลาด
จาก HTTP ถึง HTTPS - 19

บรรทัดล่าง

ดังนั้นเราจึงได้ทราบว่ารูปแบบการเปิดใช้งานโปรโตคอล HTTPS บนเว็บเซิร์ฟเวอร์มีลักษณะอย่างไรและสิ่งที่จำเป็นสำหรับสิ่งนี้ ฉันหวังว่า ณ จุดนี้ชัดเจนว่าการสนับสนุนนั้นมาจากการโต้ตอบของ Java Cryptography Architecture (JCA) ซึ่งรับผิดชอบด้านการเข้ารหัสและ Java Secure Socket Extension (JSSE) ซึ่งจัดให้มีการใช้งาน TLS บนฝั่ง Java เราเห็นว่ายูทิลิตี้ keytool ที่รวมอยู่ใน JDK นั้นใช้เพื่อทำงานกับคีย์ KeyStore และที่เก็บใบรับรองอย่างไร นอกจากนี้ เรายังพบว่า HTTPS ใช้โปรโตคอล SSL/TLS เพื่อความปลอดภัย เพื่อเน้นย้ำสิ่งนี้ ฉันขอแนะนำให้คุณอ่านบทความดีๆ ในหัวข้อนี้: หวังว่าหลังจากการตรวจสอบเล็กน้อยนี้ HTTPS จะมีความโปร่งใสมากขึ้นอีกเล็กน้อย และหากคุณต้องการเปิดใช้งาน HTTPS คุณสามารถเข้าใจข้อกำหนดได้อย่างง่ายดายจากเอกสารประกอบของแอปพลิเคชันเซิร์ฟเวอร์และเฟรมเวิร์กของคุณ #เวียเชสลาฟ
ความคิดเห็น
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION