Intermediate CA fontossága

Adott cégnél felmerült az a probléma, hogy a levelező-kliens egy tanúsítvánnyal aláírt levél esetén panaszkodott az aláírásra (mindamellett, hogy a láncolat fő-tanúsítványa érvényes is volt és telepítve is!)

   

A sárga háromszög az alábbi hibaüzenetet rejtette, itt a “Részletek” a fontos:

Ha megnyitottuk, akkor ez a hibaüzenet fogadta a felhasználót:

Hiba:

A rendszer nem tudja érvényesíteni az aláírás létrehozásához használt tanúsítványt, mert a tanúsítvány kibocsátójának hitelességi tanúsítványa nem érhető el vagy érvénytelen.

A rendszer nem tudja meghatározni, hogy az aláírás létrehozásához használt hitelességi tanúsítvány megbízható-e vagy sem.

Aláírta: xx@domain.com, módszer: RSA/SHA256 idő: .

Szokás szerint a Részletek segítenek, akkor az aláírásnál ez a hibaüzenet fogad:

Hiba: Problémák léptek fel az aláírás létrehozásához használt hitelességi tanúsítvány érvényesítésekor.

Ezek után jön a valódi megoldás: ha rámegyünk a “Tanúsítvány megtekintése” gombra, akkor a köztes CA (mivel megbízható Root CA-tól lett kiállítva) automatikusan bekerül a felhasználó-szintű köztes tanúsítvány-kiállító-tárolóba. Ha ilyenkor megnézzük a “Certificate path“-t, akkor azt tapasztaljuk, hogy minden csupa pipa – sőt, ha bezárjuk sorra az ablakokat, amiken keresztül idáig jutottunk, mindegyiknél megjelenik a pipa.

S hogy miként lehet ezt a sok-sok ablakot elkerülni? Például, ha a láncolat összes elemét előre felvesszük a tanúsítványtárba (ez ugye mehetne akár gép-szinten), hiszen így tudja ellenőrizni a hitelességet – ehhez pedig fel tudjuk használni az előző lépések során látott/kapott tanúsítványok exportjait 🙂

TLS 1.0 és 1.1

Mint azt régebben már tudtuk, a nemrég megjelent Edge/Chrome 98-as verziójával kezdve megszűnik a TLS 1.0 és 1.1 támogatása. Ezt azok fogják leginkább észrevenni, akik régebbi rendszereken “ragadtak” ilyen/olyan okból kifolyólag, s a protokollt sem frissítették.

Ilyen esetben az alábbi üzenet jelenik meg:

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Megoldás az természetesen kiszolgáló-függő, ha be lehet kapcsolni a TLS 1.2-t, akkor egy ideig meg lehet úszni a cseréjét, de ez mindenképp egy figyelmeztetés kell legyen az üzemeltetőnek. Sajnos elég sokan most kaptak észhez, s nyomják a piros gombot, amikor rájönnek, hogy most már telefonról/böngészőből nem használható az oldaluk/levelezésük…

Anélkül, hogy túlzottan belemennénk a részletekbe, a blogon már többször említett openssl-el ugyanakkor tudjuk tesztelni, hogy milyen titkosítási protokoll van támogatva:

openssl s_client -connect kiszolgalo.hu:443 -tls1

openssl s_client -connect kiszolgalo.hu:443 -tls1_1

openssl s_client -connect kiszolgalo.hu:443 -tls1_2

Amennyiben visszakapjuk a publikus tanúsítványt (meg a többi lekérdezett érték is jó), akkor a kiszolgáló támogatja a jelzett protokollt, ellenkező esetben vagy még “reszelnünk” kell rajta, vagy (ha annyira elavult) lecserélni egy korszerűbb változatra.

2022 januári frissítések

Nem szoktam minden apróságról írogatni (ezért most ennek kapcsán sem mennék bele technikai részletekbe), viszont úgy tűnik, még nem mindenkihez jutott el a információ, hogy a januári frissítés-csomag gondot okozhat az L2TP/IPSEC VPN felépítésében. Tudom, hogy rengeteg más hiba is javításra került benne, de attól még nem győzzük hangsúlyozni a tesztelés fontosságát. Az érintett foltok KB5009543 (Win10) és KB5009566 (Win11) eltávolítása segíthet.

