CUCM Security By Default en ITL Operation and Troubleshooting begrijpen

Inleiding

In dit document wordt de functie Security By Default (SBD) van Cisco Unified Communications Manager (CUCM) Versies 8.0 en hoger beschreven.

Achtergrondinformatie

CUCM versie 8.0 en hoger introduceert de SBD-functie, die bestaat uit ITL-bestanden (Identity Trust List) en de Trust Verification Service (TVS).

Elk CUCM-cluster maakt nu automatisch gebruik van beveiliging op basis van ITL. Er is een afweging tussen beveiliging en gebruiksgemak / gemak van beheer waarvan beheerders op de hoogte moeten zijn voordat ze bepaalde wijzigingen aanbrengen in een versie 8.0 CUCM-cluster.

Dit document is een aanvulling op de officiële Security By Default-documenten en bevat operationele informatie en tips voor probleemoplossing om beheerders te helpen en het probleemoplossingsproces te vereenvoudigen.

Het is een goed idee om vertrouwd te raken met deze kernconcepten van SBD: Asymmetric Key Cryptography Wikipedia-artikel en artikel over Public Key Infrastructure Wikipedia.

Overzicht SBD

Dit gedeelte geeft een snel overzicht van wat SBD precies biedt. Zie de sectie met informatie over SBD-details en probleemoplossing voor de volledige technische details van elke functie.

SBD biedt deze drie functies voor ondersteunde IP-telefoons:

• Standaard verificatie van gedownloade TFTP-bestanden (configuratie, locale, ringlist) die een ondertekeningssleutel gebruiken
• Optionele codering van TFTP-configuratiebestanden die gebruikmaken van een ondertekeningssleutel
• Certificaatverificatie voor telefonisch geïnitieerde HTTPS-verbindingen die gebruikmaken van een extern certificaatarchief op CUCM (TVS)

Dit document geeft een overzicht van elk van deze functies.

TFTP-downloadverificatie

Wanneer een Certificate Trust List (CTL) of ITL-bestand aanwezig is, vraagt de IP-telefoon een ondertekend TFTP-configuratiebestand aan bij de CUCM TFTP-server.

Met dit bestand kan de telefoon controleren of het configuratiebestand afkomstig is van een vertrouwde bron. Met CTL / ITL-bestanden aanwezig op telefoons, moeten configuratiebestanden worden ondertekend door een vertrouwde TFTP-server.

Het bestand is platte tekst op het netwerk terwijl het wordt verzonden, maar wordt geleverd met een speciale verificatiehandtekening.

De telefoon vraagt SEP<MAC Address>.cnf.xml.sgn om het configuratiebestand met de speciale handtekening te ontvangen.

Dit configuratiebestand is ondertekend met de TFTP-privésleutel die overeenkomt met CallManager.pem op de pagina Beheer van het besturingssysteem (OS) Certificate Management.

Het ondertekende bestand heeft een handtekening bovenaan om het bestand te verifiëren, maar is anders in platte tekst XML.

De onderstaande afbeelding laat zien dat de ondertekenaar van het configuratiebestand CN=CUCM8-Publisher.bbbburns.lab is, dat op zijn beurt wordt ondertekend door CN=JASBURNS-AD.

Dit betekent dat de telefoon de handtekening van CUCM8-Publisher.bbbburns.lab moet verifiëren tegen het ITL-bestand voordat dit configuratiebestand wordt geaccepteerd.

Hier is een diagram dat laat zien hoe de privésleutel wordt gebruikt samen met een Message Digest Algorithm (MD)5 of Secure Hash Algorithm (SHA)1-hashfunctie om het ondertekende bestand te maken.

Handtekeningverificatie keert dit proces om door het gebruik van de openbare sleutel die overeenkomt om de hash te decoderen. Als de hashes overeenkomen, wordt het volgende weergegeven:

• Dit bestand is tijdens het transport niet gewijzigd.
• Dit bestand is afkomstig van de partij die in de handtekening wordt vermeld, omdat alles dat met de openbare sleutel is gedecodeerd, moet zijn gecodeerd met de privésleutel.

TFTP-configuratiebestandscodering

Als de optionele TFTP-configuratieversleuteling is ingeschakeld in het bijbehorende beveiligingsprofiel van de telefoon, vraagt de telefoon een gecodeerd configuratiebestand aan.

Dit bestand is ondertekend met de TFTP-privésleutel en gecodeerd met een symmetrische sleutel die wordt uitgewisseld tussen de telefoon en de CUCM (raadpleeg de Cisco Unified Communications Manager Security Guide, release 8.5(1) voor volledige details).

De inhoud ervan kan niet worden gelezen met een netwerksnuffelaar, tenzij de waarnemer over de nodige sleutels beschikt.

De telefoon vraagt SEP<MAC Address>.cnf.xml.enc.sgn aan om het gecodeerde bestand te krijgen.

Het gecodeerde configuratiebestand heeft ook de handtekening in het begin, maar er is geen platte tekstgegevens na, alleen gecodeerde gegevens (vervormde binaire tekens in deze teksteditor).

De afbeelding laat zien dat de ondertekenaar hetzelfde is als in het vorige voorbeeld, dus deze ondertekenaar moet aanwezig zijn in het ITL-bestand voordat de telefoon het bestand accepteert.

Verder moeten de decoderingssleutels correct zijn voordat de telefoon de inhoud van het bestand kan lezen.

Vertrouwensverificatieservice (verificatie van certificaten en handtekeningen op afstand)

IP-telefoons bevatten een beperkte hoeveelheid geheugen en er kan ook een groot aantal telefoons zijn om in een netwerk te beheren.

CUCM fungeert als een externe vertrouwensopslag via de TVS, zodat er geen volledige certificaatvertrouwensopslag op elke IP-telefoon hoeft te worden geplaatst.

