Dela via

  • Artikel

Certifikatfel

 

Utgivet: mars 2016

Gäller för: System Center 2012 R2 Operations Manager, System Center 2012 - Operations Manager, System Center 2012 SP1 - Operations Manager

I det här avsnittet beskrivs lösningar på certifikatproblem vid övervakning av UNIX- eller Linux-datorer.

Felmeddelande vid certifikatsignering

Under installationen av UNIX-/Linux-agenter kan följande felmeddelande visas.

Event Type:        Error
Event Source:    Cross Platform Modules
Event Category:                None
Event ID:              256
Date:                     4/1/2009
Time:                     4:02:27 PM
User:                     N/A
Computer:          COMPUTER1
Description:
Unexpected ScxCertLibException: Can't decode from base64
; input data is:

Felet inträffar när certifikatsigneringsmodulen anropas men själva certifikatet är tomt. Felet kan orsakas av ett fel på SSH-anslutningen till fjärrsystemet.

Om du ser felmeddelandet gör du följande:

  1. Kontrollera att SSH-daemon i fjärrvärden körs.

  2. Kontrollera att du kan öppna en SSH-session med fjärrvärden med autentiseringsuppgifterna som anges i identifieringsguiden.

  3. Kontrollera att autentiseringsuppgifterna i identifieringsguiden har den behörighet som krävs för identifiering. Mer information finns i Funktioner som krävs för UNIX- och Linux-konton.

Certifikat- och värdnamnet matchar inte

Nätverksnamnet som används i certifikatet måste matcha det fullständiga domännamnet som matchas av Operations Manager. Om nätverksnamnet inte matchar visas följande felmeddelande när du kör identifieringsguiden:

The SSL certificate contains a common name (CN) that does not match the hostname

Du kan visa certifikatets grundläggande information på en UNIX- eller Linux-dator genom att ange följande kommando:

openssl x509 -noout -in /etc/opt/microsoft/scx/ssl/scx.pem -subject -issuer -dates

När du gör det visas utdata som liknar följande:

subject= /DC=name/DC=newdomain/CN=newhostname/CN=newhostname.newdomain.name
issuer= /DC=name/DC=newdomain/CN=newhostname/CN=newhostname.newdomain.name
notBefore=Mar 25 05:21:18 2008 GMT
notAfter=Mar 20 05:21:18 2029 GMT

Validera värdnamnen och datumen och se till att de matchar namnet som matchas av Operations Manager-hanteringsservern.

Om värdnamnen inte matchar använder du någon av följande åtgärder för att lösa problemet:

  • Om UNIX- eller Linux-värdnamnet är rätt men Operations Manager-hanteringsservern matchar det felaktigt ändrar du DNS-posten så att den matchar rätt fullständigt domännamn eller lägger till en post i värdfilen på Operations Manager-servern.

  • Om UNIX- eller Linux-värdnamnet är fel gör du något av följande:

    • Ändra värdnamnet på UNIX- eller Linux-värden till det rätta och skapa ett nytt certifikat.

    • Skapa ett nytt certifikat med det önskade värdnamnet.

Ändra namn i certifikatet:

Om certifikatet har skapats med ett felaktigt namn kan du ändra värdnamnet och skapa certifikatet och den privata nyckeln på nytt. Det kan du göra genom att köra följande kommando i UNIX- eller Linux-datorn:

/opt/microsoft/scx/bin/tools/scxsslconfig -f -v

Alternativet –f tvingar filerna i /etc/opt/microsoft/scx/ssl att skrivas över.

Du kan även ändra värd- och domännamnet i certifikatet med växlarna –h och –d, som i följande exempel:

/opt/microsoft/scx/bin/tools/scxsslconfig -f -h <hostname> -d <domain.name>

Starta om agenten genom att köra följande kommando:

/opt/microsoft/scx/bin/tools/scxadmin -restart

Lägga till en post i värdfilen:

Om det fullständiga domännamnet inte är i omvänd DNS kan du lägga till en post i värdfilen som finns på hanteringsservern för att ange namnmatchning. Värdfilen finns i mappen \Windows\System32\Drivers\etc. En post i värdfilen är en kombination av IP-adressen och det fullständiga domännamnet.

Om du exempelvis vill lägga till en post för värden som har namnet ”nyttvärdnamn.nyttdomännamn.namn” med IP-adressen 192.168.1.1 lägger du till följande i slutet av värdfilen:

192.168.1.1     newhostname.newdomain.name