@Soder, igen, tudom, még mindig szívás 😀

Exchange Y2K22 hiba

A Microsoft (s elsősorban az Exchange 2016/2019) fejlesztői sokat fognak mostanában csuklani, mivel a világon nagyon sok rendszergazda miattuk fogja az új évet hibakereséssel kezdeni.

A gond ott van, hogy a levelek beragadnak a kimenő sorba, „Message deferred by categorizer agent” hibaüzenettel. Az ok az, hogy az „MS Filtering Engine Update” megkapta a legújabb, “220101001” verziószámú (később a 02 végű) frissítését – viszont a verziószám tárolására használt változóban a „22” kezdetű érték már nem fér el (a pontos technikai részletek – signed long/unsigned long – már nem a cikk témája).

A megoldás aránylag egyszerű: kikapcsolni (Disable-AntiMalwareScanning.ps1) vagy átlépni a malware-szűrőt:

Set-MalwareFilteringServer -BypassFiltering $True -identity <Kiszolgálónév>

A Microsoft Exchange Transport újraindítása után szépen elindulnak a levelek 😊

Update: Javítás itt: https://techcommunity.microsoft.com/t5/exchange-team-blog/email-stuck-in-exchange-on-premises-transport-queues/ba-p/3049447

Exchange vs AD-séma

Nemrég egyik olvasóm megkeresett, hogy segítsek neki, mert a séma-verziókról szóló cikkem segített neki, de az ott található linkek elavultak/érvénytelenek, a verziószámokról nem is beszélve.

Azóta valóban sok víz lefolyt a Dunán 🙂 Az AD-sémák felsorolásától most eltekintenék, a kolléga inkább Exchange-oldalról közelítette meg a témát. Nos, annak lekérdezését is frissítsük akkor, hiszen PS-ből csodálatosan lekérdezhető:

Import-Module ActiveDirectory

# Exchange Schema Version (forest)

$sc = (Get-ADRootDSE).SchemaNamingContext

$ob = “CN=ms-Exch-Schema-Version-Pt,” + $sc

Write-Output “(Forest Exch schema) RangeUpper: $((Get-ADObject $ob -pr rangeUpper).rangeUpper)”

# Exchange Object Version (forest)

$cc = (Get-ADRootDSE).ConfigurationNamingContext

$fl = “(objectClass=msExchOrganizationContainer)”

Write-Output “(Forest Exch object) ObjectVersion (Configuration): $((Get-ADObject -LDAPFilter $fl -SearchBase $cc – pr objectVersion).objectVersion)”

# Exchange Object Version (domain)

$dc = (Get-ADRootDSE).DefaultNamingContext

$ob = “CN=Microsoft Exchange System Objects,” + $dc

Write-Output “(Domain Exch object) ObjectVersion (Default): $((Get-ADObject $ob -pr objectVersion).objectVersion)”

Ha viszont csak a pőre számok érdekelnek bennünket, itt található egy aktuális lista (mondjuk más sorrendben, mint a fenti lekérdezés, de a kiíratásnál betettem az itt használt megnevezést is).

Ha pedig arra vagyunk kíváncsiak, hogy melyik Exchange CU esetén változik a séma, itt (2016 esetén itt) kapunk rá választ.

RDP tanúsítvány saját CA-val

Régebben, amikor sárga ablakokról beszéltünk, nem ejtettünk szót egy másik megoldásról. Jellemzően, mi van, ha van belső CA-nk: lehet-e használni az általa kiállított tanúsítványokat az RDP-kapcsolatokhoz? Nos, igen, bár kell hozzá pár dolog (hacsak nem akarjuk kézzel, egyesével ujjlenyomat alapján hozzárendelni).