Telkens wanneer de telefoon een handtekening of certificaat niet kan verifiëren via de CTL- of ITL-bestanden, wordt de TVS-server om verificatie gevraagd.

Deze centrale vertrouwenswinkel is gemakkelijker te beheren dan wanneer de vertrouwenswinkel aanwezig was op alle IP-telefoons.

Gegevens over SBD en probleemoplossing

In dit gedeelte wordt het SBD-proces beschreven.

ITL-bestanden en certificaten aanwezig op CUCM

Ten eerste zijn er een aantal bestanden die op de CUCM-server zelf aanwezig moeten zijn. Het belangrijkste onderdeel is het TFTP-certificaat en de TFTP-privésleutel.

Het TFTP-certificaat bevindt zich onder Beheer besturingssysteem > Beveiliging > Certificaatbeheer > CallManager.pem.

De CUCM-server gebruikt het CallManager.pem-certificaat private en public keys voor de TFTP-service (evenals voor de Cisco Call Manager (CCM) -service).

De afbeelding laat zien dat het CallManager.pem certificaat is uitgegeven aan CUCM8-publisher.bbbburns.lab en ondertekend door JASBURNS-AD. Alle TFTP-configuratiebestanden worden ondertekend met de onderstaande privésleutel.

Alle telefoons kunnen de openbare TFTP-sleutel in het CallManager.pem-certificaat gebruiken om elk bestand te decoderen dat is gecodeerd met de TFTP-privésleutel en om elk bestand te verifiëren dat is ondertekend met de TFTP-privésleutel.

Naast de CallManager.pem certificaat private key, slaat de CUCM server ook een ITL bestand op dat wordt gepresenteerd aan telefoons.

De opdracht show itl toont de volledige inhoud van dit ITL-bestand via Secure Shell (SSH)-toegang tot de CLI van het besturingssysteem van de CUCM-server.

Deze sectie breekt het ITL-bestand stuk voor stuk af, omdat het een aantal belangrijke componenten heeft die de telefoon gebruikt.

Het eerste deel is de handtekeninginformatie. Zelfs het ITL-bestand is een ondertekend bestand. Deze uitvoer laat zien dat deze is ondertekend door de TFTP-privésleutel die is gekoppeld aan het vorige CallManager.pem-certificaat.

admin:show itl
Length of ITL file: 5438
The ITL File was last modified on Wed Jul 27 10:16:24 EDT 2011

        Parse ITL File
        ----------------

Version:        1.2
HeaderLength:   296 (BYTES)

BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
3       SIGNERID        2       110
4       SIGNERNAME      76      CN=CUCM8-Publisher.bbbburns.lab;
                                OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
5       SERIALNUMBER    10      21:00:2D:17:00:00:00:00:00:05
6       CANAME          15      CN=JASBURNS-AD
*Signature omitted for brevity*

De volgende secties bevatten elk hun doel binnen een speciale functie parameter. De eerste functie is de System Administrator Security Token. Dit is de handtekening van de publieke TFTP-sleutel.

        ITL Record #:1
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       1972
2       DNSNAME         2
3       SUBJECTNAME     76      CN=CUCM8-Publisher.bbbburns.lab;
                                OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4       FUNCTION        2       System Administrator Security Token
5       ISSUERNAME      15      CN=JASBURNS-AD
6       SERIALNUMBER    10      21:00:2D:17:00:00:00:00:00:05
7       PUBLICKEY       140
8       SIGNATURE       256
9       CERTIFICATE     1442    0E 1E 28 0E 5B 5D CC 7A 20 29 61 F5 
                                8A DE 30 40 51 5B C4 89 (SHA1 Hash HEX)
This etoken was used to sign the ITL file.

De volgende functie is CCM+TFTP. Dit is opnieuw de openbare TFTP-sleutel die dient om gedownloade TFTP-configuratiebestanden te verifiëren en te decoderen.

        ITL Record #:2
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       1972
2       DNSNAME         2
3       SUBJECTNAME     76      CN=CUCM8-Publisher.bbbburns.lab;
                                OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4       FUNCTION        2       CCM+TFTP
5       ISSUERNAME      15      CN=JASBURNS-AD
6       SERIALNUMBER    10      21:00:2D:17:00:00:00:00:00:05
7       PUBLICKEY       140
8       SIGNATURE       256
9       CERTIFICATE     1442    0E 1E 28 0E 5B 5D CC 7A 20 29 61 F5 
                                8A DE 30 40 51 5B C4 89 (SHA1 Hash HEX)

De volgende functie is TVS. Er is een vermelding voor de openbare sleutel van elke TVS-server waarmee de telefoon verbinding maakt.

Hierdoor kan de telefoon een SSL-sessie (Secure Sockets Layer) instellen op de TVS-server.

        ITL Record #:3
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       743
2       DNSNAME         2
3       SUBJECTNAME     76      CN=CUCM8-Publisher.bbbburns.lab;
                                OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4       FUNCTION        2       TVS
5       ISSUERNAME      76      CN=CUCM8-Publisher.bbbburns.lab;
                                OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
6       SERIALNUMBER    8       2E:3E:1A:7B:DA:A6:4D:84
7       PUBLICKEY       270
8       SIGNATURE       256
11      CERTHASH        20      C7 E1 D9 7A CC B0 2B C2 A8 B2 90 FB 
                                AA FE 66 5B EC 41 42 5D
12      HASH ALGORITHM  1       SHA-1

De laatste functie in het ITL-bestand is de Certificate Authority Proxy Function (CAPF).

Met dit certificaat kunnen de telefoons een beveiligde verbinding tot stand brengen met de CAPF-service op de CUCM-server, zodat de telefoon een lokaal significant certificaat (LSC) kan installeren of bijwerken.

        ITL Record #:4
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       455
2       DNSNAME         2
3       SUBJECTNAME     61      CN=CAPF-9c4cba7d;
                                OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4       FUNCTION        2       CAPF
