Nu există un simplu răspuns da/nu la această întrebare, mă tem.
Dacă Kestrel și Apache rulează în aceeași casetă, atunci utilizați efectiv un certificat doar pentru că Kestrel așteaptă unul. Nu oferă securitate și Este mai sigur? întrebarea nu este aplicabilă.
Dacă Kestrel și Apache sunt în cutii diferite, atunci este puțin mai complex. Dacă cele două casete sunt într-o rețea de încredere, ați putea argumenta la fel ca mai sus - certificatele sunt acolo doar pentru că Kestrel așteaptă unul.
Dacă rețeaua nu este de încredere, acum veți avea nevoie de puțină securitate. Certificatul oferă identitatea mașinii necesară pentru a instiga o conexiune TLS. Indiferent dacă utilizați un certificat autosemnat sau un certificat semnat CA pentru aceasta, adaugă mai multe opțiuni.
- Dacă aplicația Kestrel utilizează un FQDN intern (de ex.
aplicație.locală) și CA nu dorește să certifice astfel de nume (de exemplu, un CA comercial nu va face acest lucru), atunci sunteți forțat să utilizați certificate autosemnate.
- Dacă CA este internă și dorește să certifice nume locale, atunci puteți lua în considerare utilizarea unui CA pentru certificatul Kestrel.
Deci, presupunând deocamdată că puteți utiliza un certificat CA pentru Kestrel, în continuare trebuie să vă întrebați de ce ar trebui să faceți acest lucru:
Un certificat semnat CA devine, în general, util într-un scenariu unu-la-mulți. Dacă aveți un server și mai multe părți de încredere (clienți), atunci un certificat emis de CA asigură:
- Părțile care se bazează trebuie doar să aibă încredere în CA și fiecare certificat emis este implicit de încredere (un certificat autosemnat trebuie să fie de încredere de către toți clienții);
- părțile care se bazează nu trebuie să revizuiască guvernanța și procesele operaționale ale fiecărui server în care doresc să aibă încredere, deoarece pot presupune că, dacă CA l-a certificat, atunci este demn de încredere;
- totul funcționează după reînnoirea certificatului (comparativ cu un certificat autosemnat, care ar trebui distribuit către toate clienți după reînnoire);
- revocarea funcționează (nu există conceptul de revocare pentru certificatele autosemnate - dacă certificatul serverului este compromis, trebuie să eliminați certificatul din toate clienti);
Cu toate acestea, dacă vă aflați într-un scenariu unu-la-unu (cum ar fi între un proxy invers și un server de aplicații), atunci un CA aduce mai puține beneficii (deciziile de încredere sunt mai ușoare, reînnoirea este ușoară, iar dacă serverul este compromis, pur și simplu eliminați certificatul de la un client). De fapt, dacă nu aveți un CA disponibil, costul general pentru construirea și gestionarea unui CA doar pentru conexiunea dintre serverul de aplicații și proxy invers este atât de mare încât să nu merite.
Pentru cei din urmă, singurul dezavantaj al utilizării unui certificat autosemnat ar putea fi lipsa managementului central. Multe CA ajută la gestionarea ciclului de viață al certificatelor emise, chiar dacă este la fel de simplu un e-mail automat pentru a vă aminti că certificatul este pe cale să expire, sau la fel de complex ca reînnoirile automate. Un certificat autosemnat este gestionat de dvs. Pentru a ajuta la atenuarea acestui lucru, unele organizații folosesc instrumente de gestionare a ciclului de viață al certificatelor pentru a-și gestiona certificatele și, dacă instrumentul poate monitoriza și certificatul autosemnat, atunci acesta se ocupă de această problemă.
Deci, pentru a rezuma, dacă CA dumneavoastră oferă un serviciu suplimentar de gestionare a ciclului de viață care vă ajută să gestionați certificatul, atunci ar putea fi demn de luat în considerare; dar altfel, într-un scenariu unu-la-unu, cum ar fi între un server de aplicații și un proxy invers, nu are nicio diferență dacă utilizați un certificat autosemnat sau un certificat semnat CA.
Dacă mergeți pe calea unui certificat emis de CA pentru serverul de aplicații, aveți mai multe decizii:
Dacă aplicația și proxy invers se află în aceeași casetă, puteți lua în considerare în siguranță utilizarea unui certificat între ele - este puțin probabil să vă aflați într-o situație în care un serviciu este compromis, în timp ce celălalt este încă de încredere. Ați (ar trebui) să presupuneți că toate certificatele dintr-o cutie sunt compromise dacă unul este, așa că, în general, nu există niciun beneficiu real în certificatele separate.
Dacă aplicațiile sunt în casete diferite, atunci ați putea fi într-o situație în care una este compromisă, în timp ce cealaltă nu este. În pregătirea pentru astfel de cazuri, ar trebui să aveți un certificat diferit pe fiecare cutie.
Rețineți că, în timp ce cele de mai sus discută despre comunicarea dintre serverul de aplicații și proxy-ul invers, puteți încerca același raționament cu Server de identitate 4 (orice ar fi asta).