Egyrészt a tanúsítvány kell tartalmazza vagy a “Server Authentication” vagy a “Remote Desktop Authentication” EKU-t. Az első, egyértelmű – de a második nincs a listában. Ilyenkor megtehetjük az, hogy felvesszük “custom” meghatározásként, 1.3.6.1.4.1.311.54.1.2 értékkel.

(Ha véletlenül elgépeltük, vagy mondjuk át akarjuk nevezni, akkor ADSIEdit a barátunk, a konfigurációs konténer:

CN=OID,CN=Public Key Services,CN=Services,CN=Configuration )

Tapasztalatom alapján javasolt, hogy ne csak CN-ben, hanem SAN-ban is legyen benne a gép “igazi” FQDN-je (ha más névvel akarunk rá hivatkozni, természetesen az is benne lehet a SAN-ban). A tanúsítvány helyét ne bántsuk, maradjon a “Personal” tárolóban (ugye az alap önaláírt máshol van).

Ez még nem elég, még “élesítenünk” is kell.

Ehhez Computer Configuration> Policies >Administrative Templates > Windows Components > Remote Desktop Services >Remote Desktop Session Host > Security (régebbi rendszerek esetén “Remote Desktop Session Host” helyett csak “Session Host“) útvonalon a “Server Authentication certificate template” értékét kell kitölteni, a sablon nevével (tudjuk, ez a szóköz nélküli verzió 🙂 ) – extrémebbek a sablon OID-ját is használhatják 🙂 .

Wsus gondok Win 2022 upgrade után

Pár napja publikus lett a Windows 2022 (pl. VLSC*), de az “éles” ismerkedésünk nem indult valami jól. Az egy dolog, hogy szűz telepítésnél hogyan viselkedik, de tudjuk, hogy puding próbája az evés – így mondjuk például egy in-place upgrade már jobban kimutatja a problémákat. Természetesen a felmerülő kérdéseket nem szabad általánosítani, hiszen a helyi sajátosságok is közrejátszanak, majd a jövő megmutatja, hogy ez valóban lokális gond volt-e.

Adott cégnél próbálták ki az upgrade-et egy 2019-ről. Maga a telepítés sikeresen lezajlott, de utána máris kellett a segítségem, ugyanis pl. a Wsus upgrade-je sikertelen lett. Maga a hibaüzenet nem ismeretlen az IT-sok világa előtt, hiszen láttunk már ilyent:

Fatal Error: The schema version of the database is from a newer version of WSUS than currently installed. You must either patch your WSUS server to at least that version or drop the database.

Előbb természetesen megnéztem az adatbázis-verziót meg a post-Wsus konfigban szereplő verziót – egyezett (ellenkező esetben az alábbi parancsot érdemes lefuttatni):

C:\Program Files\Update Services\Database\UpdateSchemaVersion.sql

Mivel nem akartak sokat foglalkozni ezzel az adott cégnél, kérték, hogy akkor nulláról indítsuk. Így előbb megpróbáltam simán adatbázis törléssel (SQL Management Studio-ból) és ismételt létrehozással (anno máshol nem WID volt, így a jegyzeteimben ott volt még a szögletes zárójelbeli kiegészítés):

wsusutil.exe postinstall [SQL_INSTANCE_NAME=server\SQLEXPRESS]

Majd, amikor (látszólag) ez sem vezetett eredményre, letöröltük a WID instance-t és a WSUS szerepkört, majd újraindítás után újratelepítettük. Itt már biztossá vált, hogy nem ezzel volt baj, hiszen a WSUS konzol félig-betöltése továbbra is megmaradt.

A rend azután állt helyre, miután a 4GB memória növelésre került. Az eredeti elképzelés szerinti feladatokra lehet, hogy elég volt anno ez a mennyiség, de megnézve az aktuális terheltséget, szükség volt a +1GB-ra, főleg a kezdeti szinkronizációhoz (elég szűkös erőforrásokkal rendelkeznek…).