5       ISSUERNAME      61      CN=CAPF-9c4cba7d;
                                OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
6       SERIALNUMBER    8       0A:DC:6E:77:42:91:4A:53
7       PUBLICKEY       140
8       SIGNATURE       128
11      CERTHASH        20      C7 3D EA 77 94 5E 06 14 D2 90 B1 
                                A1 43 7B 69 84 1D 2D 85 2E
12      HASH ALGORITHM  1       SHA-1

The ITL file was verified successfully.

Het volgende gedeelte behandelt precies wat er gebeurt wanneer een telefoon wordt opgestart.

Telefoon downloadt ITL en configuratiebestand

Nadat de telefoon is opgestart en een IP-adres en het adres van een TFTP-server heeft verkregen, vraagt deze eerst naar de CTL- en ITL-bestanden.

Deze pakketopname toont een telefoonverzoek voor het ITL-bestand. Als je op tftp.opcode == 1 filtert, zie je elk TFTP-leesverzoek van de telefoon:

Aangezien de telefoon CTL- en ITL-bestanden van TFTP met succes heeft ontvangen, vraagt de telefoon om een ondertekend configuratiebestand.

De logboeken van de telefoonconsole die dit gedrag weergeven, zijn beschikbaar via de webinterface van de telefoon:

Eerst vraagt de telefoon een CTL-bestand aan, dat slaagt:

837: NOT 09:13:17.561856 SECD: tlRequestFile: Request CTLSEP0011215A1AE3.tlv
846: NOT 09:13:17.670439 TFTP: [27]:Requesting CTLSEP0011215A1AE3.tlv from 
14 . 48 . 44 . 80
847: NOT 09:13:17.685264 TFTP: [27]:Finished --> rcvd 4762 bytes

Vervolgens vraagt de telefoon ook een ITL-bestand aan:

868: NOT 09:13:17.860613 TFTP: [28]:Requesting ITLSEP0011215A1AE3.tlv from 
14 . 48 . 44 . 80
869: NOT 09:13:17.875059 TFTP: [28]:Finished --> rcvd 5438 bytes 

Telefoon verifieert ITL en configuratiebestand

Nadat het ITL-bestand is gedownload, moet het worden geverifieerd. Er zijn een aantal staten waar een telefoon op dit moment kan worden gebruikt, dus dit document behandelt ze allemaal.

• De telefoon heeft geen CTL- of ITL-bestand aanwezig of ITL is leeg vanwege de parameter Prepare Cluster for Rollback to Pre 8.0. In deze staat vertrouwt de telefoon blindelings het volgende CTL- of ITL-bestand dat is gedownload en gebruikt deze handtekening voortaan.
• De telefoon heeft al een CTL maar geen ITL. In deze toestand vertrouwt de telefoon alleen een ITL als deze kan worden geverifieerd door de CCM + TFTP-functie in het CTL-bestand.
• De telefoon heeft al een CTL- en een ITL-bestand. In deze status controleert de telefoon of de onlangs gedownloade bestanden overeenkomen met de handtekening op de CTL-, ITL- of TVS-server.

Hier is een stroomschema dat beschrijft hoe de telefoon ondertekende bestanden en HTTPS-certificaten verifieert:

In dit geval kan de telefoon de handtekening in de ITL- en CTL-bestanden verifiëren. De telefoon heeft al zowel een CTL als ITL, dus het heeft gewoon tegen hen gecontroleerd en de juiste handtekening gevonden.

877: NOT 09:13:17.925249 SECD: validate_file_envelope: 
File sign verify SUCCESS; header length <296>

Aangezien de telefoon de CTL- en ITL-bestanden heeft gedownload, vraagt deze vanaf dit punt ALLEEN ondertekende configuratiebestanden aan.

Dit illustreert dat de telefoonlogica is om te bepalen dat de TFTP-server veilig is, op basis van de aanwezigheid van CTL en ITL, en vervolgens om te vragen om een ondertekend bestand:

917: NOT 09:13:18.433411 tftpClient: tftp request rcv'd from /usr/tmp/tftp,
srcFile = SEP0011215A1AE3.cnf.xml, dstFile = /usr/ram/SEP0011215A1AE3.cnf.xml 
max size = 550001
918: NOT 09:13:18.457949 tftpClient: auth server - tftpList[0] = ::ffff:
14 . 48 . 44 . 80 
919: NOT 09:13:18.458937 tftpClient: look up server - 0
920: NOT 09:13:18.462479 SECD: lookupCTL: TFTP SRVR secure
921: NOT 09:13:18.466658 tftpClient: secVal = 0x9 922: NOT 09:13:18.467762 
tftpClient: ::ffff:14 . 48 . 44 . 80 is a secure server 
923: NOT 09:13:18.468614 tftpClient: retval = SRVR_SECURE
924: NOT 09:13:18.469485 tftpClient: Secure file requested
925: NOT 09:13:18.471217 tftpClient: authenticated file approved - add .sgn 
-- SEP0011215A1AE3.cnf.xml.sgn
926: NOT 09:13:18.540562 TFTP: [10]:Requesting SEP0011215A1AE3.cnf.xml.sgn 
from 14 . 48 . 44 . 80 with size limit of 550001
927: NOT 09:13:18.559326 TFTP: [10]:Finished --> rcvd 7652 bytes 

Zodra het ondertekende configuratiebestand is gedownload, moet de telefoon het verifiëren met de functie voor CCM + TFTP in de ITL:

937: NOT 09:13:18.656906 SECD: verifyFile: verify SUCCESS 
</usr/ram/SEP0011215A1AE3.cnf.xml>

