Apache จะไม่ขอใบรับรองไคลเอนต์ SSL ของฉัน

ขั้นแรก คุณต้องกำหนดค่า Apache Httpd เพื่อขอใบรับรองไคลเอ็นต์ สำหรับสิ่งนี้ อย่างน้อยคุณต้องใช้ SSLVerifyClient optional บนตำแหน่ง/ไดเรกทอรีที่คุณต้องการตรวจสอบสิทธิ์ด้วยวิธีนี้

ประการที่สอง ใบรับรองที่ส่งโดยไคลเอ็นต์จะต้องได้รับความเชื่อถือจาก Apache Httpd ด้วยเช่นกัน (โดยหลักการแล้วคุณสามารถใช้ SSLVerifyClient optional_no_ca ปล่อยให้ไคลเอ็นต์ใดๆ รับรองผ่านสแต็ก Apache Httpd SSL/TLS จากนั้นจึงตรวจสอบใบรับรองภายใน PHP เท่านั้น แต่นั่นเป็นงานที่ค่อนข้างยุ่งยาก ซึ่งคุณต้องระมัดระวังให้มากขึ้นอีกเล็กน้อยเนื่องจาก ไม่จำเป็นต้องใช้โค้ดง่ายๆ ที่สำคัญกว่านั้น สิ่งนี้จะไม่มีประโยชน์เลยทีเดียวในบริบทนี้ เนื่องจากคุณอยู่ในสถานการณ์ที่คุณสามารถควบคุม CA ของคุณได้)

เท่าที่ฉันเข้าใจ SSL_CLIENT_VERIFY (ตัวแปรที่ฉันไม่ค่อยได้ใช้ด้วยตัวเอง) ดูเหมือนจะมีประโยชน์จริงๆ กับ SSLVerifyClient optional_no_ca เท่านั้น มันอาจจะใช้ได้กับ SSLVerifyClient optional แต่ฉันสงสัยอย่างนั้น SSLVerifyClient require จะปฏิเสธการเชื่อมต่อโดยใช้ใบรับรองไคลเอ็นต์ที่ไม่น่าเชื่อถือ (โดย CA ตัวใดตัวหนึ่งใน SSLCACertificateFile/SSLCACertificatePath) หรือหากไม่มีใบรับรอง เท่าที่ฉันรู้ SSLVerifyClient optional จะปล่อยให้ไคลเอ็นต์ผ่านไปโดยไม่มีใบรับรองหรือใบรับรองที่เชื่อถือได้ แต่จะปฏิเสธการเชื่อมต่อด้วยหากใบรับรองไม่เชื่อถือ

ในกรณีนี้ การปฏิเสธการเชื่อมต่อ ฉันหมายถึงการปิดการเชื่อมต่อ SSL/TLS อย่างกะทันหันพร้อมกับการแจ้งเตือน ไม่มีโอกาสสร้างหน้าแสดงข้อผิดพลาด HTTP(S) สิ่งที่คุณจะได้รับจากข้อผิดพลาดมาตรฐานของเบราว์เซอร์ ซึ่งอยู่ในบรรทัด ssl_error_unknown_certificate_... (คุณควรพิจารณาสิ่งนี้ในแง่ของการใช้งาน)

ตั้งแต่นั้นเป็นต้นมา สิ่งที่คุณต้องมีคือตั้งค่า CA ของคุณเอง ซึ่งอาจทำงานบนเว็บด้วยการสร้างคีย์ในเบราว์เซอร์และภายในเว็บไซต์เดียวกัน คุณคงไม่ต้องการ SSLVerifyClient require สำหรับสิ่งนั้น เพราะคุณจะต้องให้ผู้ใช้ที่ยังไม่มีใบรับรองเข้ามา (ใช้ optional แทน) ดังที่กล่าวไปแล้ว คำสั่งเหล่านี้ไม่จำเป็นต้องใช้กับโฮสต์ทั้งหมด แต่สามารถเฉพาะเจาะจงกับบางสถานที่/ไดเร็กทอรีได้

