Standaard CUCM-beveiliging en ITL-werking en probleemoplossing begrijpen
Inhoud
Inleiding
Dit document beschrijft de optie Security By Default (SBD) van Cisco Unified Communications Manager (CUCM) versies 8.0 en hoger.
Achtergrondinformatie
CUCM versie 8.0 en later introduceert de SBD-functie, die bestaat uit Identity Trust List (ITL) bestanden en de Trust Verification Service (TVS).
Elk CUCM-cluster gebruikt nu automatisch ITL-gebaseerde beveiliging. Er is een afweging tussen veiligheid en gebruiksgemak/beheergemak die beheerders moeten kennen voordat ze bepaalde wijzigingen aanbrengen in een CUCM-cluster versie 8.0.
Dit document vormt een aanvulling op de officiële Standaarddocumenten van Security By Default en biedt operationele informatie en tips voor probleemoplossing om beheerders te helpen en het probleemoplossingsproces te vergemakkelijken.
Het is een goed idee om vertrouwd te raken met deze kernconcepten van SBD: Asymmetric Key Cryptography Wikipedia artikel en Public Key Infrastructure Wikipedia artikel.
SBD-overzicht
Deze sectie geeft een snel overzicht van wat SBD precies biedt. Zie het gedeelte SBD Detail- en probleemoplossing voor meer informatie over elke functie en voor meer technische informatie.
SBD biedt deze drie functies voor ondersteunde IP-telefoons:
- Standaard verificatie van door TFTP gedownloade bestanden (configuratie, lokaal, ringlist) die een ondertekeningssleutel gebruiken
- Optionele encryptie van TFTP-configuratiebestanden die een ondertekeningssleutel gebruiken
- Certificaatverificatie voor door de telefoon geïnitieerde HTTPS-verbindingen die gebruikmaken van een extern certificaatvertrouwensarchief op CUCM (TVS)
Dit document geeft een overzicht van al deze functies.
TFTP-downloadverificatie
Wanneer een CTL-bestand (Certificate Trust List) of ITL-bestand aanwezig is, vraagt de IP-telefoon een ondertekend TFTP-configuratiebestand aan bij de CUCM TFTP-server.
Dit bestand staat de telefoon toe om te verifiëren dat 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 onbewerkte 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 door de privé-sleutel van TFTP die overeenkomt met CallManager.pem op de pagina Besturingssysteem (OS) Management Certificate Management.
Het ondertekende bestand heeft een handtekening bovenaan om het bestand te verifiëren, maar is anders in onbewerkte tekst XML.
De afbeelding hieronder laat zien dat de ondertekenaar van het configuratiebestand CN=CUCM8-Publisher.bbbburns.lab is, die op zijn beurt is 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 is geaccepteerd.
Hier is een diagram dat toont hoe de privé-sleutel samen met een Berichtenoverzicht algoritme (MD)5 of Secure Hash Algorithm (SHA)1 hashfunctie wordt gebruikt om het ondertekende bestand te maken.
De verificatie van de handtekening keert dit proces door het gebruik van de openbare sleutel om die aanpast om de knoeiboel te decrypteren. Als de hashes overeenkomen, toont het:
- Dit bestand is tijdens het transport niet gewijzigd.
- Dit bestand is afkomstig van de partij die in de handtekening wordt vermeld, aangezien alles dat met succes is gedecodeerd met de openbare sleutel versleuteld moet zijn met de privé-sleutel.
TFTP-configuratiebestandsversleuteling
Als de optionele TFTP-configuratieencryptie is ingeschakeld in het bijbehorende telefoonbeveiligingsprofiel, vraagt de telefoon om een versleuteld configuratiebestand.
Dit bestand is ondertekend met de privé-sleutel van TFTP en is versleuteld met een symmetrische sleutel die is uitgewisseld tussen de telefoon en de CUCM (raadpleeg de Cisco Unified Communications Manager Security Guide, release 8.5(1) voor meer informatie).
De inhoud kan niet worden gelezen met een netwerksnuffel tenzij de waarnemer de nodige toetsen heeft.
De telefoon vraagt SEP<MAC Address>.cnf.xml.enc.sgn om het ondertekende versleutelde bestand te krijgen.
Het versleutelde configuratiebestand heeft de handtekening aan het begin ook, maar er zijn geen onbewerkte tekstgegevens na, alleen versleutelde gegevens (vernielde 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 decryptie sleutels correct zijn voordat de telefoon de inhoud van het bestand kan lezen.
Trustverificatieservice (certificaat op afstand en verificatie van handtekeningen)
IP-telefoons bevatten een beperkte hoeveelheid geheugen en er kan ook een groot aantal telefoons in een netwerk worden beheerd.
CUCM fungeert als een externe vertrouwensopslag via de TVS, zodat een volledige certificaatvertrouwensopslag niet 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, vraagt hij de TVS-server om verificatie.
Deze centrale vertrouwensopslag is gemakkelijker te beheren dan als de vertrouwensopslag op alle IP telefoons aanwezig was.
Informatie over SBD-details en probleemoplossing
In deze sectie wordt het SBD-proces uitvoerig beschreven.
ITL-bestanden en -certificaten aanwezig op CUCM
Eerst, zijn er een aantal dossiers die op de server CUCM zelf aanwezig moeten zijn. Het belangrijkste is het TFTP-certificaat en de private sleutel van TFTP.
Het TFTP-certificaat bevindt zich onder OS-beheer > Beveiliging > Certificaatbeheer > CallManager.pem.
De CUCM-server gebruikt de privaat- en openbare sleutels van het CallManager.pem-certificaat voor de TFTP-service (en voor de Cisco Call Manager (CCM)-service).
De afbeelding laat zien dat het CallManager.pem certificaat wordt afgegeven aan CUCM8-uitgever.bbbburns.lab en ondertekend door JASBURNS-AD. Alle TFTP-configuratiebestanden worden ondertekend door de onderstaande privésleutel.
Alle telefoons kunnen de openbare sleutel van TFTP in het certificaat van CallManager.pem gebruiken om elk bestand te decoderen dat met de privé-sleutel van TFTP is versleuteld en om elk bestand te verifiëren dat met de privé-sleutel van TFTP is ondertekend.
Naast de CallManager.pem certificaat privé-sleutel, slaat de CUCM-server ook een ITL-bestand op dat aan telefoons wordt getoond.
De opdracht show itl toont de volledige inhoud van dit ITL-bestand via Secure Shell (SSH) toegang tot de CUCM-server OS CLI.
Deze sectie breekt het ITL-bestand stuk voor stuk op, omdat het een aantal belangrijke componenten heeft die de telefoon gebruikt.
Het eerste deel is de handtekeningsinformatie. Zelfs het ITL-bestand is een ondertekend bestand. Deze output toont aan dat het door de privé sleutel van TFTP wordt ondertekend die met het vorige certificaat CallManager.pem wordt geassocieerd.
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 het Security Token voor systeembeheerders. Dit is de handtekening van de openbare sleutel van TFTP.
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 sleutel van TFTP die dient om gedownloade TFTP-configuratiebestanden te verifiëren en te decrypteren.
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 TV. Er is een ingang voor de openbare sleutel van elke TVS-server waarmee de telefoon verbindt.
Hierdoor kan de telefoon een Secure Sockets Layer (SSL) sessie instellen voor 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 (CAPF).
Met dit certificaat kunnen de telefoons een beveiligde verbinding maken met de CAPF-service op de CUCM-server, zodat de telefoon een Locally Significant Certificate (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.
De volgende sectie behandelt precies wat gebeurt wanneer een telefoonlaarzen.
Telefoondownloads ITL en configuratiebestand
Nadat de telefoon start en verkrijgt een IP-adres evenals het adres van een TFTP-server, vraagt het eerst om de CTL en de ITL-bestanden.
Deze pakketopname toont een telefoonverzoek voor het ITL-bestand. Als u op tftp.opcode == 1 filtert, ziet u elke TFTP Lees Aanvraag van de telefoon:
Aangezien de telefoon met succes CTL- en ITL-bestanden van TFTP heeft ontvangen, vraagt de telefoon om een ondertekend configuratiebestand.
De logboeken van de telefoonconsole die dit gedrag tonen zijn beschikbaar bij de interface van het telefoonWeb:
Eerst vraagt de telefoon om een CTL-bestand, 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
Daarna vraagt de telefoon ook om een ITL-bestand:
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 dit worden geverifieerd. Er zijn een aantal staten waar een telefoon in kan zijn op dit punt, dus dit document bedekt ze allemaal.
- De telefoon heeft geen CTL of ITL bestand aanwezig of ITL is leeg vanwege de Pre 8.0 parameter Voorbereiden Cluster voor Rollback. in deze staat, vertrouwt de telefoon blindelings op het volgende CTL of ITL bestand gedownload en gebruikt deze handtekening voortaan.
- De telefoon heeft al een CTL maar geen ITL. In deze staat, vertrouwt de telefoon alleen op een ITL als het kan worden geverifieerd door de functie CCM+TFTP in het CTL bestand.
- De telefoon heeft al een CTL en een ITL bestand. In deze staat, de telefoon verifieert dat de onlangs gedownloade bestanden overeenkomen met de handtekening in of 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 een CTL en ITL dus het gewoon gecontroleerd tegen hen en vond de juiste handtekening.
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 vanaf dit punt alleen ondertekende configuratiebestanden.
Dit illustreert dat de telefoonlogica moet bepalen dat de server van TFTP veilig is, gebaseerd op de aanwezigheid van CTL en ITL, en dan om een ondertekend bestand te vragen:
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 authenticeren tegen de functie voor CCM+TFTP in het ITL:
937: NOT 09:13:18.656906 SECD: verifyFile: verify SUCCESS
</usr/ram/SEP0011215A1AE3.cnf.xml>
Telefonisch contact opnemen met 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 werkt op alle servers waar de CallManager-service is geactiveerd. De CUCM TFTP-service gebruikt de geconfigureerde CallManager-groep om een lijst met TVS-servers te maken waarmee de telefoon contact moet opnemen in het telefoonconfiguratiebestand.
Sommige laboratoria gebruiken slechts één CUCM-server. In een multi-node CUCM-cluster kunnen er maximaal drie TVS-vermeldingen zijn voor een telefoon, één voor elke CUCM in de CUCM-groep van de telefoon.
Dit voorbeeld laat zien wat er gebeurt als de knop directory's op de IP-telefoon wordt ingedrukt. De URL van de directory's wordt geconfigureerd voor HTTPS, zodat de telefoon wordt aangeboden met het Tomcat-webcertificaat van de server van de directory's.
Dit Tomcat webcertificaat (tomcat.pem in OS Administration) is niet geladen in de telefoon, dus de telefoon moet contact opnemen met TVS om het certificaat te verifiëren.
Raadpleeg het vorige TVS - Overzicht diagram voor een beschrijving van de interactie. Hier is het logperspectief van de telefoonconsole:
Eerst vindt u de URL van de map:
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 die verificatie vereist.
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 verifieert eerst dat het certificaat dat door de SSL/TLS server wordt voorgelegd in CTL aanwezig is. Dan bekijkt de telefoon de Functies in het ITL-bestand om te zien of het een overeenkomst vindt.
Deze foutmelding zegt "HTTPS cert not in CTL", wat betekent "dat certificering niet kan worden gevonden in de CTL of het 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 het TVS-cache.
Dit wordt gedaan om op netwerkverkeer te snijden als de telefoon onlangs de TVS-server om hetzelfde certificaat heeft gevraagd.
Als het HTTPS-certificaat niet wordt gevonden in het telefooncachegeheugen, 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 (Secure HTTP, of HTTPS) is, dus het is ook een certificaat dat moet worden geverifieerd tegen de CTL naar 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 de TVS-server "Hallo, vertrouw ik op dit Directories-servercertificaat?" te vragen
Dit voorbeeld toont het antwoord op die vraag - een antwoord van 0 wat succes (geen fout) betekent.
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 TVS een succesvolle respons geeft, worden de resultaten voor dat certificaat opgeslagen in de cache.
Dit betekent dat, als u binnen de volgende 86.400 seconden weer op de knop directory's drukt, u geen contact hoeft op te nemen met de TVS-server om het certificaat te verifiëren. U heeft eenvoudig toegang 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
Tot slot controleert u of uw verbinding met de Directories server geslaagd is.
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 draait. U kunt TVS-logbestanden verzamelen met de Cisco Unified Real-Time Monitoring Tool (RTMT).
De CUCM TVS-logboeken tonen dat je SSL-handdruk met de telefoon, de telefoon vraagt TVS over het Tomcat-certificaat, dan reageert TVS om aan te geven dat het certificaat is afgestemd 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 van alle certificaten op de webpagina Bestuursbeheer > Certificaatbeheer.
Controleer handmatig of de telefoon ITL overeenkomt met CUCM ITL
Een veel voorkomende misvatting die wordt gezien bij probleemoplossing betreft de neiging om het ITL-bestand te verwijderen in de hoop dat het een probleem met bestandsverificatie oplost.
Soms wordt het wissen van ITL-bestanden vereist, maar het ITL-bestand hoeft alleen te worden verwijderd wanneer 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 "Verification Failure" wanneer het probeert om het ITL-bestand of de configuratiebestanden te downloaden.
- Er bestaat geen back-up van de oude privé-sleutel van TFTP.
Hier zie je hoe je de eerste twee van deze condities controleert.
Eerst, kunt u de controlesom van het ITL- dossier vergelijken huidig op CUCM met het controlesom ITL- dossier van de telefoon.
Er is momenteel geen manier om de MD5sum van het ITL-bestand op CUCM zelf te bekijken vanaf CUCM tot u een versie met de fix voor deze Cisco bug ID CSCto60209 uitvoert.
Voer dit ondertussen 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
Dit toont aan dat de MD5sum van het ITL-bestand in CUCM b61910bb01d8d3a1c1b36526cc9f2ddc is.
Nu kunt u de telefoon zelf bekijken om de hash van het ITL-bestand te bepalen dat daar geladen is: Instellingen > Beveiligingsconfiguratie > Vertrouwenlijst.
Hieruit blijkt dat de MD5sum overeenkomt. 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 naar de volgende handeling gaan - bepalen of het TVS-certificaat in het ITL overeenkomt met het certificaat dat door TVS wordt aangeboden. 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 zo uitziet:
Bekijk het TVS-certificaat in het vorige ITL-bestand. Vervolgens wordt een vermelding weergegeven met het serienummer 2E3E1A7BDA64D84.
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 komt de TVS.pem in het ITL-bestand overeen met het TVS-certificaat dat op het netwerk wordt weergegeven. U hoeft het 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 herstellen / een cluster opnieuw opbouwen / verlopen certificaten
Het belangrijkste certificaat is nu het CallManager.pem certificaat. Deze certificaat privé-sleutel wordt gebruikt om alle TFTP-configuratiebestanden te ondertekenen, waaronder het ITL-bestand.
Als het bestand CallManager.pem opnieuw wordt gegenereerd, wordt er een nieuw CCM+TFTP-certificaat gegenereerd met een nieuwe privé-sleutel. Bovendien is het ITL-bestand nu ondertekend door deze nieuwe CCM+TFTP-toets.
Nadat u CallManager.pem regenereert en de TVS en TFTP service opnieuw start, gebeurt dit wanneer een telefoon opstart.
- De telefoon probeert het nieuwe ITL-bestand te downloaden dat ondertekend is door de nieuwe CCM+TFTP vanaf de TFTP-server. De telefoon heeft alleen het oude ITL-bestand op dit punt, en de nieuwe sleutels zijn niet in het ITL-bestand aanwezig op de telefoon.
- Aangezien de telefoon de nieuwe handtekening CCM+TFTP in het oude ITL niet kon vinden, probeert het contact op te nemen met de TVS-dienst.
- Wanneer de telefoon contact maakt met TVS, de CUCM-server die TVS uitvoert, heeft het nieuwe CallManager.pem certificaat in de OS Certificate Store.
- De TVS-server heeft succes en de telefoon laadt het nieuwe ITL-bestand in het geheugen.
- De telefoon probeert nu om een configuratiebestand te downloaden, dat is ondertekend door de nieuwe CallManager.pem-toets.
- Aangezien het nieuwe ITL is geladen, wordt het nieuw ondertekende configuratiebestand met succes geverifieerd door het ITL in het geheugen.
Belangrijkste punten:
- Regenereert nooit tegelijkertijd de CallManager.pem- en TVS.pem-certificaten.
- Als TVS.pem of CallManager.pem wordt geregenereerd, moeten TVS en TFTP opnieuw worden gestart en moeten telefoons opnieuw worden ingesteld om de nieuwe ITL-bestanden te verkrijgen.
- Nieuwe versies van CUCM behandelen deze telefoon automatisch teruggesteld en waarschuwen de gebruiker bij de regeneratietijd 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 tussen clusters verplaatsen
Wanneer u telefoons van één cluster naar een andere met ITL's op zijn plaats beweegt, moet met ITL en de Privé Sleutel van TFTP worden rekening gehouden.
Elk nieuw configuratiebestand dat aan de telefoon wordt gepresenteerd, MOET overeenkomen met een handtekening in CTL, ITL of een handtekening in de telefoon huidige TVS-service.
Dit document legt uit hoe u ervoor kunt zorgen dat de nieuwe cluster ITL-bestand en configuratiebestanden kunnen worden vertrouwd door het huidige ITL-bestand op de telefoon. https://supportforums.cisco.com/docs/DOC-15799.
Back-up en herstel
Van het CallManager.pem-certificaat en de persoonlijke sleutel wordt een back-up gemaakt via het Disaster Recovery System (DRS). Als een TFTP-server opnieuw wordt opgebouwd, MOET deze worden hersteld vanaf de back-up, zodat de privé-sleutel kan worden hersteld.
Zonder de privé sleutel van CallManager.pem op de server, vertrouwen de telefoons met huidige ITLs die de oude sleutel gebruiken niet op ondertekende configuratiedossiers.
Als een cluster opnieuw wordt opgebouwd en niet van back-up wordt hersteld, is het precies zoals het document "Verplaatsende telefoons tussen clusters". Dit komt doordat een cluster met een nieuwe sleutel een ander cluster is wat de telefoons betreft.
Er is één ernstig defect verbonden aan back-up en herstel. Als een cluster gevoelig is voor Cisco bug-id CSC50405, bevatten de DRS-back-ups niet het CallManager.pem-certificaat.
Dit zorgt ervoor dat elke server die via deze back-up is 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 terugzetbewerking niet hebben doorlopen, betekent dit mogelijk dat alle ITL-bestanden uit de telefoons moeten worden verwijderd.
Om te verifiëren of uw CallManager.pem-bestand moet worden geregenereerd, 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 die moeten worden gezocht:
This etoken was not used to sign the ITL file.
en
Verification of the ITL file failed.
Error parsing the ITL file!!
De vorige gestructureerde vraag van de Vraag van de Taal (SQL) zoekt naar de certificaten die een rol van "Verificatie en Vergunning." hebben
Het CallManager.pem-certificaat in de vorige databasevraag die de rol van verificatie en autorisatie heeft, moet ook aanwezig zijn in de webpagina van het OS-beheercertificaat.
Als het vorige defect wordt aangetroffen, is er een wanverhouding tussen de CallManager.pem-certificaten in de query en in de OS-webpagina.
Host Names of Domain Names wijzigen
Als u de hostnaam of de domeinnaam van een CUCM-server wijzigt, worden alle certificaten tegelijk op die server opnieuw gegenereerd. De sectie van de certificaatregeneratie verklaarde dat regeneratie van zowel TVS.pem als CallManager.pem een "slecht ding." is
Er zijn een paar scenario's waar een hostname verandering mislukt, en een paar waar het werkt zonder problemen. Deze paragraaf behandelt ze allemaal en koppelt ze terug naar wat u al weet over TV's en ITL uit dit document.
Cluster met één knooppunt en alleen ITL (let op; dit breekt zonder voorbereiding)
- Met een Business Edition server of alleen uitgever-implementatie worden zowel CallManager.pem als TVS.pem tegelijkertijd opnieuw gegenereerd wanneer u hostnamen wijzigt.
- Als de hostname wordt gewijzigd op een enkele knooppunt cluster zonder eerst de Rollback Enterprise parameter te gebruiken die hier wordt behandeld, zijn de telefoons niet in staat om het nieuwe ITL-bestand of de configuratie bestanden te verifiëren tegen hun huidige ITL-bestand.
- De telefoons kunnen geen verbinding maken met TVS omdat het TVS-certificaat ook niet langer wordt vertrouwd.
- De telefoons tonen een fout over "Vertrouwen Lijst Verificatie mislukte,"geen nieuwe configuratieveranderingen worden van kracht, en de veilige dienst URLs ontbreken.
- De enige oplossing als de voorzorgsmaatregel in stap 2 niet eerst wordt genomen is om het ITL van elke telefoon handmatig te verwijderen.
Cluster met één knooppunt, zowel CTL als ITL (dit kan tijdelijk worden verbroken, maar eenvoudig worden hersteld)
- Nadat u de hernaam van servers hebt uitgevoerd, voert u de CTL-client opnieuw uit. Dit plaatst het nieuwe CallManager.pem certificaat in het CTL-bestand dat de telefoon downloadt.
- Nieuwe configuratiebestanden, die de nieuwe ITL-bestanden bevatten, 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 private USB eToken-toets die hetzelfde blijft.
Multi-Node Cluster met alleen ITL (dit werkt over het algemeen, maar kan permanent worden verbroken als dit overhaast gebeurt)
- Omdat een multi-knooppunt cluster meerdere TVS-servers heeft, kan elke server zijn certificaten zonder een probleem laten regenereren. Wanneer de telefoon met deze nieuwe, onbekende handtekening wordt voorgesteld, vraagt het een andere van de servers van TVS om het nieuwe servercertificaat te verifiëren.
- Er zijn twee belangrijke problemen die tot een mislukking kunnen leiden:
- Als alle servers tegelijkertijd hernoemd en opnieuw opgestart worden, is geen van de TVS-servers bereikbaar met bekende certificaten wanneer de servers en telefoons terug komen.
- Als een telefoon slechts één server in de CallManager Group heeft, maken de extra TVS-servers geen verschil. Zie het "Single Node Cluster" scenario om dit op te lossen, of voeg een andere server toe aan de telefoon CallManager Group.
Multi-Node Cluster met zowel CTL als ITL (dit kan niet permanent worden verbroken)
- Nadat u de hernamen 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.
Gecentraliseerde TFTP
Wanneer een telefoon met een ITL laarzen, vraagt het deze bestanden: 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 ITLFile.tlv en de CTLFile.tlv, die een gecentraliseerde TFTP-server biedt aan elke telefoon die erom vraagt.
Met gecentraliseerd TFTP, is er één enkele cluster van TFTP die aan een aantal andere subclusters richt.
Dit gebeurt vaak omdat telefoons op meerdere CUCM-clusters dezelfde DHCP-scope delen en daarom dezelfde DHCP-optie 150 TFTP-server moeten hebben.
Alle IP-telefoons verwijzen naar het centrale TFTP-cluster, zelfs als ze zich op andere clusters registreren. Deze centrale TFTP-server vraagt naar de externe TFTP-servers wanneer het een verzoek ontvangt voor een bestand dat het niet kan vinden.
Vanwege deze operatie 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 voorafgaand aan Versie 8.x.
Als een ITLFile.tlv van de Gecentraliseerde server van TFTP wordt voorgesteld, vertrouwen de telefoons geen dossiers van de verre server van TFTP omdat de handtekeningen niet aanpassen.
Dit gebeurt in een heterogene mix. In een homogene mix vraagt de telefoon om ITLSEP<MAC>.tlv die uit de juiste externe cluster wordt gehaald.
In een heterogene omgeving met een combinatie van pre-Versie 8.x- en Versie 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 "Beveiligde telefoon URL-parameters" met HTTP in plaats van HTTPS. Dit schakelt effectief de ITL-functies op de telefoon uit.
Veelgestelde vragen
Kan ik de 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 to 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 er een ondertekend ITL-bestand met lege functiewaarden gemaakt.
Het "lege" ITL-bestand is nog steeds ondertekend, dus het cluster moet in een volledig functionele beveiligingsstatus zijn voordat deze parameter kan worden ingeschakeld.
Nadat deze parameter is ingeschakeld en het nieuwe ITL-bestand met lege vermeldingen wordt 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, versleutelde configuratiebestanden en HTTPS URL’s) beschikbaar zijn.
Kan ik gemakkelijk het ITL-bestand van alle telefoons verwijderen wanneer de CallManager.pem is verloren?
Er is momenteel geen methode om alle ITL's te verwijderen van een telefoon die op afstand door Cisco wordt geleverd. Daarom zijn de procedures en interacties die in dit document worden beschreven zo belangrijk om rekening mee te houden.
Er is een momenteel onopgeloste verbetering van Cisco bug ID CSCto47052 die om deze functionaliteit verzoekt, maar deze is nog niet geïmplementeerd.
In de tussenliggende periode is een nieuwe functie toegevoegd via Cisco bug-id CSCts01319, die het Cisco Technical Assistance Center (TAC) mogelijk in staat stelt om terug te keren naar het eerder vertrouwde ITL als dit nog steeds op de server beschikbaar is.
Dit werkt alleen in bepaalde gevallen waar het cluster op een versie met deze defecte fix staat en waar het vorige ITL bestaat in een back-up die opgeslagen is op een speciale locatie op de server.
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 is 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 beheersgemak. Om het ITL-bestand echt veilig te maken, moet het niet gemakkelijk op afstand kunnen worden verwijderd.
Zelfs met scripted knoppersen met Simple Object Access Protocol (SOAP) XML-objecten kan het ITL niet op afstand worden verwijderd.
Dit komt doordat TVS-toegang (en dus Secure Authenticatie URL-toegang om inkomende SOAP XML-knopdrukobjecten te valideren) niet-functioneel is.
Als de verificatie-URL niet als beveiligd is geconfigureerd, is het mogelijk om de toetspersen te scripten om een ITL te verwijderen, maar dit script is niet beschikbaar bij Cisco.
Andere methoden om externe toetspersen te kunnen uitvoeren zonder de verificatie-URL te gebruiken, zijn mogelijk beschikbaar bij een derde partij, maar deze toepassingen worden niet geleverd door Cisco.
De meest gebruikte methode om het ITL te verwijderen is een e-mailuitzending naar alle telefoongebruikers die hen instrueert over de sleutelreeks.
Als de montagestoegang aan Beperkt of Gehandicapten wordt geplaatst, moet de telefoon fabrieksteruggesteld worden, aangezien de gebruikers geen toegang tot het menu van Instellingen van de telefoon hebben.
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
2.0 |
14-Jul-2023 |
Hercertificering |
1.0 |
27-May-2013 |
Eerste vrijgave |
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)