Telefooncontacten TVS voor onbekend certificaat

Het ITL-bestand biedt een TVS-functie die het certificaat bevat van de TVS-service die wordt uitgevoerd op de TCP-poort 2445 van de CUCM-server.

TVS wordt uitgevoerd op alle servers waarop de CallManager-service is geactiveerd. De CUCM TFTP-service gebruikt de geconfigureerde CallManager-groep om een lijst met TVS-servers samen te stellen waarmee de telefoon contact moet opnemen in het telefoonconfiguratiebestand.

Sommige labs gebruiken slechts één CUCM-server. In een CUCM-cluster met meerdere knooppunten kunnen maximaal drie TVS-vermeldingen voor een telefoon zijn, één voor elke CUCM in de CUCM-groep van de telefoon.

Dit voorbeeld laat zien wat er gebeurt als de knop Directories op de IP-telefoon wordt ingedrukt. De directories-URL is geconfigureerd voor HTTPS, zodat de telefoon het Tomcat-webcertificaat van de directories-server krijgt.

Dit Tomcat-webcertificaat (tomcat.pem in OS-beheer) wordt niet geladen in de telefoon, dus de telefoon moet contact opnemen met TVS om het certificaat te verifiëren.

Raadpleeg het vorige TVS-overzichtsdiagram voor een beschrijving van de interactie. Hier is het logboekperspectief van de telefoonconsole:

Eerst vindt u de URL van de directory:

1184: NOT 15:20:55.219275 JVM: Startup Module Loader|cip.dir.TandunDirectories:
? - Directory url https://14 . 48 . 44 . 80:8443/ccmcip/xmldirectory.jsp

Dit is een SSL/Transport Layer Security (TLS) beveiligde HTTP-sessie waarvoor verificatie vereist is.

1205: NOT 15:20:59.404971 SECD: clpSetupSsl: Trying to connect to IPV4, IP: 
14 . 48 . 44 . 80, Port : 8443
1206: NOT 15:20:59.406896 SECD: clpSetupSsl: TCP connect() waiting,
<14 . 48 . 44 . 80> c:8 s:9 port: 8443
1207: NOT 15:20:59.408136 SECD: clpSetupSsl: TCP connected,
<14 . 48 . 44 . 80> c:8 s:9
1208: NOT 15:20:59.409393 SECD: clpSetupSsl: start SSL/TLS handshake, 
<14 . 48 . 44 . 80> c:8 s:9
1209: NOT 15:20:59.423386 SECD: srvr_cert_vfy: Server Certificate 
Validation needs to be done

De telefoon controleert eerst of het certificaat dat door de SSL/TLS-server wordt gepresenteerd, aanwezig is in de CTL. Vervolgens kijkt de telefoon naar de functies in het ITL-bestand om te zien of deze overeenkomen.

Deze foutmelding zegt "HTTPS cert not in CTL", wat betekent "dat certificering niet kan worden gevonden in de CTL of de ITL."

1213: NOT 15:20:59.429176 SECD: findByCertAndRoleInTL: Searching TL from CTL file
1214: NOT 15:20:59.430315 SECD: findByCertAndRoleInTL: Searching TL from ITL file
1215: ERR 15:20:59.431314 SECD: EROR:https_cert_vfy: HTTPS cert not in CTL,
<14 . 48 . 44 . 80>

Nadat de directe inhoud van het CTL- en ITL-bestand is gecontroleerd op het certificaat, is het volgende dat de telefoon controleert de TVS-cache.

Dit wordt gedaan om het netwerkverkeer te verminderen als de telefoon onlangs de TVS-server om hetzelfde certificaat heeft gevraagd.

Als het HTTPS-certificaat niet in de telefooncache is gevonden, kunt u een TCP-verbinding maken met de TVS-server zelf.

1220: NOT 15:20:59.444517 SECD: processTvsClntReq: TVS Certificate 
Authentication request
1221: NOT 15:20:59.445507 SECD: lookupAuthCertTvsCacheEntry: No matching 
entry found at cache
1222: NOT 15:20:59.446518 SECD: processTvsClntReq: No server sock exists, 
must be created
1223: NOT 15:20:59.451378 SECD: secReq_initClient: clnt sock fd 11 bound 
to </tmp/secClnt_secd>
1224: NOT 15:20:59.457643 SECD: getTvsServerInfo: Phone in IPv4 only mode
1225: NOT 15:20:59.458706 SECD: getTvsServerInfo: Retreiving IPv4 address
1230: NOT 15:20:59.472628 SECD: connectToTvsServer: Successfully started 
a TLS connection establishment to the TVS server: IP:14 . 48 . 44 . 80, port:2445
(default); Waiting for it to get connected.

Vergeet niet dat de verbinding met TVS zelf SSL / TLS (beveiligde HTTP of HTTPS) is, dus het is ook een certificaat dat moet worden geverifieerd tegen de CTL of ITL.

Als alles goed gaat, wordt het TVS-servercertificaat gevonden in de TVS-functie van het ITL-bestand. Zie ITL Record #3 in het vorige voorbeeld ITL-bestand.

1244: NOT 15:20:59.529938 SECD: srvr_cert_vfy: Server Certificate Validation 
needs to be done
1245: NOT 15:20:59.533412 SECD: findByIssuerAndSerialAndRoleInTL: 
Searching TL from CTL file 
1246: NOT 15:20:59.534936 SECD: findByIssuerAndSerialAndRoleInTL: 
Searching TL from ITL file
1247: NOT 15:20:59.537359 SECD: verifyCertWithHashFromTL: cert hash and 
hash in TL MATCH
1248: NOT 15:20:59.538726 SECD: tvs_cert_vfy: TVS cert verified with hash 
from TL, <14 . 48 . 44 . 80>

