SSL certificaten interne systemen

[beOnt]

Momenteel hebben we een kleine 100 servers onder ons beheer, samen met paar honderd printers access points en dergelijke. Elk van de apparaten hebben een HTTPS website met een self signed certificaat. Tot op heden liet ik dit zijn, maar aangezien we tegenwoordig een security team hebben die effectief al deze websites als een mogelijke vulnerability ziet, is het een eis dat elk van deze apparaten een geldig certificaat moet hebben.

Momenteel hebben we een interne CA server, maar deze is niet onder ons (europees) beheer, en die wordt enkel maar gebruikt voor de windows systemen. Daarbij komt ook dat er redelijk wat externe mensen aanwezig zijn, en dat deze het root certificate van onze CA server niet hebben, waardoor deze bij hen als niet trusted aangegeven wordt. Ik zou natuurlijk bij al deze mensen het certificaat kunnen importeren, maar dit is niet wenselijk

Als makkelijke oplossing was ik eigenlijk aan het denken om een publiek certifcaat aan te kopen voor meerdere jaren, en deze te gebruiken op onze interne apparaten.

Nu zit ik met de volgende vragen:

1. Is dit een goed idee? Tot zover ik weet kan ik geen interne domain namen gebruiken voor een publiek certificaat; bijv. "EU.LOCAL", en moet ik "*.Website.com" gebruiken
2. Moet dit een wildcard certificaat zijn?
3. Is er een gemakkelijke oplossing om certificaten te beheren op een multi vendor omgeving? Bijv. Aruba access points, cisco access points, ILO's, Vcenters... ? Hoe doen jullie dit?
4. Bestaat er een makkelijke manier om deze te renewen?

Bedankt

[remco91]

1.Is dit een goed idee? Tot zover ik weet kan ik geen interne domain namen gebruiken voor een publiek certificaat; bijv. "EU.LOCAL", en moet ik "*.Website.com" gebruiken

Hiervoor moet je inderdaad externe namen gebruiken, dit is ook sowieso beter voor de toekomst wanneer je office 365 wil gaan implementeren, maar uiteraard veel werk.

2.Moet dit een wildcard certificaat zijn?

Wanneer je zoveel servers met verschillende namen hebt is dit inderdaad wel aan te bevelen anders moet je voor elke naam een nieuwe certificaat aanschaffen


De overige vragen heb ik geen ervaring mee.

[wagenveld]

Om op een paar honderd devices/servers allemaal hetzelfde wildcard certificaat te gaan gebruiken lijkt mij ook niet super handig.
https://www.sslshopper.co...ildcard-certificates.html

Voor 90% van je interne certificaten zou ik gewoon de interne Windows PKI gebruiken, je kunt deze ook prima inzetten voor niet Windows systemen. Denk wel even aan een correct geconfigureerde CDP.
Voor iets als Radius of webservers waar veel non-domain joined machines bij moeten kunnen kun je dan een publiek certificaat aanschaffen.

[Killah_Priest]

remco91 schreef op woensdag 26 juli 2017 @ 10:44:
[...]

Wanneer je zoveel servers met verschillende namen hebt is dit inderdaad wel aan te bevelen anders moet je voor elke naam een nieuwe certificaat aanschaffen

Vanuit een security perspectief is dit heel slecht. Mocht je private key uitlekken dan kun je vervolgens op 100 devices een nieuw certificaat uitrollen.

Voor het gemak is een wildcard certificaat natuurlijk wel het beste

[remco91]

Killah_Priest schreef op woensdag 26 juli 2017 @ 11:07:
[...]


Vanuit een security perspectief is dit heel slecht. Mocht je private key uitlekken dan kun je vervolgens op 100 devices een nieuw certificaat uitrollen.

Voor het gemak is een wildcard certificaat natuurlijk wel het beste

Dat is uiteraard altijd de afweging die gemaakt moet worden veiligheid en beheersbaarheid.

[VHware]

Andere optie is natuurlijk Let's Encrypt gebruiken (DNS-Challenge), als de DNS-provider van je publieke domeinnaam een API heeft waar je tegen kan babbelen om geautomatiseerd TXT-records te kunnen maken ter verificatie.

Kan handmatig uiteraard, maar dat wil je echt niet elke 90 dagen doen voor al je servers/devices.

Hier een voorbeeld met Powershell waarbij dit in Veeam wordt gebruikt:
https://www.virtualtothec...-for-veeam-cloud-connect/

Op een Linux-systeem kan je deze tutorial gebruiken:
https://www.aaflalo.me/20...t-with-dehydrated-dns-01/

Mocht je TransIP als DNS-provider gebruiken, dan kan je hier de DNS-hook downloaden welk je met Dehydrated kan gebruiken:

https://github.com/sigio/dehydrated-transip-dns-validator

[ Voor 62% gewijzigd door VHware op 29-07-2017 15:33 . Reden: links toegevoegd ]

[Verwijderd]

Een wildcard certificate kan een goede oplossing wezen ondanks de eerder genoemde bezwaren. Het aangehaalde artikel heeft een genuanceerde conclusie:

All-in-all, wildcard certificates offer a very powerful and safe solution for securing multiple subdomains. It is important to understand the risks you are taking but in most situations they are minimal and allow you to save hundreds, if not thousands, of dollars. And every dollar counts these days.

Ik heb zelf een reverse proxy staan voor de web interfaces van de netwerk hardware die we gebruiken. De motivatie hiervoor is :

• SSL implementatie kan verschillen tussen devices. Met de reverse proxy kun je ervoor zorgen dat de SSL implementatie voor alle devices voldoet aan moderne standaarden (Zoals een A rating bij de SSL Server Test van qualis https://www.ssllabs.com/ssltest/).
• De web interface van de sommige/veel netwerk hardware is lek. Zo lukt het mij bij sommige hardware van HP en ZyXell de configuratie te downloaden zonder in te loggen op het systeem. Waarschijnlijk zitten er meer lekken in de web interface. Op de reverse proxy kun je http authenticatie configureren waar je eerst aan moet voldoen voordat je bij de web interface van de netwerk hardware komt.
• Mogelijkheid tot automatiseren Let's Encrypt certificaten.

[johnkeates]

We lossen het op twee manieren op (die eigenlijk al genoemd zijn):

1. We hebben een aantal HAProxy ACL's die Let's Encrypt requests afvangen en met een whitelist checken of die überhaupt in een CI staan en dan de challenge accepteren, waarna een intern apparaat (dat niet extern te bereiken is) dus een geldig certificaat kan krijgen. Sommige apparaten hebben te weinig OS om daar wat mee te doen (embedded OS, Windows, RTOS enz.) en dan gebruiken we een auto-renewal VM die niks anders doet dan certificaten ophalen en installeren op de devices die dat zelf niet kunnen

2. Sommige apparaten zijn zo kneuzig opgezet dat ze alleen maar self-signed certs kunnen gebruiken, of totaal geen TLS kunnen (maar dan SSLv3, of bijv niet hoger dan TLS 1.0 - heeft allemaal weinig zin). Die hebben een eigen verbinding die via een transparante reverse proxy of TLS tunnel met de rest van het netwerk mogen praten, dit werkt alleen voor UDP (nog?) niet, maar voor TCP wel en op protocol niveau ook met HTTP, IMAP, FTP, POP, SMTP, IPP enz. Op die manier kunnen we hun self-signed cert lokaal op de proxy pinnen, en krijgen de clients een geldige TLS 1.2 verbinding.