การรวม CA บนเว็บของคุณเอง (หรือโดยทั่วไปคือการสร้าง CA ของคุณเอง) ไม่ใช่เรื่องง่ายหากคุณยังใหม่กับเรื่องทั้งหมดนี้ มีเครื่องมือสำเร็จรูปอยู่แล้ว (เช่น OpenCA) หรือคุณสามารถสร้างเครื่องมือของคุณเองโดยใช้บิตต่างๆ ของ JavaScript/ActiveX และคุณจะ ต้องการโค้ดฝั่งเซิร์ฟเวอร์เพื่อจัดการคำขอ SPKAC หรือ PKCS#10 (และเพื่อออกใบรับรองจริง) (เพื่อให้ CA ดังกล่าวมีประโยชน์ คุณคงต้องการให้ผู้ใช้ที่สมัครใบรับรองใหม่แสดงหลักฐานประจำตัวบางส่วน ณ เวลาที่สมัคร ซึ่งอาจรวมถึงรหัสผ่าน)

เมื่อตั้งค่านี้แล้ว คุณควรกำหนดค่า SSLCACertificateFile (หรือ ...Path) ให้ชี้ไปที่ใบรับรอง CA ของ CA ภายในของคุณ (ไม่ว่าจะเป็น CA บนเว็บหรือไม่ก็ตาม บนไซต์เดียวกันหรือไม่ก็ตาม) (แน่นอนว่า เก็บคีย์ส่วนตัวของ CA ของคุณไว้เป็นส่วนตัว ซึ่งอาจกำหนดค่าไว้ภายในแอปพลิเคชันบนเว็บของ CA ของคุณ แต่ Apache Httpd เองก็ไม่จำเป็นต้องรู้เรื่องนี้) เบราว์เซอร์จะแนะนำเฉพาะใบรับรองที่ออกโดย CA หรือตัวกลางเหล่านั้นเท่านั้น (เว้นแต่ คุณได้กำหนดค่า SSLCADNRequestFile ซึ่งจะใช้ในการส่งรายการ CA ที่ยอมรับแทน)

โปรดทราบว่าสองขั้นตอนนี้ (การตั้งค่า CA และการตั้งค่าเว็บไซต์ของคุณเพื่อใช้ใบรับรองไคลเอ็นต์) จริงๆ แล้วมีความเป็นอิสระอย่างแท้จริง ความจริงที่ว่าทั้งสองสามารถเป็นส่วนหนึ่งของไซต์เดียวกันได้ก็สะดวก แต่ก็ไม่จำเป็น คุณสามารถลองใช้การตั้งค่า Apache Httpd โดยไม่ต้องปรับใช้ CA ทั้งหมดบนไซต์ก่อน (ฉันขอแนะนำ แม้ว่าจะเป็นเพียงเพื่อดูว่าคุณกำลังทำอะไรอยู่ก็ตาม) มีเครื่องมือมากมายในการสร้าง CA เล็กๆ ของคุณเองที่สามารถจัดการได้ด้วยใบรับรองจำนวนหนึ่ง: CA.pl ของ OpenSSL หรือ TinyCA เป็นต้น คุณสามารถใช้ ใบรับรองการทดสอบ (localhost และ testclient, testclient_r จะถูกเพิกถอนหากคุณต้องการใช้ CRL ซึ่งอาจไม่จำเป็นในตอนแรก): รหัสผ่านทั้งหมดคือ testtest

ตามที่คุณคาดหวังไว้แล้ว (ด้วย MySQL DB) คุณจะต้องจัดการใบรับรองที่คุณออกและแมปใบรับรองกับผู้ใช้ SSL_CLIENT_M_SERIAL และ SSL_CLIENT_I_DN ไม่ใช่ตัวแปรที่ถูกต้องที่จะใช้ SSL_CLIENT_I_DN คือ DN ผู้ออก (เช่น DN เรื่องของ CA) สิ่งที่คุณกำลังมองหาคือ SSL_CLIENT_S_DN: ใบรับรองไคลเอ็นต์ Subject DN SSL_CLIENT_M_SERIAL คือหมายเลขซีเรียลของใบรับรอง: อย่าใช้ เนื่องจากหมายเลขดังกล่าวไม่ซ้ำกันต่อใบรับรอง: ผู้ใช้ 1 รายสามารถมีใบรับรองได้หลายใบที่มี DN หัวเรื่องเดียวกัน (เช่น หากมีใบรับรองหมดอายุหรือถูกเพิกถอน)

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