Succes! De telefoon heeft nu een beveiligde verbinding met de TVS-server. De volgende stap is om de TVS-server te vragen "Hallo, vertrouw ik dit directories-servercertificaat?"

Dit voorbeeld toont het antwoord op die vraag - een antwoord van 0 wat succes betekent (geen fout).

1264: NOT 15:20:59.789738 SECD: sendTvsClientReqToSrvr: Authenticate 
Certificate : request sent to TVS server - waiting for response
1273: NOT 15:20:59.825648 SECD: processTvsSrvrResponse: Authentication Response 
received, status : 0

Aangezien de reactie van TVS succesvol is, worden de resultaten voor dat certificaat opgeslagen in de cache.

Dit betekent dat, als u binnen de volgende 86.400 seconden opnieuw op de knop Directories drukt, u geen contact hoeft op te nemen met de TVS-server om het certificaat te verifiëren. U kunt eenvoudig toegang krijgen tot de lokale cache.

1279: NOT 15:20:59.837086 SECD: saveCertToTvsCache: Saving certificate 
in TVS cache with default time-to-live value: 86400 seconds
1287: ERR 15:20:59.859993 SECD: Authenticated the HTTPS conn via TVS

Ten slotte controleert u of uw verbinding met de directories-server is gelukt.

1302: ERR 15:21:01.959700 JVM: Startup Module Loader|cip.http.ae:? 
- listener.httpSucceed:  https://14 . 48 . 44 . 80:8443/ccmcip/
xmldirectoryinput.jsp?name=SEP0011215A1AE3

Hier is een voorbeeld van wat er gebeurt op de CUCM-server waar TVS wordt uitgevoerd. U kunt tv-logs verzamelen met de Cisco Unified Real-Time Monitoring Tool (RTMT).

De CUCM TVS-logs laten zien dat u SSL-handshake met de telefoon gebruikt, de telefoon vraagt TVS naar het Tomcat-certificaat en vervolgens reageert TVS om aan te geven dat het certificaat overeenkomt in het TVS-certificaatarchief.

15:21:01.954 |   debug 14 . 48 . 44 . 202: tvsSSLHandShake Session ciphers - AES256-SHA
15:21:01.954 |   debug TLS HS Done for ph_conn .
15:21:02.010 |   debug     MsgType               : TVS_MSG_CERT_VERIFICATION_REQ
15:21:02.011 |   debug tvsGetIssuerNameFromX509 - issuerName : CN=CUCM8-
Publisher.bbbburns.lab;OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US and Length: 75

15:21:02.011 |   debug CertificateDBCache::getCertificateInformation - 
Certificate compare return =0 
15:21:02.011 |   debug CertificateDBCache::getCertificateInformation -
Certificate found and equal
15:21:02.011 |   debug     MsgType               : TVS_MSG_CERT_VERIFICATION_RES

Het TVS-certificaatarchief is een lijst met alle certificaten op de webpagina Beheer besturingssysteem > Certificaatbeheer.

Handmatig controleren of ITL-code overeenkomt met CUCM ITL 

Een veel voorkomende misvatting bij het oplossen van problemen betreft de neiging om het ITL-bestand te verwijderen in de hoop dat het een probleem met bestandsverificatie oplost.

Soms is verwijdering van ITL-bestanden vereist, maar het ITL-bestand hoeft alleen te worden verwijderd als aan AL deze voorwaarden is voldaan.

• De handtekening van het ITL-bestand op de telefoon komt niet overeen met de handtekening van het ITL-bestand op de CM TFTP-server.
• De TVS-handtekening in het ITL-bestand komt niet overeen met het certificaat dat door TVS wordt aangeboden.
• De telefoon toont "Verificatie mislukt" wanneer het probeert het ITL-bestand of de configuratiebestanden te downloaden.
• Er bestaat geen back-up van de oude TFTP-privésleutel.

Hier is hoe u de eerste twee van deze voorwaarden te controleren.

Ten eerste kunt u de checksum van het ITL-bestand op CUCM vergelijken met het checksum ITL-bestand van de telefoon.

Er is momenteel geen manier om te kijken naar de MD5sum van het ITL-bestand op CUCM van CUCM zelf totdat u een versie uitvoert met de oplossing voor deze Cisco-bug ID CSCto60209.

Voer dit in de tussentijd uit met uw favoriete GUI- of CLI-programma's:

jasburns@jasburns-gentoo /data/trace/jasburns/certs/SBD $ tftp 14 . 48 . 44 . 80
tftp> get ITLSEP0011215A1AE3.tlv
Received 5438 bytes in 0.0 seconds
tftp> quit
jasburns@jasburns-gentoo /data/trace/jasburns/certs/SBD $ md5sum 
ITLSEP0011215A1AE3.tlv
b61910bb01d8d3a1c1b36526cc9f2ddc  ITLSEP0011215A1AE3.tlv

Hieruit blijkt dat de MD5sum van het ITL-bestand in CUCM b61910bb01d8d3a1c1b36526cc9f2ddc is.

Nu kunt u naar de telefoon zelf kijken om de hash van het ITL-bestand te bepalen dat daar is geladen: Instellingen > Beveiligingsconfiguratie > Vertrouwenslijst.

Hieruit blijkt dat de MD5sums overeenkomen. Dit betekent dat het ITL-bestand op de telefoon overeenkomt met het bestand op de CUCM, dus het hoeft niet te worden verwijderd.

Als het WEL overeenkomt, moet u doorgaan naar de volgende bewerking - bepalen of het TVS-certificaat in de ITL overeenkomt met het certificaat dat door TVS wordt gepresenteerd. Deze operatie is een beetje meer betrokken.

Kijk eerst naar de pakketopname van de telefoon die verbinding maakt met de TVS-server op TCP-poort 2445.

