Hasain Alshakarti

Internet Explorer 7 and later. In order to confirm the identity of organizations that host secure webpages, certifying authorities issue security certificates. These certificates are validated when you request a secure webpage.

By default, Internet Explorer performs a number of steps in order to validate the security certificate for a secure website. If a certificate is invalid, is out-of-date, or improperly identifies the website in question, Internet Explorer displays a notification to the user.

As an additional verification step, many certifying authorities also provide a service that identifies certificates that have been recently revoked. Earlier versions of Internet Explorer displayed notifications when this service could not be reached.

Because the inability to reach these services does not necessarily indicate that a certificate has been revoked, many users complained that such notifications were “false positives.” After considerable negative feedback, these notifications were disabled by default in Internet Explorer 7 and later.

When enabled, the FEATURE_WARN_ON_SEC_CERT_REV_FAILED feature displays notifications when Internet Explorer cannot reach the certificate revocation service published by a certifying authority. By default, this feature is disabled for Internet Explorer. This feature is not supported for applications hosting the WebBrowser Control.

To enable this feature using the registry, add the name of the Internet Explorer executable file to the following setting.

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_WARN_ON_SEC_CERT_REV_FAILED]
“iexplore.exe”=dword:00000001

The feature is enabled when the value is set to (DWORD) 00000001 and disabled when the value is (DWORD) 00000000.

It is pretty straight forward to configure SSL Client Certificate Authentication in UAG, just follow the steps in the online guide at http://technet.microsoft.com/en-us/library/ee861163.aspx and you should be able to run in almost no time except for an issue that occurs whenever your logon name and  common name does not match!

An authentication error will occur with the error message in UAG telling that the user account does not have the expected cn, upn or email value that has been extracted from the users SSL authentication certificate at the time of logon. Looking at the certificate all values of cn, upn and email shows a 100% match of the same values on the user account!

Looking at the cert auth scripts in UAG we can see that UAG is using the value of the common name of the certificate subject as the user_name. The user_name is then used to obtain information from Active Directory regarding that user account. And this is where the error occurs, the matching for the username is simply wrong.

To correct this you can obtain the UPN value from the client certificate in the certificate validation script and use that value to obtain the user logon name by simply splitting at the @ sign.

Download the UAG customupdate-cert scripts and make sure to change the authserver01 key word to the name of your authentication repository.

/Hasain

Just follow the steps below:

1. IE setting for CRL checking of the server certificate is enabled

2. Set the hostnames of servers hosting the CRL and /or OCSP to 127.0.0.1 in your hosts file

3. Execute [certutil.exe -urlcache * delete] to remove all cached CRLs

4. Start your browser and tell it to HTTPS:// to the site

5. It will take some time trying to check the CRL/OCSP from the non-existing server

6. After that you are on the site without any warnings! Not really what I expected?!

Firefox gives the same results and only Google Chrome gives us a warning…

What if the same happens with Code Signing? Interesting case we have!

/Hasain

Yet another day of troubleshooting DirectAccess, this time it was about a broken IPHTTPS tunnel. During the troubleshooting we recognized that the client is not able to establish a connection the the IPHTTPS url https://da.domain.com/IPHTTPS, using a network sniffer we could very clear see the server sending a reset packet after the Client Hello message. This indicates that the SSL server is not able to continue communicating using SSL. Knowing that there was a certificate change just a few days before this error occurred we found that the old certificate was still used for the SSL binding at the DA server even though the configuration was reapplied using the DA management console after the certificate change.

When changing the certificate used for the IPHTTPS tunnel it is very important to clear the old SSL certificate binding before adding the new one.

If you configured your DirectAccess using the DA management console follow the steps below to change the IPHTTPS certificate:

·         Run the command: netsh http show sslcert
This will show the current sslcert binding with details about ip, port and the certificate

·         Delete the old bindning using the command: netsh http del sslcert

·         Using the DA management console, select the new IPHTTPS certificate, save an apply the new configuration

If you configured your DirectAccess using scripts or netsh commands to define all setting follow the steps below to change the IPHTTPS certificate:

·         Run the command: netsh http show sslcert
This will show the current sslcert binding with details about ip, port and the certificate

·         Delete the old bindning using the command: netsh http del sslcert

