Self-signed certificate

In cryptography and computer security, self-signed certificates are public key certificates that are not issued by a certificate authority (CA). These self-signed certificates are easy to make and do not cost money. However, they do not provide any trust value.

For instance, if a website owner uses a self-signed certificate to provide HTTPS services, people who visit that website cannot be certain that they are connected to their intended destination. For all they know, a malicious third-party could be redirecting the connection using another self-signed certificate bearing the same holder name. The connection is still encrypted, but does not necessarily lead to its intended target. In comparison, a certificate signed by a trusted CA prevents this attack because the user's web browser separately validates the certificate against the issuing CA. The attacker's certificate fails this validation.

Self-signed certificates can be created for free, using a wide variety of tools including OpenSSL, Java's keytool, Adobe Reader, wolfSSL and Apple's Keychain. They are easy to customize; e.g, they can have larger key sizes or hold additional metadata. Their use doesn't involve the problems of trusting third parties that may improperly sign certificates. Self-signed certificate transactions usually present a far smaller attack surface by eliminating both the complex certificate chain validation,^[1] and certificate revocation checks like CRL and OCSP.

In a CA-based PKI system, parties engaged in secure communication must trust a CA, i.e. place the CA certificates in a whitelist of trusted certificates. Developers of web browsers may use procedures specified by the CA/Browser Forum to whitelist well-known, public certificate authorities. Individual groups and companies may whitelist additional, private CA certificates. The trust issues of an entity accepting a new self-signed certificate are similar to the issues of an entity trusting the addition of a new CA certificate. The parties in a self-signed PKI must establish trust with each other (using procedures outside the PKI), and confirm the accurate transfer of public keys e.g. compare the certificate's cryptographic hash out of band.

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

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

لا يمكن الوثوق بالقيم الموجودة في الشهادة الموقعة ذاتيًا إلا إذا تم التحقق منها خارج نطاق الشهادة أثناء قبولها، وكان هناك طريقة للتحقق من عدم تغيير الشهادة الموقعة ذاتيًا بعد الوثوق بها. على سبيل المثال، تتضمن عملية الوثوق بشهادة موقعة ذاتيًا التحقق اليدوي من تواريخ الصلاحية، ويتم إدراج تجزئة الشهادة في القائمة البيضاء. ^{[ 2 ]} عند تقديم الشهادة إلى جهة للتحقق منها، تتحقق هذه الجهة أولًا من تطابق تجزئة الشهادة مع التجزئة المرجعية في القائمة البيضاء، وإذا تطابقت (مما يشير إلى أن الشهادة الموقعة ذاتيًا هي نفسها التي تم الوثوق بها سابقًا)، فيمكن حينها الوثوق بتواريخ صلاحية الشهادة. يمكن الاطلاع على المعالجة الخاصة لحقول شهادة X.509 للشهادات الموقعة ذاتيًا في RFC 3280. ^{[ 1 ]}

يختلف إلغاء الشهادات الموقعة ذاتيًا عن إلغاء الشهادات الموقعة من قبل هيئة إصدار الشهادات. فمن حيث المبدأ، لا يمكن لأي جهة (سواء كانت هيئة إصدار شهادات أو غيرها) إلغاء شهادة موقعة ذاتيًا. ولكن يمكن إبطال شهادة هيئة إصدار شهادات موقعة ذاتيًا عن طريق إزالتها من قائمة الشهادات الموثوقة. ^{[ 3 ]}

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

يُستخدم مصطلحا "موقع ذاتيًا" و"صادر ذاتيًا" أحيانًا بشكل متبادل، بل ويُستخدم مصطلح "شهادة موقعة ذاتيًا" أحيانًا بشكل خاطئ للإشارة إلى شهادة صادرة عن جهة إصدار شهادات خاصة (غير موثوق بها علنًا). ^{[ 4 ] [ 5 ] [ 6 ]}

يُعرّف RFC 5280 الشهادات الموقعة ذاتيًا بأنها "شهادات صادرة ذاتيًا حيث يمكن التحقق من التوقيع الرقمي بواسطة المفتاح العام المرتبط بالشهادة"، ^{[ 7 ]} بينما تُعرّف الشهادة الصادرة ذاتيًا بأنها شهادة "يكون فيها المُصدر والموضوع كيانًا واحدًا". وبينما يقتصر تعريف RFC هذا، بالمعنى الدقيق، على شهادات هيئة التصديق، فلا يوجد ما يبرر اعتماده أيضًا على شهادات الكيانات النهائية.

• سلطة إصدار الشهادات §  ضعف تنفيذ مخطط الطرف الثالث الموثوق به
• X.509 ، المعيار الذي يصف التنسيق الأكثر استخدامًا لتخزين الشهادات
• Let's Encrypt ، وهي جهة إصدار شهادات توفر شهادات مجانية تم التحقق من صحتها من قبل النطاق ^{[ 8 ]}