Klik met de rechtermuisknop op een pakket in deze stream in Wireshark, klik op Decoderen als en selecteer SSL. Zoek het servercertificaat dat er als volgt uitziet:

Kijk naar het TVS-certificaat in het vorige ITL-bestand. U ziet dan een vermelding met het serienummer 2E3E1A7BDAA64D84.

admin:show itl
        ITL Record #:3
                  ----
BYTEPOS TAG             LENGTH  VALUE
------- ---             ------  -----
1       RECORDLENGTH    2       743
2       DNSNAME         2
3       SUBJECTNAME     76      CN=CUCM8-Publisher.bbbburns.lab;
                                OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
4       FUNCTION        2       TVS
5       ISSUERNAME      76      CN=CUCM8-Publisher.bbbburns.lab;
                                OU=TAC;O=Cisco;L=RTP;ST=North Carolina;C=US
6       SERIALNUMBER    8       2E:3E:1A:7B:DA:A6:4D:84

Met succes, de TVS.pem binnenkant van het ITL-bestand komt overeen met de TVS-certificaat gepresenteerd op het netwerk. U hoeft de ITL niet te verwijderen en TVS presenteert het juiste certificaat.

Als de bestandsverificatie nog steeds mislukt, controleert u de rest van het vorige stroomschema.

Beperkingen en interacties

Certificaten regenereren / Cluster opnieuw samenstellen / Vervaldatum certificaat

Het belangrijkste certificaat is nu het CallManager.pem certificaat. Deze private key van het certificaat wordt gebruikt om alle TFTP-configuratiebestanden te ondertekenen, waaronder het ITL-bestand.

Als het bestand CallManager.pem opnieuw wordt gegenereerd, wordt een nieuw CCM+TFTP-certificaat gegenereerd met een nieuwe privésleutel. Bovendien is het ITL-bestand nu ondertekend met deze nieuwe CCM+TFTP-sleutel.

Nadat u CallManager.pem opnieuw hebt gegenereerd en de TVS- en TFTP-service opnieuw hebt gestart, gebeurt dit wanneer een telefoon wordt opgestart.

1. De telefoon probeert het nieuwe ITL-bestand te downloaden dat is ondertekend door de nieuwe CCM + TFTP van de TFTP-server. De telefoon heeft op dit moment alleen het oude ITL-bestand en de nieuwe sleutels bevinden zich niet in het ITL-bestand dat op de telefoon aanwezig is.
2. Aangezien de telefoon de nieuwe CCM+TFTP-handtekening niet kon vinden in de oude ITL, probeert deze contact op te nemen met de TVS-service.
   

   Let op: dit onderdeel is erg belangrijk. Het TVS-certificaat uit het oude ITL-bestand moet nog steeds overeenkomen. Als zowel de CallManager.pem als TVS.pem op hetzelfde exacte moment worden geregenereerd, kunnen de telefoons geen nieuwe bestanden downloaden zonder de ITL handmatig van de telefoon te verwijderen.

3. Wanneer de telefoon contact opneemt met TVS, heeft de CUCM-server waarop TVS wordt uitgevoerd het nieuwe CallManager.pem-certificaat in de Certificate Store van het besturingssysteem.
4. De TVS-server retourneert succes en de telefoon laadt het nieuwe ITL-bestand in het geheugen.
5. De telefoon probeert nu een configuratiebestand te downloaden, dat is ondertekend door de nieuwe CallManager.pem-sleutel.
6. Aangezien de nieuwe ITL is geladen, wordt het nieuw ondertekende configuratiebestand met succes geverifieerd door de ITL in het geheugen.

Belangrijkste punten:

• Regenereer nooit zowel de CallManager.pem- als de TVS.pem-certificaten tegelijk.
• Als TVS.pem of CallManager.pem opnieuw wordt gegenereerd, moeten TVS en TFTP opnieuw worden opgestart en moeten telefoons opnieuw worden ingesteld om de nieuwe ITL-bestanden te verkrijgen.
• Nieuwere versies van CUCM behandelen deze telefoon reset automatisch en waarschuwen de gebruiker op het moment van regeneratie van het certificaat.
• Als er meer dan één TVS-server bestaat (meer dan één server in de CallManager-groep), kunnen de extra servers het nieuwe CallManager.pem-certificaat verifiëren.                          

Telefoons verplaatsen tussen clusters

Wanneer u telefoons van het ene cluster naar het andere verplaatst met ITL's op hun plaats, moet rekening worden gehouden met de ITL- en TFTP-privésleutel.

Elk nieuw configuratiebestand dat aan de telefoon wordt gepresenteerd, MOET overeenkomen met een handtekening in CTL, ITL of een handtekening in de huidige TVS-service van de telefoon.

In dit document wordt uitgelegd hoe u ervoor kunt zorgen dat het nieuwe ITL-bestand en de nieuwe configuratiebestanden van het cluster kunnen worden vertrouwd door het huidige ITL-bestand op de telefoon. https://supportforums.cisco.com/docs/DOC-15799.

Back-up en herstel

Er wordt een back-up gemaakt van het CallManager.pem-certificaat en de privésleutel via Disaster Recovery System (DRS). Als een TFTP-server opnieuw wordt gebouwd, MOET deze worden teruggezet vanaf de back-up, zodat de privésleutel kan worden teruggezet.

Zonder de privésleutel CallManager.pem op de server vertrouwen telefoons met de huidige ITL's die de oude sleutel gebruiken, geen ondertekende configuratiebestanden.

Als een cluster opnieuw wordt opgebouwd en niet wordt teruggezet vanuit de back-up, is dit precies hetzelfde als het document "Bewegende telefoons tussen clusters". Dit komt omdat een cluster met een nieuwe sleutel een ander cluster is voor zover het de telefoons betreft.