·         Add the new sslcert binding using the command: netsh http add sslcert

/Hasain

Kunde inte låta bli att notera texten nedan på ett informationsblad som beskriver hur man gjorde för att ansluta till ett trådlöst WIFI nät. Det som drog min blick extra mycket var notisen på bladet som syns på bilden nedan.

Jag blir riktigt fundersam när jag ser sådana beskrivningar där vi lär våra användare ett felaktigt beteende. Vad tror vi kommer att hända om samma användare får ett liknande fel när han eller hon surfar till sin internetbank eller företagets webbmail mm.

/Hasain

PKI finns idag i de flesta tillämpningar som körs under Linux, om stödet inte finns med från början så går det i de flesta gångerna att lägga till det i efter hand och är man lite händig själv så kan man fixa till PKI i det mesta men då får man vara beredd att sätta sig vid tangentbordet själv 🙂

Efter att ha konstaterat att PKI är ganska supporterad i Ubuntu/Linux, så kom turen till att testa med smartkort. För att smartkort ska funka så behövs en drivrutin till läsaren och CSP programvara som mappar mellan rådande standard och smartkortet. De standard som används i Linux när det gäller smartkort är PKCS11 och korten är antigen PKCS15 eller så emuleras PKCS15 av CSP.

Det finns två projekt som kommit längst i Linux när det gäller smartkort, OpenSC som kan hantera många kort med filsystem och RSA modul är den ena och Musclecard so kan hantera många java-baserade kort är den andra. Jag började med att testa OpenSC och har mer eller mindre fastnat för den 😉

OpenSC klarar av att prata med smartkort och läsare baserade på CT-API, PC/SC och OpenCT. läsaren som jag använder är Gemplus GemPC Twin som är ett USB CCID och kommunicerar med PC/SC. det som behövdes för att få fat på läsaren är libccid(driver för CCID USB Readers), Pcscd(PC/SC Middleware) och OpenSC(PKCS11/15 tools and API) med tillhörande plugins för exempelvis Mozilla.

Om man ska jämföra lite så måste jag säga att jag saknar den kompletta CSP implementationen som ju finns i Windows! I Linux så stödjer alla ett gränssnitt mot PKCS11 men den finns inte i själva OS:et eller på ett automatiserat sätt utan måste pluggas in i varje applikation eller de lav systemet på ett mer eller mindre mauellt sätt. Den manuella aktiviteten är nödvändig i början och allt brukar funka om man byter kort eller läsare givet att det nya kortet och den nya läsaren är kompatibla med systemet.

Jag har testat och kört Smartkort i Firefox samt lokal smartkortlogon i Ubuntu. För Firefox så behöver man manuellt lägga till en modul för att kunna använda smartkortet via OpenSC, efter det så finns kortet och de cert och nycklar för HTTPS/SSL inloggning. Lokalinloggnig med smartkort i Ubuntu var lite mer av ett äventyr, det fanns färdiga PAM moduler men ingen av de funkade, man fick bara ett fel meddelande om att signeringen inte kunnde genomföras, efter lite tester så visade det sig att det meddelande som skickades till kortet för signering var för långt, det är troligtvis en miss i testprocessen där man inte räknat med begränsningar som beror på korten eller mjukvaran runt dessa. Efter en justering och en ny kompilerad pam-modul så funkade det utmärkt 🙂

Det finns två varianter av smartcardlogon som pam-modul, en som inte genomför någon kontroll av certkedjan och CRL:en och en som följer konstens alla regler och kan automatiskt mappa användare i systemet beroende på egenskaper i det cert som finns på kortet. Den första av dessa funkar fint med selfsigned certfikat och är ganska enkel att sätta upp då man lägger certfikatet i en fil i användarens hemmamapp, vid inloggning kommer pam-modulen att försöka hitta lämpliga nycklar på det kort som sitter i läsaren som matchar certet, den kommer sedan att be kortet signera lite slumpdata för att sedan verifiera signaturen mot det certo och nyckel som finns i användarens hemmamapp.

Smartkortlogon via SSH ska enligt uppgift från Johannes G. funkar bra, har själv inte hunnit testa dett men hoppas kunna återkomma om det.

/Hasain