• ประการแรก ผู้ใช้ควรปกป้องใบรับรองของตนเองด้วยรหัสผ่านอยู่แล้ว ฉันคิดว่าสิ่งที่คุณต้องการจริงๆ คือรูปแบบการลงชื่อเพียงครั้งเดียว (SSO)

• ประการที่สอง ขึ้นอยู่กับระดับความรู้คอมพิวเตอร์ของผู้ใช้ ใบรับรองอาจเป็นเรื่องยากในการจัดการ

  ความจริงที่ว่าคำว่า "ใบรับรอง" หากพูดอย่างเคร่งครัดนั้นไม่ได้รวมคีย์ส่วนตัวไว้เลย แต่บางครั้งก็บอกเป็นนัยว่าการใช้คีย์ส่วนตัวอาจทำให้บางคนสับสนได้ ในด้านหนึ่ง บางครั้งคุณอาจได้ยินว่า "นำเข้าใบรับรองของคุณไปยังเบราว์เซอร์ของคุณ" และ "ใช้ใบรับรองของคุณเพื่อเข้าสู่ระบบ"; ในทางกลับกัน คุณยังสามารถได้ยินว่า "ส่งใบรับรองของคุณมาให้ฉัน" แบบแรกหมายถึงการใช้งานและความพร้อมใช้งานของคีย์ส่วนตัว ("ใบรับรอง" อาจหมายถึง .p12 ในนิพจน์เหล่านี้) อย่างหลังไม่ควรเกี่ยวข้องกับรหัสส่วนตัวอย่างแน่นอน

  อินเทอร์เฟซผู้ใช้ของเบราว์เซอร์ค่อนข้างแย่หรือสับสนในการจัดการใบรับรองหรือออกจากระบบ ขอย้ำอีกครั้ง หากระบบไม่รู้จักใบรับรอง การเชื่อมต่อ SSL/TLS จะไม่ถูกสร้างขึ้น ดังนั้นเว็บเซิร์ฟเวอร์จึงไม่มีโอกาสแสดงหน้าข้อผิดพลาด HTML ไม่ว่าจะประเภทใดก็ตาม

บางทีคุณอาจพิจารณา SSO รูปแบบอื่นๆ ก็ได้ (เช่น CAS, บางอย่างที่ใช้ SAML หรือ Kerberos/SPNEGO)

ฉันมีปัญหาที่คล้ายกันกับ:

• เซนโอเอส 6.3
• อาปาเช่ 2.2.15

หลังจากลองมาบ้างฉันก็พบปัญหาของฉัน

หากฉันตั้งค่า SSLVerifyClient optional หรือ SSLVerifyClient optional_no_ca และฉันระบุ SSLCACertificateFile หรือ SSLCACertificatePath ด้วย Apache จะได้รับใบรับรองไคลเอ็นต์ก็ต่อเมื่อมีการเผยแพร่จาก CA ที่พบในไฟล์อ้างอิง CA/เส้นทางที่ระบุในการกำหนดค่า

คุณอาจดู apache doc หากยังไม่ได้ดำเนินการ

หลักการทั่วไปคือคุณสร้างใบรับรองที่ลงนามด้วยตนเองและตรวจสอบก่อนลองใช้

ดูเหมือนว่าไคลเอ็นต์จะเชื่อมต่อกับไซต์อินทราเน็ตของคุณผ่าน http จากที่นั่น มีหลายวิธีในการสลับไปใช้ https โดยใช้ใบรับรอง SSL ของคุณ วิธีที่ง่ายที่สุดคือใช้โมดูลการเขียนใหม่ของ apache แต่ในกรณีของคุณ ขณะที่คุณกำลังตรวจสอบ php/mysql คุณอาจเปลี่ยนเส้นทางไคลเอ็นต์ของคุณจาก http ไปยัง https ซึ่งไม่ใช่วิธีง่ายๆ