Er is één ernstig defect in verband met back-up en herstel. Als een cluster gevoelig is voor Cisco bug ID CSCtn50405, bevatten de DRS-back-ups niet het CallManager.pem-certificaat.

Dit zorgt ervoor dat elke server die vanaf deze back-up wordt hersteld, corrupte ITL-bestanden genereert totdat een nieuwe CallManager.pem wordt gegenereerd.

Als er geen andere functionele TFTP-servers zijn die de back-up- en herstelbewerking niet hebben doorlopen, betekent dit mogelijk dat alle ITL-bestanden van de telefoons moeten worden verwijderd.

Om te controleren of uw CallManager.pem-bestand opnieuw moet worden gegenereerd, voert u de opdracht show itl in gevolgd door:

run sql select c.subjectname, c.serialnumber, c.ipv4address, t.name from  
certificate as c, certificatetrustrolemap as r, typetrustrole as t where  c.pkid =
r.fkcertificate and t.enum = r.tktrustrole 

In de ITL-uitvoer zijn de belangrijkste fouten waarnaar moet worden gezocht:

This etoken was not used to sign the ITL file.

en

Verification of the ITL file failed.
Error parsing the ITL file!!

In de vorige SQL-query (Structured Query Language) wordt gezocht naar de certificaten die een rol hebben als 'Authenticatie en autorisatie'.

Het CallManager.pem-certificaat in de vorige databasequery dat de rol van verificatie en autorisatie heeft, moet ook aanwezig zijn op de webpagina Certificaatbeheer van het besturingssysteem.

Als het vorige defect wordt aangetroffen, is er een mismatch tussen de CallManager.pem-certificaten in de query en op de webpagina van het besturingssysteem.

Hostnamen of domeinnamen wijzigen

Als u de hostnaam of domeinnaam van een CUCM-server wijzigt, worden alle certificaten op die server in één keer geregenereerd. De sectie certificaatregeneratie legde uit dat regeneratie van zowel de TVS.pem als CallManager.pem een "slechte zaak" is.

Er zijn een paar scenario's waarin een hostnaamwijziging mislukt en een paar waar het zonder problemen werkt. Dit gedeelte behandelt ze allemaal en koppelt ze terug naar wat u al weet over TVS en ITL uit dit document.

Cluster met één knooppunt met alleen ITL (wees voorzichtig, dit breekt zonder voorbereiding)

• Met een Business Edition-server of een implementatie alleen voor uitgevers worden zowel CallManager.pem als TVS.pem geregenereerd op hetzelfde moment dat u hostnamen wijzigt.
• Als de hostnaam op een cluster met één node wordt gewijzigd zonder eerst de hier vermelde parameter Rollback Enterprise te gebruiken, kunnen de telefoons het nieuwe ITL-bestand of de nieuwe configuratiebestanden niet verifiëren aan de hand van hun huidige ITL-bestand.
• De telefoons kunnen geen verbinding maken met TVS omdat het TVS-certificaat ook niet meer wordt vertrouwd.
• De telefoons geven een fout weer over "Verificatie vertrouwenslijst mislukt", nieuwe configuratiewijzigingen worden niet van kracht en beveiligde service-URL's mislukken.
• De enige oplossing als de voorzorgsmaatregel in stap 2 niet eerst wordt genomen, is om de ITL handmatig van elke telefoon te verwijderen.

Cluster met één knooppunt met zowel CTL als ITL (dit kan tijdelijk worden verbroken, maar kan eenvoudig worden hersteld)

• Voer de CTL-client opnieuw uit nadat u de naam van de servers hebt gewijzigd. Dit plaatst het nieuwe CallManager.pem-certificaat in het CTL-bestand dat de telefoon downloadt.
• Nieuwe configuratiebestanden, waaronder de nieuwe ITL-bestanden, kunnen worden vertrouwd op basis van de CCM+TFTP-functie in het CTL-bestand.
• Dit werkt omdat het bijgewerkte CTL-bestand wordt vertrouwd op basis van een USB eToken-privésleutel die hetzelfde blijft.

Cluster met meerdere knooppunten met alleen ITL (dit werkt over het algemeen, maar kan permanent worden verbroken als het haastig wordt gedaan)

• Omdat een cluster met meerdere knooppunten meerdere TVS-servers heeft, kunnen de certificaten van elke server probleemloos worden geregenereerd. Wanneer de telefoon wordt gepresenteerd met deze nieuwe, onbekende handtekening, vraagt het een andere van de TVS-servers om het nieuwe servercertificaat te verifiëren.
• Er zijn twee belangrijke problemen die ervoor kunnen zorgen dat dit mislukt:
  
  • Als alle servers tegelijkertijd worden hernoemd en opnieuw worden opgestart, is geen van de TVS-servers bereikbaar met bekende certificaten wanneer de servers en telefoons weer worden opgestart.
  • Als een telefoon slechts één server in de CallManager-groep heeft, maken de extra TVS-servers geen verschil. Zie het scenario "Single Node Cluster" om dit op te lossen of voeg een andere server toe aan de groep CallManager.

Cluster met meerdere knooppunten met zowel CTL als ITL (dit kan niet permanent worden verbroken)

• Nadat u de nieuwe namen hebt doorlopen, verifieert de TVS-service de nieuwe certificaten.
• Zelfs als alle TVS-servers om de een of andere reden niet beschikbaar zijn, kan de CTL-client nog steeds worden gebruikt om de telefoons bij te werken met de nieuwe CallManager.pem CCM+TFTP-certificaten.

Gecentraliseerd TFTP

Wanneer een telefoon met een ITL opstart, vraagt deze deze bestanden op: CTLSEP<MAC Address>.tlv, ITLSEP<MAC Address>.tlv, en SEP<MAC Address>.cnf.xml.sgn.

