كيفية إنشاء شهادة موقعة ذاتيا مع openssl؟




certificate ssl-certificate (9)

توليد مفاتيح

أستخدم /etc/mysql لتخزين /etc/apparmor.d/usr.sbin.mysqld لأن /etc/apparmor.d/usr.sbin.mysqld يحتوي على /etc/mysql/*.pem r .

sudo su -
cd /etc/mysql
openssl genrsa -out ca-key.pem 2048;
openssl req -new -x509 -nodes -days 1000 -key ca-key.pem -out ca-cert.pem;
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem -out server-req.pem;
openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem;
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem -out client-req.pem;
openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem;

إضافة التكوين

/etc/mysql/my.cnf

[client]
ssl-ca=/etc/mysql/ca-cert.pem
ssl-cert=/etc/mysql/client-cert.pem
ssl-key=/etc/mysql/client-key.pem

[mysqld]
ssl-ca=/etc/mysql/ca-cert.pem
ssl-cert=/etc/mysql/server-cert.pem
ssl-key=/etc/mysql/server-key.pem

في إعدادي ، تم تسجيل خادم أوبونتو على: /var/log/mysql/error.log

ملاحظات المتابعة:

  • SSL error: Unable to get certificate from '...'

    قد يتم رفض الوصول إلى ملف Cert الخاص بك إذا لم يكن في تكوين apparmors . كما هو مذكور في الخطوات السابقة ^ ، قم بحفظ جميع .pem كملفات .pem في الدليل /etc/mysql/ الذي تمت الموافقة عليه افتراضيًا من قبل apparmor (أو تعديل apparmor / SELinux للسماح بالوصول إلى أي مكان قمت بتخزينه فيه.)

  • SSL error: Unable to get private key

    قد لا يدعم إصدار خادم mysql تنسيق rsa:2048 الافتراضي.

    السرية التي تم إنشاؤها rsa:2048 إلى rsa عادي مع:

    openssl rsa -in server-key.pem -out server-key.pem
    openssl rsa -in client-key.pem -out client-key.pem
    
  • تحقق مما إذا كان الخادم المحلي يدعم SSL :

    mysql -u root -p
    mysql> show variables like "%ssl%"; 
    +---------------+----------------------------+
    | Variable_name | Value                      |
    +---------------+----------------------------+
    | have_openssl  | YES                        |
    | have_ssl      | YES                        |
    | ssl_ca        | /etc/mysql/ca-cert.pem     |
    | ssl_capath    |                            |
    | ssl_cert      | /etc/mysql/server-cert.pem |
    | ssl_cipher    |                            |
    | ssl_key       | /etc/mysql/server-key.pem  |
    +---------------+----------------------------+
    
  • التحقق من اتصال بـ db هو SSL مشفر :

    التحقق من الاتصال

    عند تسجيل الدخول إلى مثيل MySQL ، يمكنك إصدار الاستعلام:

    show status like 'Ssl_cipher'; 
    

    إذا لم يكن اتصالك مشفرًا ، فستكون النتيجة فارغة:

    mysql> show status like 'Ssl_cipher'; 
    +---------------+-------+ 
    | Variable_name | Value | 
    +---------------+-------+ 
    | Ssl_cipher    |       |  
    +---------------+-------+ 
    1 row in set (0.00 sec) 
    

    بخلاف ذلك ، سيظهر سلسلة غير صفرية الطول للشرق قيد الاستخدام:

    mysql> show status like 'Ssl_cipher'; 
    +---------------+--------------------+ 
    | Variable_name | Value              | 
    +---------------+--------------------+ 
    | Ssl_cipher    | DHE-RSA-AES256-SHA |  
    +---------------+--------------------+ 
    1 row in set (0.00 sec) 
    
  • يتطلب ssl لاتصال مستخدم محدد ('يتطلب ssl'):

    • SSL

    يخبر الملقم للسماح فقط اتصالات مشفرة SSL للحساب.

    GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost'
      REQUIRE SSL;
    

    للاتصال ، يجب على العميل تحديد خيار --ssl-ca لمصادقة شهادة الخادم ، وربما تحديد خيارات -ssl-key و -ssl-cert بشكل إضافي. إذا لم يتم تحديد خيار --ssl-ca ولا خيار --ssl-capath ، فلن يقوم العميل بمصادقة شهادة الخادم.

الرابط البديل: البرنامج التعليمي المطول هنا http://www.madirish.net/214

أقوم بإضافة دعم https إلى جهاز Linux مضمن. لقد حاولت إنشاء شهادة موقعة ذاتيًا من خلال الخطوات التالية:

openssl req -new > cert.csr
openssl rsa -in privkey.pem -out key.pem
openssl x509 -in cert.csr -out cert.pem -req -signkey key.pem -days 1001
cat key.pem>>cert.pem

يعمل هذا ، ولكني حصلت على بعض الأخطاء ، على سبيل المثال ، google chrome:

ربما هذا ليس الموقع الذي تبحث عنه!
شهادة أمن الموقع غير موثوق بها!

هل فاتني شيء؟ هل هذه هي الطريقة الصحيحة لإنشاء شهادة موقعة ذاتيًا؟


هل فاتني شيء؟ هل هذه هي الطريقة الصحيحة لإنشاء شهادة موقعة ذاتيًا؟

من السهل إنشاء شهادة موقعة ذاتيا. أنت فقط تستخدم الأمر openssl req . قد يكون من الصعب إنشاء واحدة يمكن استهلاكها بواسطة أكبر مجموعة من العملاء ، مثل المتصفحات وأدوات سطر الأوامر.

من الصعب لأن المتصفحات لديها مجموعة من المتطلبات الخاصة بها ، وأنها أكثر تقييدا ​​من IETF. يتم توثيق المتطلبات المستخدمة من قبل المتصفحات في CA / متصفح المنتديات (انظر المراجع أدناه). تظهر القيود في مجالين رئيسيين: (1) نقاط الثقة ، و (2) أسماء DNS.

إن المتصفحات الحديثة (مثل المستعرضات التي نستخدمها في 2014/2015) تريد الحصول على شهادة ترتبط بمؤشر الثقة ، وتريد أن يتم تقديم أسماء DNS بطرق معينة في الشهادة. والمتصفحات تتحرك بنشاط ضد شهادات الخادم الموقعة ذاتيا

لا تجعل بعض المتصفحات من السهل استيراد شهادة خادم موقعة ذاتيًا. في الواقع ، لا يمكنك مع بعض المتصفحات ، مثل متصفح Android. لذا فإن الحل الكامل هو أن تصبح السلطة الخاصة بك.

في غياب أن تصبح السلطة الخاصة بك ، يجب عليك الحصول على أسماء DNS الحق في منح الشهادة فرصة أكبر للنجاح. لكنني أشجعك على أن تصبح السلطة الخاصة بك. من السهل أن تصبح السلطة الخاصة بك ، وسوف الجانب خطوة كل القضايا الثقة (من الأفضل أن تثق من نفسك؟).

ربما هذا ليس الموقع الذي تبحث عنه!
شهادة أمن الموقع غير موثوق بها!

ويرجع ذلك إلى أن المتصفحات تستخدم قائمة محددة مسبقًا من نقاط ارتساء الثقة للتحقق من صحة شهادات الخادم. شهادة موقعة ذاتيا لا تتحول إلى نقطة موثوقة.

أفضل طريقة لتجنب ذلك هي:

  1. إنشاء السلطة الخاصة بك (أي ، أن تصبح CA)
  2. قم بإنشاء طلب توقيع شهادة (CSR) للخادم
  3. قم بتوقيع CSR الخاص بالمخدم بمفتاح CA الخاص بك
  4. قم بتثبيت شهادة الخادم على الخادم
  5. قم بتثبيت شهادة المرجع المصدق على العميل

الخطوة 1 - إنشاء السلطة الخاصة بك يعني فقط لإنشاء شهادة موقعة ذاتيا مع CA: true استخدام المفتاح الصحيح والسليم. هذا يعني أن الموضوع والمصدر هما نفس الكيان ، يتم تعيين CA إلى true في القيود الأساسية (يجب أن يتم وضع علامة عليها أيضًا على أنها هامة) ، واستخدام المفتاح هو keyCertSign و crlSign (إذا كنت تستخدم CRLs) ، ومعرف مفتاح الموضوع (SKI) ) هو نفس معرف مفتاح السلطة (AKI).

لتصبح المرجع المصدق الخاص بك ، راجع كيف تقوم بتوقيع طلب توقيع الشهادة مع المرجع المصدق الخاص بك؟ على . بعد ذلك ، قم باستيراد CA الخاص بك إلى Trust Store الذي يستخدمه المستعرض.

الخطوات من 2 إلى 4 تقريبًا ما تفعله حاليًا مع الخادم العام عندما تقوم Startcom خدمات CA مثل Startcom أو CAcert . تسمح لك الخطوة 1 و 5 بتجنب سلطة الطرف الثالث ، والعمل كسلطتك الخاصة (من الأفضل أن تثق من نفسك؟).

أفضل طريقة تالية لتجنب تحذير المتصفح هو الوثوق بشهادة الخادم. ولكن بعض المتصفحات ، مثل المتصفح الافتراضي لنظام التشغيل Android ، لا تتيح لك إجراء ذلك. لذلك لن تعمل على النظام الأساسي مطلقًا.

ستكون مشكلة المتصفحات (وغيرها من وكلاء المستخدم المماثلين) التي لا تثق بالشهادات الموقعة ذاتيا مشكلة كبيرة في إنترنت الأشياء (IoT). على سبيل المثال ، ما الذي يحدث عندما تتصل بمنظم الحرارة أو الثلاجة لبرمجته؟ الجواب ، لا شيء جيد بقدر ما تشعر بتجربة المستخدم.

بدأت مجموعة عمل WebAppSec التابعة لـ W3C في النظر إلى المشكلة. انظر ، على سبيل المثال ، اقتراح: تمييز HTTP على أنه غير آمن .

كيفية إنشاء شهادة موقعة ذاتيا مع openssl؟

الأوامر أدناه وملف التكوين إنشاء شهادة موقعة ذاتيا (كما يوضح لك كيفية إنشاء طلب توقيع). وهي تختلف عن الإجابات الأخرى في أحد النواحي التالية: أسماء DNS المستخدمة للشهادة الموقعة ذاتيًا هي في الاسم البديل للموضوع (SAN) ، وليس الاسم العام (CN) .

يتم وضع أسماء DNS في SAN من خلال ملف التكوين مع سطر subjectAltName = @alternate_names (لا توجد طريقة للقيام بذلك من خلال سطر الأوامر). ثم هناك قسم alternate_names في ملف التكوين (يجب ضبط هذا ليناسب ذوقك):

[ alternate_names ]

DNS.1       = example.com
DNS.2       = www.example.com
DNS.3       = mail.example.com
DNS.4       = ftp.example.com

# Add these if you need them. But usually you don't want them or
#   need them in production. You may need them for development.
# DNS.5       = localhost
# DNS.6       = localhost.localdomain
# DNS.7       = 127.0.0.1

# IPv6 localhost
# DNS.8     = ::1

من المهم وضع اسم DNS في SAN وليس CN لأن كل من IETF و CA / Browser Forums يحددان هذه الممارسة. كما تحدد أيضًا أنه يتم إهمال أسماء DNS في CN (ولكن ليس محظورًا). إذا وضعت اسم DNS في CN ، فيجب تضمينه في شبكة SAN بموجب سياسات CA / B. لذلك لا يمكنك تجنب استخدام الاسم البديل الموضوع.

إذا لم تقم بوضع أسماء DNS في SAN ، فحينئذٍ ستفشل الشهادة في التحقق تحت المستعرض ووكلاء المستخدمين الآخرين الذين يتبعون إرشادات منتدى CA / Browser.

ذات صلة: متصفحات تتبع سياسات منتدى CA / Browser؛ وليس سياسات IETF. هذا هو أحد الأسباب التي تجعل الشهادة التي تم إنشاؤها باستخدام OpenSSL (والتي عادة ما تتبع IETF) لا يتم التحقق منها في بعض الأحيان تحت المتصفح (تتبع المتصفحات CA / B). فهي معايير مختلفة ، ولديها سياسات إصدار مختلفة ومتطلبات التحقق المختلفة.

إنشاء شهادة موقعة ذاتيا (لاحظ إضافة خيار -x509 ):

openssl req -config example-com.conf -new -x509 -sha256 -newkey rsa:2048 -nodes \
    -keyout example-com.key.pem -days 365 -out example-com.cert.pem

إنشاء طلب توقيع (لاحظ عدم وجود خيار -x509 ):

openssl req -config example-com.conf -new -sha256 -newkey rsa:2048 -nodes \
    -keyout example-com.key.pem -days 365 -out example-com.req.pem

طباعة شهادة موقعة ذاتيا :

openssl x509 -in example-com.cert.pem -text -noout

طباعة طلب توقيع :

openssl req -in example-com.req.pem -text -noout

ملف التكوين (تم تمريره عبر خيار -config )

[ req ]
default_bits        = 2048
default_keyfile     = server-key.pem
distinguished_name  = subject
req_extensions      = req_ext
x509_extensions     = x509_ext
string_mask         = utf8only

# The Subject DN can be formed using X501 or RFC 4514 (see RFC 4519 for a description).
#   Its sort of a mashup. For example, RFC 4514 does not provide emailAddress.
[ subject ]
countryName         = Country Name (2 letter code)
countryName_default     = US

stateOrProvinceName     = State or Province Name (full name)
stateOrProvinceName_default = NY

localityName            = Locality Name (eg, city)
localityName_default        = New York

organizationName         = Organization Name (eg, company)
organizationName_default    = Example, LLC

# Use a friendly name here because its presented to the user. The server's DNS
#   names are placed in Subject Alternate Names. Plus, DNS names here is deprecated
#   by both IETF and CA/Browser Forums. If you place a DNS name here, then you 
#   must include the DNS name in the SAN too (otherwise, Chrome and others that
#   strictly follow the CA/Browser Baseline Requirements will fail).
commonName          = Common Name (e.g. server FQDN or YOUR name)
commonName_default      = Example Company

emailAddress            = Email Address
emailAddress_default        = [email protected]

# Section x509_ext is used when generating a self-signed certificate. I.e., openssl req -x509 ...
[ x509_ext ]

subjectKeyIdentifier        = hash
authorityKeyIdentifier  = keyid,issuer

# You only need digitalSignature below. *If* you don't allow
#   RSA Key transport (i.e., you use ephemeral cipher suites), then
#   omit keyEncipherment because that's key transport.
basicConstraints        = CA:FALSE
keyUsage            = digitalSignature, keyEncipherment
subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"

# RFC 5280, Section 4.2.1.12 makes EKU optional
#   CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
#   In either case, you probably only need serverAuth.
# extendedKeyUsage  = serverAuth, clientAuth

# Section req_ext is used when generating a certificate signing request. I.e., openssl req ...
[ req_ext ]

subjectKeyIdentifier        = hash

basicConstraints        = CA:FALSE
keyUsage            = digitalSignature, keyEncipherment
subjectAltName          = @alternate_names
nsComment           = "OpenSSL Generated Certificate"

# RFC 5280, Section 4.2.1.12 makes EKU optional
#   CA/Browser Baseline Requirements, Appendix (B)(3)(G) makes me confused
#   In either case, you probably only need serverAuth.
# extendedKeyUsage  = serverAuth, clientAuth

[ alternate_names ]

DNS.1       = example.com
DNS.2       = www.example.com
DNS.3       = mail.example.com
DNS.4       = ftp.example.com

# Add these if you need them. But usually you don't want them or
#   need them in production. You may need them for development.
# DNS.5       = localhost
# DNS.6       = localhost.localdomain
# DNS.7       = 127.0.0.1

# IPv6 localhost
# DNS.8     = ::1

قد تحتاج إلى القيام بما يلي لمتصفح Chrome. بخلاف ذلك ، قد يشكو Chrome أن الاسم العام غير صالح ( ERR_CERT_COMMON_NAME_INVALID ) . لست متأكدًا من العلاقة بين عنوان IP في شبكة التخزين (SAN) و CN في هذا المثيل.

# IPv4 localhost
# IP.1       = 127.0.0.1

# IPv6 localhost
# IP.2     = ::1

هناك قواعد أخرى تتعلق بالتعامل مع أسماء DNS في شهادات X.509 / PKIX. الرجوع إلى هذه الوثائق للقواعد:

يتم سرد RFC 6797 و RFC 7469 لأنها تكون أكثر تقييدًا من مستندات RFC و CA / B الأخرى. لا يسمح RFC 6797 و 7469 عنوان IP ، إما.


oneliner v2017:

سينت أو إس:

openssl req -x509 -nodes -sha256 -newkey rsa:2048 \
-keyout localhost.key -out localhost.crt \
-days 3650 \
-subj "CN=localhost" \
-reqexts SAN -extensions SAN \
-config <(cat /etc/pki/tls/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=IP:127.0.0.1,DNS:localhost"))

أوبونتو:

openssl req -x509 -nodes -sha256 -newkey rsa:2048 \
-keyout localhost.key -out localhost.crt \
-days 3650 \
-subj "CN=localhost" \
-reqexts SAN -extensions SAN \
-config <(cat /etc/ssl/openssl.cnf <(printf "\n[SAN]\nsubjectAltName=IP:127.0.0.1,DNS:localhost"))

أوصي بإضافة المعلمة -sha256 ، لاستخدام خوارزمية التجزئة SHA-2 ، لأن المتصفحات الرئيسية تفكر في إظهار "شهادات SHA-1" باعتبارها غير آمنة.

نفس سطر الأوامر من الإجابة المقبولة -diegows مع إضافة -2525

openssl req -x509 -sha256 -newkey rsa: 2048 keykey key.pem -out cert.pem -days XXX

مزيد من المعلومات في مدونة Google Security .


فيما يلي الخيارات الموضحة في إجابة @ diegows ، والتي تم وصفها بمزيد من التفاصيل ، من الوثائق :

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days XXX
req

PKCS # 10 طلب شهادة وشهادة توليد فائدة.

-x509

يخرج هذا الخيار شهادة موقعة ذاتيًا بدلاً من طلب شهادة. يتم استخدام هذا عادةً لإنشاء شهادة اختبار أو مرجع مصدق موقّع ذاتيًا.

-newkey arg

يقوم هذا الخيار بإنشاء طلب شهادة جديد ومفتاح خاص جديد. تأخذ الحجة واحدة من عدة أشكال. rsa: nbits ، حيث nbits هو عدد وحدات البت ، ينشئ حجمًا أساسيًا في RSA.

-keyout filename

هذا يعطي اسم الملف لكتابة المفتاح الخاص الذي تم إنشاؤه حديثاً إلى.

-out filename

هذا يحدد اسم ملف الإخراج للكتابة إلى أو الإخراج القياسي بشكل افتراضي.

-days n

عندما يتم استخدام الخيار -x509 هذا يحدد عدد الأيام للمصادقة على الشهادة. الافتراضي هو 30 يومًا.

-nodes

إذا تم تحديد هذا الخيار ، في حالة إنشاء مفتاح خاص ، لن يتم تشفيره.

الوثائق في الواقع أكثر تفصيلا مما سبق ، أنا فقط تلخيصه هنا.


لا يمكنني التعليق ، لذلك سنضع هذا كإجابة منفصلة. لقد وجدت بعض المشكلات في الإجابة المتفق عليها أحادية الخطوط:

  • يتضمن الخط الواحد عبارة مرور في المفتاح.
  • يستخدم الشريط الأحادي SHA1 الذي في العديد من المتصفحات يلقي التحذيرات في وحدة التحكم.

إليك إصدارًا مبسّطًا يزيل عبارة المرور ويرفع مستوى الأمان لقمع التحذيرات ويتضمن اقتراحًا في التعليقات للمرور في -subj لإزالة قائمة الأسئلة الكاملة:

openssl genrsa -out server.key 2048
openssl rsa -in server.key -out server.key
openssl req -sha256 -new -key server.key -out server.csr -subj '/CN=localhost'
openssl x509 -req -sha256 -days 365 -in server.csr -signkey server.key -out server.crt

استبدل "localhost" بأي مجال تطلبه. سوف تحتاج إلى تشغيل الأمرين الأولين واحدا تلو الآخر حيث سيطالب openssl بعبارة المرور.

للجمع بين الاثنين في ملف .pem:

cat server.crt server.key > cert.pem

هذا هو البرنامج النصي الذي استخدمه في المربعات المحلية لتعيين SAN (subjectAltName) في شهادات موقعة ذاتيًا.

يأخذ هذا البرنامج النصي اسم المجال (example.com) ويقوم بإنشاء SAN لـ *. example.com و example.com في نفس الشهادة. يتم التعليق على الأقسام أدناه. اسم البرنامج النصي (على سبيل المثال generate-ssl.sh ) وأعطها أذونات قابلة للتنفيذ. ستتم كتابة الملفات إلى نفس الدليل مثل البرنامج النصي.

يتطلب Chrome 58 an an an أن يتم تعيين SAN في شهادات موقعة ذاتيًا.

#!/usr/bin/env bash

# Set the TLD domain we want to use
BASE_DOMAIN="example.com"

# Days for the cert to live
DAYS=1095

# A blank passphrase
PASSPHRASE=""

# Generated configuration file
CONFIG_FILE="config.txt"

cat > $CONFIG_FILE <<-EOF
[req]
default_bits = 2048
prompt = no
default_md = sha256
x509_extensions = v3_req
distinguished_name = dn

[dn]
C = CA
ST = BC
L = Vancouver
O = Example Corp
OU = Testing Domain
emailAddress = [email protected]$BASE_DOMAIN
CN = $BASE_DOMAIN

[v3_req]
subjectAltName = @alt_names

[alt_names]
DNS.1 = *.$BASE_DOMAIN
DNS.2 = $BASE_DOMAIN
EOF

# The file name can be anything
FILE_NAME="$BASE_DOMAIN"

# Remove previous keys
echo "Removing existing certs like $FILE_NAME.*"
chmod 770 $FILE_NAME.*
rm $FILE_NAME.*

echo "Generating certs for $BASE_DOMAIN"

# Generate our Private Key, CSR and Certificate
# Use SHA-2 as SHA-1 is unsupported from Jan 1, 2017

openssl req -new -x509 -newkey rsa:2048 -sha256 -nodes -keyout "$FILE_NAME.key" -days $DAYS -out "$FILE_NAME.crt" -passin pass:$PASSPHRASE -config "$CONFIG_FILE"

# OPTIONAL - write an info to see the details of the generated crt
openssl x509 -noout -fingerprint -text < "$FILE_NAME.crt" > "$FILE_NAME.info"

# Protect the key
chmod 400 "$FILE_NAME.key"

يقوم هذا البرنامج النصي أيضًا بكتابة ملف معلومات حتى تتمكن من فحص الشهادة الجديدة والتحقق من تعيين SAN بشكل صحيح.

                ...
                28:dd:b8:1e:34:b5:b1:44:1a:60:6d:e3:3c:5a:c4:
                da:3d
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Subject Alternative Name: 
            DNS:*.example.com, DNS:example.com
Signature Algorithm: sha256WithRSAEncryption
     3b:35:5a:d6:9e:92:4f:fc:f4:f4:87:78:cd:c7:8d:cd:8c:cc:
     ...

إذا كنت تستخدم Apache ، فيمكنك حينئذٍ الإشارة إلى الشهادة المذكورة أعلاه في ملف التهيئة الخاص بك مثل:

<VirtualHost _default_:443>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/htdocs

    SSLEngine on
    SSLCertificateFile path/to/your/example.com.crt
    SSLCertificateKeyFile path/to/your/example.com.key
</VirtualHost>

تذكر إعادة تشغيل خادم Apache (أو Nginx ، أو IIS) لتصبح الشهادة الجديدة سارية المفعول.


واحد بطانة FTW. أحب أن أبقيه بسيطًا. لماذا لا تستخدم أمر واحد يحتوي على جميع الحجج اللازمة؟ هذه هي الطريقة التي أحبها - يؤدي هذا إلى إنشاء شهادة x509 ومفتاح PEM:

openssl req -x509 \
 -nodes -days 365 -newkey rsa:4096 \
 -keyout self.key.pem \
 -out self-x509.crt \
 -subj "/C=US/ST=WA/L=Seattle/CN=example.com/[email protected]" 

يحتوي هذا الأمر المفرد على جميع الإجابات التي تقدمها عادةً للحصول على تفاصيل الشهادة. بهذه الطريقة يمكنك تعيين المعلمات وتشغيل الأمر ، والحصول على الإخراج الخاص بك - ثم الذهاب للقهوة.

>> المزيد هنا <<


ينشئ الأمر التالي شهادة قوية نسبياً (اعتبارًا من 2018) للمجال example.com صالحة لمدة 3650 يومًا (~ 10 سنوات). يحفظ المفتاح الخاص في example.key والشهادة في example.crt .

openssl req -x509 -newkey rsa:4096 -sha256 -nodes -keyout example.key -out example.crt -subj "/CN=example.com" -days 3650

ونظرًا لأنها شهادة موقعة ذاتيًا ويلزم المستخدمون قبولها يدويًا ، لا يُعتبَر استخدام فترة صلاحية قصيرة أو تشفيرًا ضعيفًا.

في المستقبل ، قد ترغب في استخدام أكثر من 4096 بت لمفتاح RSA وخوارزمية هاش أقوى من sha256 ، ولكن اعتبارًا من 2018 هذه قيم sha256 . فهي قوية بما فيه الكفاية في حين يتم دعمها من قبل جميع المتصفحات الحديثة.

ملاحظة جانبية: من الناحية النظرية يمكنك ترك المعلمة -nodes (التي تعني "لا تشفير DES") ، وفي هذه الحالة ، يمكن تشفير -nodes بكلمة مرور. ومع ذلك ، فإن هذا لا يكاد يكون مفيدًا على الإطلاق لتثبيت الخادم ، لأنك قد تحتاج إلى تخزين كلمة المرور على الخادم أيضًا ، أو يجب عليك إدخالها يدويًا في كل إعادة تشغيل.





x509certificate