گواهی – آیا ما باید یک کلید خصوصی بر روی توزیع کننده بار داشته باشیم

ما سناریوی زیر را داریم:

  • 2 Load Balancers Serving Traffic From Web Servers
  • ما گواهی SSL با کلید خصوصی در سرورهای وب نصب کرده ایم

اکنون سوال من این است که اگر ما نیاز به تمدید گواهینامه مشابه در بارگرهای بار، نیاز دارم –

  1. فقط گواهی (.cer / .der) را بر روی ترازو بار نصب کنید

  2. گواهی را با کلید خصوصی بر روی متعادل کننده بار نصب کنید [19659007] من تعجب می کنم زمانی که یکی از همکاران من به من گفت قدم دوم. چرا باید کلید خصوصی LB را داشته باشم، زمانی که ما قبلا آن را روی سرور Backend نصب کردیم؟

زیرساخت کلید عمومی – PKI: چرا گواهی CA را تهدید می کند؟

با توجه به مدل تهدید SSL / TLS از ssllabs:

https://www.ssllabs.com/downloads/SSL_Threat_Model.png

چرا "اخطار گواهینامه CA" تهدیدی است؟ (در شاخه "Trust (PKI)")
آیا هدف گواهی به طور عمومی در دسترس نیست؟

من درک می کنم، چرا "گواهینامه های CA Rogue CA" تهدیدی است، اما چرا "Certificate CA Certificates" از بین رفته است؟

x.509 تایید هویت امضاهای زنجیره ای – Exchange Security Stack Security Information

هنگامی که یک برنامه کاربردی مشتری یک پرونده گواهی برگ را از یک موجودیت صادر شده توسط CA صادر می کند، چگونه تأیید امضا های Cert را انجام می دهد؟

به طور مشخص، مشخص نیست که آیا یک امضای گواهی برگ فقط رمزنگاری است تایید شده توسط کلید عمومی public key (که در cert تعبیه شده است) یا در صورتی که بعضی از مدارک والد CA در فرآیند رمزگشایی / تأیید امضا وجود داشته باشد.

پس از تایید برگ برگ، و برنامه به زنجیره صادر کننده و براساس گواهی CA متوسط ​​می پردازد، در تأیید امضا مرکزی CA، کلید عمومی کلید ریشه در برخی از راه ها دخالت دارد؟ یا آیا برنامه تنها نیاز به کلید عمومی CA متوسط ​​برای تأیید امضا میانجی دارد؟

tls – گواهی SSL برای WebAPI

ما یک سیستم ساده با یک سرویس REST (WebAPI) داریم که در یک دستگاه (میزبان در IIS در یک پورت سفارشی، شماره پورت 3031) میزبانی می شود و با یک وب سایت میزبانی شده در دستگاه دیگری که با سرویس صحبت می کند

ما می خواهیم هر دو از SSL استفاده کنند، بنابراین درک می کنیم که ما باید دو گواهینامه SSL جداگانه برای استقرار تولید در اینترنت خرید کنیم.

آیا این درست است؟

اگر چنین است، می دانم چگونه درخواست و خرید یک گواهی برای سرویس WebAPI REST … خدمات در یک پورت 3031 سفارشی میزبانی می شود، آیا باید یک گواهی معمولی برای نام دامنه دستگاه که در آن سرویس میزبانی می شود، خرید کنم؟ و سپس باید ابتدا گواهی را روی IIS بر روی آن دستگاه نصب کنم (مثل آن در اینجا توضیح داده شده است: https://docs.microsoft.com/en-us/aspnet/web-api/overview/security/working-with-ssl- در web-api.

چگونه میتوانم تأیید دامنه گواهی خریداری شده را انجام دهم اگر میخواهم از گواهی سرویس REST در یک پورت سفارشی استفاده کنم؟ (برای یک وب سایت به طور منظم)

متاسفم برای نادانی من، من در انجمن جستجو کردم تا پاسخی به موضوع من پیدا کنم، اما من آن را پیدا نکردم، شاید این بدان معناست که دانش من بسیار محدود در مورد گواهینامه ها و امنیت است. 19659007]

openssl – ایجاد گواهی بدون کلید خصوصی یا استفاده از USB eToken

با توجه به این موضوع:

ایجاد گواهی بدون کلید خصوصی با OpenSSL

وضعیت بسیار شبیه من است. من یک USB eToken 5110 JC (Aladdin) داریم که دارای خصوصی شخصی غیر قابل قبول است، زیرا هدف اصلی آن است. بنابراین، من می توانم از pkcs11-tool استفاده کنم – module /lib/libeToken.so.9 -l –pin -s -i و کار می کند. libeToken.so.9 توسط SAC 9.1 (Safenet Authentication Tool) ارائه می شود. تا کنون خیلی خوب است

مشکل من این است: من نیاز به تولید گواهینامه ها و امضای آنها با این eToken دارم. من سعی کردم از موتور pkcs11 با openssl استفاده کنم، بدون موفقیت. ممکن است به علت اشتباه (من سعی کردم https://github.com/OpenSC/libp11 چگونه، اما من اشتباهات زیادی داشته ام، و من رها کردن)

من سعی کردم به استفاده از gpg اما من اشتباهات در حالی که یادگیری کارت .

بنابراین من این موضوع جالب را رسیده ام. از آنجا که من می توانم به راحتی گواهی و کلید عمومی را از usb Token صادر کنم، نوک والنتین بوسی به نظر می رسد خوب است، زیرا می توانم openssl x509 -force_pubkey اجرا کنم. آیا تا به حال صحیح است؟

بنابراین، مشکلی برای انجام این کار چیست؟ من می دانم که امضای فرآیند ایجاد یک هش از برخی داده ها و رمزگذاری با یک کلید خصوصی است. هنگامی که برخی از داده ها به شخصی که با امضای آن ارسال می شود، گیرنده بررسی خواهد کرد که الگوریتم هش کردن چیست، سپس یک هش از داده ها با یک الگوریتم مشابه تولید می کند و در مقایسه با داده های هش رمزگشایی شده با کلید عمومی فرستنده، درست است؟

بنابراین هنگام تولید یک گواهی بدون توجه به اینکه آیا داده از CSR یا stdin ساخته شده است، امضای ساخته شده از طریق کلید عمومی تأیید نشانه دیجیتال را تأیید نخواهد کرد، زیرا هر کسی می تواند این کلید عمومی را دریافت کند و از طرف صاحب eToken تولید گواهی کند. 19659002] بنابراین، چه چیزی در حال حاضر؟ چه چیزی اشتباه می گویم؟

آخرین سوال، داده های رمز شده با کلید خصوصی را می توان با کلید عمومی آن لغو کرد و بالعکس. اما من نمی دانستم که با استفاده از همان کلید (از آنجا که کلیدهای assymetric هستند) امکان رمزگذاری و رمزگشایی وجود دارد