*VLSC: Ott is nagy változások történnek, hiszen az MS igyekszik kivezetni a “sima” fiókok használatát s “céges” fiókok irányába terelni. Ez részben jogos, hiszen általában a licenszek adott céghez/cégekhez kötődnek, így abban a cégben létre lehet hozni egy új felhasználót – még ha nem is kap licenszt igénylő postafiókot; ugyanakkor véleményem szerint ennek a műveletnek a szükségessége kaphatott volna nagyobb visszhangot.

CA tanúsítvány igénylése – parancssor

Rengeteg parancssori eszköz létezik, most a Windowsos beépített eszközök használatáról ejtek pár szót (pontosabban már létező .req file CA-nak való átadása a cikk témája). Már az elején tisztáznám, hogy Enterprise környezetben, tehát sablonokkal fogunk dolgozni, ezért tegyük tisztába a sablon “valódi” és megjelenített nevét (spoiler: ezt a tudást egy következő cikkben is fogjuk használni).

Természetesen grafikus felületen is a sablon-kezelő konzolon meg tudjuk nézni a sablonok nevét (“Template name”) (s itt nem a megjelenített névre (“Template display name”) gondolok!), de erre van lehetőségünk parancssorból is:

certutil -config “server.domain.local\CA-Name” -CATemplates

Ez azért fontos, mert amikor a certreq parancsot használjuk, akkor a sablonnak NE a megjelenített nevét használjuk, hanem a “valós”, valószínűleg a megjelenített név szóközök nélküli változatát.

certreq -submit -attrib “CertificateTemplate:Webserver” RequestFile.req

(Súgó: amennyiben a megjelenített nevet használjuk, akkor sajnos a CA nem pontos hibaüzenettel örvendeztet meg bennünket:

Certificate not issued (Denied) Denied by Policy Module 0x80094800, The request was for a certificate template that is not supported by the Active Directory Certificate Services policy: Web server.

The requested certificate template is not supported by this CA. 0x80094800 (-2146875392 CERTSRV_E_UNSUPPORTED_CERT_TYPE)

Hibakeresésnél természetesen ellenőrizzük, hogy létezik a sablon és jó jogokkal, de utána azt is nézzük meg, hogy milyen névvel hivatkoztunk rá 🙂 )

CA tanúsítvány igénylése – webes felület

Adott helyen bevezetésre került egy CA-infrastruktúra, létrehoztuk a sablonokat, majd felmerült, hogy miként lehet tanúsítványokat kérni egy adott sablon alapján, ha annak verziója >=3. Ez a kitétel azért fontos, mert felkerült a webes komponens is, így első körben böngészőből szerették volna kezelni.

Mivel ez a téma eddig csak érintve volt (a PKI-sorozatban: Public Key Infrastructure (PKI) 2. rész), megpróbálok pár gondolatot összeírni.

Egyik kolléga régebbi kérdésére szeretném tisztázni, hogy már az alap CA-szolgáltatás telepítésekor létrejön a CertEnroll mappa. Ha telepítjük a webes komponenst, akkor az IIS-ben a Default Web Site alatt is megjelenik, de a nevével ellentétben nem az igénylés célját szolgálja, abba a mappába (ami ráadásul fizikailag alapértelmezetten a CertSrv alatt van) általában a CA tanúsítványa, az alap CRL és a Delta-CRL (ahol a < DeltaCRLAllowed> engedélyezett volta esetén egy “+” jel látszik), illetve egy nsrev_CANév.asp állomány található (ami a Netscape (iPlanet) alkalmazás tanúsítvány-visszavonásához köthető).

Tehát akkor maradjunk a https://szervernév/CertSrv oldalon (alapból nincs 443 porton publikálva!), a “Request a certificate” link után kétféle felület fogadhat bennünket, kezdem az alapesettel:

,

majd az ACR-re történő kattintás után jön elő az alábbi:

vagy egyből az ACR-ben találjuk magunkat.

Ez utóbbi akkor történik, ha az adott felhasználónak nincs (vagy tiltva van) az “Enroll” jogosultság a “User” sablonhoz (akár közvetlenül, akár csoporton keresztül).