Als de telefoon deze bestanden niet kan vinden, vraagt het de ITLFile.tlv en de CTLFile.tlv, die een gecentraliseerde TFTP-server biedt aan elke telefoon die erom vraagt.

Met gecentraliseerd TFTP is er één TFTP-cluster dat verwijst naar een aantal andere subclusters.

Vaak gebeurt dit omdat telefoons op meerdere CUCM-clusters hetzelfde DHCP-bereik delen en daarom dezelfde DHCP Option 150 TFTP-server moeten hebben.

Alle IP-telefoons wijzen naar het centrale TFTP-cluster, zelfs als ze zich registreren bij andere clusters. Deze centrale TFTP-server vraagt de externe TFTP-servers op wanneer deze een verzoek ontvangt voor een bestand dat hij niet kan vinden.

Hierdoor werkt gecentraliseerd TFTP alleen in een homogene ITL-omgeving.

Alle servers moeten CUCM versie 8.x of hoger uitvoeren, of alle servers moeten versies uitvoeren die voorafgaan aan versie 8.x.

Als een ITLFile.tlv wordt weergegeven vanaf de gecentraliseerde TFTP-server, vertrouwen telefoons geen bestanden van de externe TFTP-server omdat de handtekeningen niet overeenkomen.

Dit gebeurt in een heterogene mix. In een homogene mix vraagt de telefoon ITLSEP<MAC>.tlv aan die uit het juiste externe cluster wordt getrokken.

In een heterogene omgeving met een mix van pre-Version 8.x en Version 8.x clusters, moet de "Prepare Cluster for Rollback to Pre 8.0" ingeschakeld zijn op het Version 8.x cluster zoals beschreven in Cisco bug ID CSCto87262.

Configureer de "Secure Phone URL Parameters" met HTTP in plaats van HTTPS. Hierdoor worden de ITL-functies op de telefoon effectief uitgeschakeld.

Veelgestelde vragen

Kan ik SBD uitschakelen?

U kunt SBD alleen uitschakelen als SBD en ITL momenteel werken.

SBD kan tijdelijk worden uitgeschakeld op telefoons met de Prepare Cluster for Rollback naar pre 8.0" Enterprise Parameter en door de "Secure Phone URL Parameters" te configureren met HTTP in plaats van HTTPS.

Wanneer u de parameter Rollback instelt, wordt een ondertekend ITL-bestand gemaakt met lege functievermeldingen.

Het "lege" ITL-bestand is nog steeds ondertekend, dus het cluster moet zich in een volledig functionele beveiligingsstatus bevinden voordat deze parameter kan worden ingeschakeld.

Nadat deze parameter is ingeschakeld en het nieuwe ITL-bestand met lege vermeldingen is gedownload en geverifieerd, accepteren de telefoons elk configuratiebestand, ongeacht wie het heeft ondertekend.

Het wordt niet aanbevolen om het cluster in deze status te laten, omdat geen van de drie eerder genoemde functies (geverifieerde configuratiebestanden, gecodeerde configuratiebestanden en HTTPS-URL's) beschikbaar zijn.

Kan ik gemakkelijk het ITL-bestand van alle telefoons verwijderen zodra de CallManager.pem verloren is?

Er is momenteel geen methode om alle ITL's te verwijderen van een telefoon die op afstand door Cisco is geleverd. Daarom zijn de procedures en interacties die in dit document worden beschreven zo belangrijk om rekening mee te houden.

Er is momenteel een onopgeloste verbetering van de Cisco-bug ID CSCto47052 die deze functionaliteit aanvraagt, maar deze is nog niet geïmplementeerd.

In de tussenliggende periode is een nieuwe functie toegevoegd via Cisco bug ID CSCts01319 waarmee het Cisco Technical Assistance Center (TAC) mogelijk kan terugkeren naar de eerder vertrouwde ITL als deze nog steeds beschikbaar is op de server.

Dit werkt alleen in bepaalde gevallen waarin het cluster zich op een versie met dit defect bevindt en de vorige ITL bestaat in een back-up die op een speciale locatie op de server is opgeslagen.

Bekijk het defect om te zien of uw versie de oplossing heeft. Neem contact op met Cisco TAC om de mogelijke herstelprocedure uit te voeren die in het defect wordt uitgelegd.

Als de vorige procedure niet beschikbaar is, moeten de telefoonknoppen handmatig op de telefoon worden ingedrukt om het ITL-bestand te verwijderen. Dit is de afweging die wordt gemaakt tussen veiligheid en gemak van administratie. Om ervoor te zorgen dat het ITL-bestand echt veilig is, moet het niet gemakkelijk op afstand worden verwijderd.

Zelfs als u op de knop met een script drukt met SOAP-XML-objecten (Simple Object Access Protocol), kan de ITL niet op afstand worden verwijderd.

Dit komt omdat op dit moment TVS-toegang (en dus Secure Authentication URL-toegang om inkomende SOAP XML-knopdrukobjecten te valideren) niet functioneel is.

Als de verificatie-URL niet als veilig is geconfigureerd, is het mogelijk om de toetsaanslagen te scripten om een ITL te verwijderen, maar dit script is niet beschikbaar bij Cisco.

Andere methoden om externe toetsaanslagen te scripten zonder de verificatie-URL te gebruiken, zijn mogelijk beschikbaar van een derde partij, maar deze toepassingen worden niet geleverd door Cisco.

De meest gebruikte methode om de ITL te verwijderen is een e-mailuitzending naar alle telefoongebruikers die hen instrueert over de sleutelreeks.

Als de toegangsinstellingen zijn ingesteld op Beperkt of Uitgeschakeld, moet de telefoon in de fabriek worden gereset, omdat gebruikers geen toegang hebben tot het menu Instellingen van de telefoon.