ในทั้งสองกรณี (apache เปลี่ยนเส้นทางอัตโนมัติผ่าน mod_rewrite หรือเปลี่ยนเส้นทางโดยการทดสอบแบบเรียงซ้อน (php/javascript/html) คุณจะต้องตั้งค่า vhost 2 เครื่องของคุณ (หนึ่งรายการสำหรับ http และอีกรายการสำหรับ https) ในวิธีที่เหมาะสม แต่ถือว่าถือว่า สมมติฐานบางอย่าง

ตัวอย่างเช่น (debian - apache 2.2) นี่คือการเปลี่ยนเส้นทางอัตโนมัติที่ทำโดย Apache (เช่นกรณีที่ 1 ที่อธิบายไว้ข้างต้น):

cat /etc/apache2/sites-available/test.cat

# VHOST test

<VirtualHost *:80>

    DocumentRoot /home/www/test
    ServerName www.test.dev

    # ######################
    # Redirect commons
    # ######################
    RewriteEngine on
    # Case of vhosts
    RewriteOptions Inherit

    # ######################
    # Redirect (empty index)
    # ######################

    # Condition 1 to redirect : request matching with the server
    RewriteCond %{HTTP_HOST}   ^www\.test\.dev [NC]

    # Condition 2 to redirect : non empty HOST
    RewriteCond %{HTTP_HOST}   !^$

    # Automatic Empty requests Redirect
    RewriteRule ^(.*)/$ /index.php


    # ######################
    # Redirect to SSL
    # ######################
    RewriteCond %{HTTP_HOST}   ^www\.test\.dev [NC]
    RewriteCond %{HTTP_HOST}   !^$
    RewriteCond %{SERVER_PORT} ^80$
    RewriteCond %{REQUEST_URI} /

    # Redirection
    RewriteRule ^/(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]

</VirtualHost>

โฮสต์เสมือนที่สองสำหรับ SSL : cat /etc/apache2/sites-available/test-ssl

# VHOST for ssl

DocumentRoot "/home/www/test"
ServerName www.test.dev

    # SSL
    SSLEngine on
    SSLCACertificateFile /etc/apache2/ssl/cur_cert/ca.pem
    SSLCertificateFile /etc/apache2/ssl/cur_cert/serveur.pem
    SSLCertificateKeyFile /etc/apache2/ssl/cur_cert/serveur.key


    <Directory "/home/www/test">
        Options FollowSymLinks MultiViews
        AllowOverride None
        Order allow,deny
        Allow from 127.0.0.1 192.168.0.0/16
    </Directory>


    <Directory "/home/www/test/cgi-bin">
        Options FollowSymLinks MultiViews
        AllowOverride None
        Order allow,deny
        Allow from 127.0.0.1 192.168.0.0/16
        Options +ExecCGI
        AddHandler cgi-script .cgi
    </Directory>

</VirtualHost>

Your case might defer slightly from this, eg you will not have the redirect portion in the 1st vhost, but only a simple vhost and the second one for https (ssl). The redirection will be done by php/javascript once you have achieved your mysql checks.

นี่คือตัวอย่างนามธรรมจากคลาส php สำหรับวิธีเรียงซ้อนสวิตช์จาก http เป็น https โดยใช้ php จากนั้น javascript จากนั้น html :

public function Redirect($url){

    if (TRUE !== Validator::isValidURL($url))
        die ("FATAL ERR: url not valid");

    // PHP ABSOLUTE URL REDIRECT (HTTP1.1)
    if (!headers_sent()) {

        header("Status: 200");
        header("Cache-Control: no-cache, must-revalidate"); // required for HTTP/1.1
        header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // past Date
        header("Pragma: no-cache");
        header('Location: '.$url); // note: 302 code return by default with "Location"
        flush();
        exit();

        // if headers are already sent... do javascript redirect... if javascript is disabled, do html redirect.
    } else {

        // Js redirect
        echo '<script type="text/javascript">';
        //echo "<!--";
        echo 'document.location="'. $url .'";';
        //echo "//-->";
        echo '</script>';

        // HTML redirect if js disabled
        echo '<noscript>';
        echo '<meta http-equiv="refresh" content="0;url="'.$url.'" />';
        echo '</noscript>';

        exit();
    }

    return FALSE;

} /* end of method (redirect) */

หวังว่าจะช่วยให้คุณเข้าใจวิธีดำเนินการและปรับแนวทางนี้ให้เหมาะกับกรณีของคุณได้ดีขึ้น