Technikailag, a weboldal kódja úgy van felépítve, hogy a “User” sablon elérhetőségétől függően a certrqad.asp vagy certrqus.asp (esetleg certrqxt.asp) oldal töltődjön be (=> URL-szerkesztéssel is be lehet hozni a kért oldalt 🙂 ):

If “Enterprise”=sServerType Then

    If IsUserTemplateAvailable()=False Then

    fShowRQAD = True %>

    <TD><LocID ID=locLblRequestCert><A Href=”certrqad.asp“><Font Face=”Arial”>Request a certificate</Font></A></LocID></TD>

<%    End If

End If

If fShowRQAD=False Then %>

    <TD><LocID ID=locLblRequestCert><A <%If “Text”=sBrowser Then%> Href=”certrqxt.asp” <%Else%> Href=”certrqus.asp” <%End If%>><Font Face=”Arial”>Request a certificate</Font></A><LocID></TD>

<%End If%>

Nézzük akkor tételesen az ACR oldalon található két linket.

A Submit oldalon egyértelmű a történet, egy már meglévő tanúsítvány-igényt tudunk beadni:

De adott helyen az első opció (Create and submit) volt fontos, ahol “lokálisan” tudjuk elkészíteni az igényt (tehát nem már létező req-et nyújtunk be):

Itt szerettek volna tanúsítványt igényelni – ehhez viszont szükséges, hogy megjelenjen a sablon. Ugyanis a bevezetőben említett sablon-verziók a webes részen nem jelennek meg.

Kerülő-megoldásként egyrészt megpróbálhatjuk a rendszert “átverni” – természetesen, mint ahogy a cikk is említi, fokozott figyelemmel és csomó teszteléssel, másrészt más (nem böngésző-alapú) módszert használunk tanúsítvány-igénylésre. Jelen cikk az előbbit járja körül: az “átverésnek” több módja is van, a végeredmény ugyanaz:

• létrehozunk egy v1 vagy v2 sablont, majd utólag módosítjuk “nagyobbra”
  
• egy már létrehozott sablon verzió-értékét írjuk át az AD-ban (mint a cikk teszi)
  

Nem lehet elégszer hangsúlyozni, hogy ezt tesztelni kell! Sőt, a weboldal bizonyos esetekben nem is töltődik be jól minden böngészőben, néha érdemes IE-t használni (nos igen, itt is látszik, hogy MS kicsit hanyagolja). Ráadásként IE-ben is lehetnek gondok, pl. ez.

Személy szerint van ennél jobban kedvelt igénylési módszerem (a grafikus mmc-konzol használata szinte gyerekjáték, ha tudjuk, hogy milyen tanúsítványt akarunk 🙂 ), de tervezem, hogy egy következő cikkben megnézzük az egyik leggyakrabban használt parancssoros opciót.

DNS zónák

Egy “nagytakarítás” során adott helyen felmerült, hogy az ADUC-ban miért látszanak egyes DNS-zónák, mások meg miért nem? Egyáltalán miért vannak ott?

Nos, kezdjük azzal, hogy AD-integrált zónák lévén mindenképp az AD-ban kell tárolódjanak, tehát bizonyos AD-kezelő eszközökkel látnunk kell őket. S bár abban “igazuk” volt, hogy a képen látható (és néhány, nem látható) zónák AD-integráltak, de nem mindegy, hogy kinek is replikálunk zónán belül.

Amennyiben Windows 2000-kompatibilis integráció lesz a kiválasztott, akkor megjelenik az ADUC-ban is (a szokásos DNS-kezelőn kívül), ellenkező esetben (szintén DNS-kezelőn kívül) csak ADSIEdit segítségével látjuk, csatlakozva a DC=DomainDNSZones,DC=tartomany,DC=hu partícióra (vagy, ha a legfelső opció, akkor értelemszerűen a DC=ForestDNSZones,DC=tartomany,DC=hu partícióra).

Mivel adott cégnél már nem volt szükség Windows-2000 kompatibilitásra, így át tudtuk állítani, s már nem zavarta őket, “eltűnt” (hétköznapi ember többet használ ADUC-ot, mint ADSIEdit-et 🙂 )