ECS: Sådan konfigurerer og accepterer du certifikater via LDAPS på ECS
Summary: Sådan konfigurerer og accepterer du certifikater via LDAPS (Lightweight Directory Access Protocol Secure) på ECS.
Instructions
LDAPS, også kendt som LDAP (Lightweight Directory Access Protocol) over SSL (Secure Socket Layer) eller TLS (Transport Layer Security), er en krypteret trafikform for LDAP-brug til en Active Directory- (AD) eller LDAP-server.
LDAPS afhænger af en fungerende LDAP-forbindelse. Gennemgå ECS-administrationsvejledningen og denne vidensartikel ECS: Sådan oprettes en AD- eller LDAP-serverforbindelse i brugergrænsefladen
En kritisk komponent med SSL- eller TLS-kommunikation er certifikaterne. Sørg for, at de anvendte certifikater ikke er udløbet og ugyldige. Dette er vigtigt, for at alle certifikater i hele certifikatkæden er korrekte.
Spørg dit netværksteam i den henseende.
Hvis du vil overføre LDAPS-certifikatkæden og aktivere LDAPS, skal du være opmærksom på følgende trin.
1. En nodeadministrations-IP-adresse er et must for at kunne overføre LDAPS-certifikatkæden.
2. UI-rodbrugeren skal overføre LDAPS-certifikatkæden til CLI-grænsefladen til nodeadministration.
3A. LDAPS-certifikatkæden i XML-data til nodeadministrations-IP-adressen
3B. LDAPS aktiverer parameterindstilling i en XML-nyttelast til nodeadministrationens IP-adresse
4. Brug LDAPS på siden ECS-godkendelsesudbyder med et fuldt kvalificeret domænenavn (FQDN) i stedet for en IP-adresse.
5. Test domænets brugerlogin.
I trin 3
skal du bruge et FQDN i stedet for en IP-adresse som:
"Med SSL-certifikater skal certifikatet have et SAN (Subject Alternate Name) i certifikatet for at matche den forbindelse, der oprettes forbindelse til, SAN får kun vist et DNS-navn, der svarer til konfigurationen på ECS."
Bekræft derfor, at siden ECS-godkendelsesudbyder, serverens URL-dialogboks, bruger et FQDN i stedet for en IP-adresse.
Eksempel: ldaps://ad-or-ldap-fqdn-domain.com
Ovenstående trin:
- En nodeadministrations-IP-adresse er et must for at kunne overføre LDAPS-certifikatkæden.
Hvis du vil undersøge ECS-indstillingerne vedrørende LDAPS-certifikatindstillingerne, skal du først bruge en nodeadministrations-IP.
Hvis der er netværksadskillelse for UI-administrationen, viser "getrackinfo -n" "MGMT"-værdierne.
Brug noderne MGMT IP-adresse. Replikering og datanetværksadskillelse er ikke relateret til disse trin:
admin@node1:~> getrackinfo -n Named networks ============== Node ID Network Ip Address Netmask Gateway VLAN Interface 1 repl 10.xxx.xxx.11 255.255.254.0 xxx.xxx.xxx.xxx 14 public 1 mgmt 10.xxx.xxx.21 255.255.254.0 xxx.xxx.xxx.xxx 13 public 1 data 10.xxx.xxx.31 255.255.254.0 xxx.xxx.xxx.xxx 15 public 2 repl 10.xxx.xxx.12 255.255.254.0 xxx.xxx.xxx.xxx 14 public 2 mgmt 10.xxx.xxx.22 255.255.254.0 xxx.xxx.xxx.xxx 13 public 2 data 10.xxx.xxx.32 255.255.254.0 xxx.xxx.xxx.xxx 15 public 3 repl 10.xxx.xxx.13 255.255.254.0 xxx.xxx.xxx.xxx 14 public 3 mgmt 10.xxx.xxx.23 255.255.254.0 xxx.xxx.xxx.xxx 13 public 3 data 10.xxx.xxx.33 255.255.254.0 xxx.xxx.xxx.xxx 15 public 4 repl 10.xxx.xxx.14 255.255.254.0 xxx.xxx.xxx.xxx 14 public 4 mgmt 10.xxx.xxx.24 255.255.254.0 xxx.xxx.xxx.xxx 13 public 4 data 10.xxx.xxx.34 255.255.254.0 xxx.xxx.xxx.xxx 15 public
Hvis der ikke er nogen netværks-MGMT-adskillelse på VDC'en, skal du bruge nodens offentlige IP-adresse i stedet.
I følgende eksempel findes der ingen MGMT i "getrackinfo -n"; Brug derfor den offentlige IP-adresse i getrackinfo som administrations-IP-adresse for de næste trin.
admin@node1:~> getrackinfo -n Named networks ============== Node ID Network Ip Address Netmask Gateway VLAN Interface admin@node1:~> admin@node1:~> getrackinfo Node private Node Public BMC Ip Address Id Status Mac Ip Address Mac Ip Address Node Name =============== ====== ====== ================= ================= ================= ================= ========= 192.1XX.2XX.1 1 MA a4:bf:xx:xx:xx:74 10.xx.xx.1 a4:bf:xx:xx:xx 192.1XX.2XX.101 provo-red 192.1XX.2XX.2 2 SA a4:bf:xx:xx:xx:c8 10.xx.xx.2 a4:bf:xx:xx:xx 192.1XX.2XX.102 sandy-red 192.1XX.2XX.3 3 SA a4:bf:xx:xx:xx:e0 10.xx.xx.3 a4:bf:xx:xx:xx 192.1XX.2XX.103 orem-red 192.1XX.2XX.4 4 SA a4:bf:xx:xx:xx:56 10.xx.xx.4 a4:bf:xx:xx:xx 192.168.219.104 ogden-red
2. UI-rodbrugeren skal overføre LDAPS-certifikatkæden til CLI-grænsefladen til nodeadministration.
Brug administrations-IP-adressen, der er indsamlet, til at hente rodbrugertokenet. Root-brugeradgangskode er påkrævet (eller en brugergrænsefladebruger med brugergrænsefladeadministratorrettigheder):
curl -s -k -v -u <user> https://<NodeManagementIP>:4443/login 2>&1
# curl -s -k -v -u root https://10.xxx.xxx.21:4443/login 2>&1 Enter host password for user 'root': ...... < HTTP/1.1 200 OK < Date: Thu, 14 Jan 2021 13:51:24 GMT < Content-Type: application/xml < Content-Length: 93 < Connection: keep-alive < X-SDS-AUTH-TOKEN: BAAcdWhGbnVRVjd1WlpmR0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxAgAC0A8= < X-SDS-AUTH-USERNAME: root < X-SDS-AUTH-MAX-AGE: 28800 < * Connection #0 to host 10.xxx.xxx.21 left intact <?xml version="1.0" encoding="UTF-8" standalone="yes"?><loggedIn><user>root</user></loggedIn>
Hvis outputtet ikke er "HTTP/1.1 200 OK", skal du kontrollere adgangskoden og IP-adressen, hvis UI-administrationsnetværket er adskilt fra kommandoen
"getrackinfo -n."Opret en tokenvariabel med rodbrugertokenet.
# export TOKEN='X-SDS-AUTH-TOKEN: BAAcdWhGbnVRVjd1WlpmR0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxAgAC0A8='
Hvis du vil teste tokenværdien, skal du køre en curl Kommando til kontrol af kapacitet:
# curl -k -X GET -H "$TOKEN" https://10.xxx.xxx.21:4443/object/capacity | xmllint --format - % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 176 100 176 0 0 249 0 --:--:-- --:--:-- --:--:-- 250 <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <cluster_capacity> <totalFree_gb>100657</totalFree_gb> <totalProvisioned_gb>447005</totalProvisioned_gb> </cluster_capacity>
3A. LDAPS-certifikatkæden i XML-data til nodeadministrations-IP-adressen
3B. Parameterindstillingen LDAPS aktiveres. Accepter LDAPS-parameter i XML-data til nodeadministrations-IP-adressen.
Ovenstående bruger root-brugertokenet til at få curl-adgang til ECS UI-tillidslageret, hvor LDAPS-certifikatet kan uploades.
Se ECS-administrationsvejledningen for at få flere oplysninger om "Tilføj specielt LDAP-certifikat".
Hent indstillingerne for truststore med en curl GET kommando:
curl -s -k -X GET -H Content-Type:application/xml -H "$TOKEN" -H ACCEPT:application/xml https://<NodeManagementIP>:4443/vdc/truststore/settings | xmllint --format -
curl -s -k -X GET -H Content-Type:application/xml -H "$TOKEN" -H ACCEPT:application/xml https://10.xxx.xxx.21:4443/vdc/truststore/settings | xmllint --format - <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <truststore_settings> <accept_all_certificates>false</accept_all_certificates> </truststore_settings>
I ovenstående eksempel er truststore "accept_all_certificates" er indstillet til falsk. Det betyder, at der ikke er tillid til LDAPS-certifikater.
Den "accept_all_certificates" udtrykket kan være tvetydigt, men det er et flag, der fortsat bruges til ECS til at afgøre, om LDAPS-certifikater skal bruges.
En bruger ønsker måske, at dette sæt er sandt eller falsk, afhængigt af deres behov. Hvis du vil teste LDAPS-forbindelsen, kan LDAPS-forbindelsen valideres ved at indstille den til true og teste brugerens log ind.
"accept_all_certificates" vender tilbage til falsk. Så hvis du redigerer truststore, skal du indstille "accept_all_certificates" Tilbage til True bagefter.
Opret en xml-fil for at ændre truststore-indstillingerne ved hjælp af en curl-kommando med xml-data:
# sudo vi truststoresettings.xml <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <truststore_settings_changes> <accept_all_certificates>true</accept_all_certificates> </truststore_settings_changes> # cat truststoresettings.xml | xmllint --format - <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <truststore_settings_changes> <accept_all_certificates>true</accept_all_certificates> </truststore_settings_changes>
Hvis du vil angive accept_all_certificates til falsk, skal du redigere datafilen til falsk i stedet for sand og køre kommandoen PUT ved hjælp af datafilen.
Kør en curl-kommando med en xml-fil som nyttelast med en curl PUT-kommando:
# curl -s -k -X PUT -H Content-Type:application/xml -H "$TOKEN" -H ACCEPT:application/xml https://<NodeManagementIP>:4443/vdc/truststore/settings --data-binary @truststoresettings.xml
For at kontrollere, at "accept_all_certificates" er opdateret, skal du køre kommandoen curl GET:
# curl -s -k -X GET -H Content-Type:application/xml -H "$TOKEN" -H ACCEPT:application/xml https://10.xxx.xxx.21:4443/vdc/truststore/settings | xmllint --format - <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <truststore_settings_changes> <accept_all_certificates>true</accept_all_certificates> </truststore_settings_changes>
Sådan undersøger du truststore, ikke kun truststore-indstillingen:
# curl -s -k -X GET -H Content-Type:application/xml -H "$TOKEN" -H ACCEPT:application/xml https://<NodeManagementIP>:4443/vdc/truststore | xmllint --format -
Et eksempel på et tomt LDAP-certifikattillidslager:
# curl -s -k -X GET -H Content-Type:application/xml -H "$TOKEN" -H ACCEPT:application/xml https://<NodeManagementIP>:4443/vdc/truststore | xmllint --format - <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <trusted_certificates/>
Der kan være behov for flere certifikater, da ECS kræver hele certifikatkæden, rodcertifikatet, CA-certifikatet, værtscertifikatet osv.
Hvis du vil føje et certifikat til truststore, skal du oprette en xml-fil med det certifikat, brugeren har. Et certifikat kan være filtyperne .pem, .crt, .cer osv.
Hvis du vil uploade certifikaterne til ECS, skal de være i et xml-format, så de fungerer som xml-data.
Certifikatets fil i ikke-xml-format:
# cat cert.crt -----BEGIN CERTIFICATE----- MIIF1DCCA7ygAwIBAgIUdK2Ao2/45jYdQP0q6Dr1/ULmnc8wDQYJKoZIhvcNAQEL xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx HhrV5ezjYHY= -----END CERTIFICATE-----
XML-formatet for en curl add-kommando:
# cat cert.xml | xmllint --format - <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <trusted_certificate_changes> <add> <certificate>-----BEGIN CERTIFICATE----- MIIG2TCCBMGgAwIBAgITMQAAAATxxxxxxxxxxxxxxxxxxxxxxxxxhkiG9w0BAQsF ADBbMRIwEAYKCZImiZPyLGQBGRYxxxxxxxxxxxxxxxxxxxxxxxxxFgR2aXRjMRMw ....................... pkHgxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxzxhlGh2TaTC xqz4T/sO4ggWs0Yz5nBmCZMDn6nxxxxxxrjX+ahXI= -----END CERTIFICATE-----</certificate> <certificate>-----BEGIN CERTIFICATE----- MIIG2TCCBMGgAwIBAgxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxqhkiG9w0BAQsF ADBbMRIwEAYKCZImiZxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxZFgR2aXRjMRMw EQYKCZImiZPyLGQBGRxxxxxxxxxxxxxxxxxxxxxxxxxxRW50ZXJwcmlzZS1DQTAe Fw0yMDA2MDgwNzQwxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxIiMA0GCSqGSIb3DQEB .......................... 8wYIKWr2AqSKKxcBHxxxxxxxxxxxxxxxxxxxxxxxxxxxxx3ykeRMZJk7VpQDQDLN feFI4rHZ4JOqDWttiHxxxxxxxxxxxxxxxxxxxxxxxxxxxhpXsxyjQIRvrtaCZVXz GR7Na7Ah1o+9MWenMExxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxGQlsQ47nZE2YgV -----END CERTIFICATE-----</certificate> </add> </trusted_certificate_changes>
Upload xml-formatet til cert-data:
curl -i -s -k -X PUT -H Content-Type:application/xml -H "$TOKEN" -H ACCEPT:application/xml https://10.xxx.xxx.21:4443/vdc/truststore --data-binary @cert.xml
For at kontrollere, at certifikatet er blevet uploadet, skal du køre GET-kommandoen, slutlinjetegnet i ECS truststore er " ."
# curl -s -k -X GET -H Content-Type:application/xml -H "$TOKEN" -H ACCEPT:application/xml https://10.xxx.xxx.21:4443/vdc/truststore | xmllint --format - <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <trusted_certificates> <certificate>-----BEGIN CERTIFICATE----- MIIG2TCCBMGgAwIBAgITMQAAAATxxxxxxxxxxxxxxxxxxxxxxxxxhkiG9w0BAQsF ADBbMRIwEAYKCZImiZPyLGQBGRYxxxxxxxxxxxxxxxxxxxxxxxxxFgR2aXRjMRMw ....................... pkHgxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxzxhlGh2TaTC xqz4T/sO4ggWs0Yz5nBmCZMDn6nxxxxxxrjX+ahXI= -----END CERTIFICATE-----</certificate> <certificate>-----BEGIN CERTIFICATE----- MIIG2TCCBMGgAwIBAgxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxqhkiG9w0BAQsF ADBbMRIwEAYKCZImiZxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxZFgR2aXRjMRMw EQYKCZImiZPyLGQBGRxxxxxxxxxxxxxxxxxxxxxxxxxxRW50ZXJwcmlzZS1DQTAe Fw0yMDA2MDgwNzQwxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxIiMA0GCSqGSIb3DQEB .......................... 8wYIKWr2AqSKKxcBHxxxxxxxxxxxxxxxxxxxxxxxxxxxxx3ykeRMZJk7VpQDQDLN feFI4rHZ4JOqDWttiHxxxxxxxxxxxxxxxxxxxxxxxxxxxhpXsxyjQIRvrtaCZVXz GR7Na7Ah1o+9MWenMExxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxGQlsQ47nZE2YgV -----END CERTIFICATE-----</certificate> </trusted_certificates>
For at kontrollere, at LDAPS-indstillingerne ikke er vendt tilbage, skal du køre kommandoen curl GET:
# curl -s -k -X GET -H Content-Type:application/xml -H "$TOKEN" -H ACCEPT:application/xml https://10.xxx.xxx.21:4443/vdc/truststore/settings | xmllint --format - <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <truststore_settings> <accept_all_certificates>false</accept_all_certificates> </truststore_settings>
Hvis det vendte tilbage til falsk, skal du sætte det tilbage til sandt,
Som når der er en ændring i truststore, kan indstillingen indstille sig til "falsk".
Kør en curl-kommando med en xml-fil som nyttelast med en curl PUT-kommando:
# curl -s -k -X PUT -H Content-Type:application/xml -H "$TOKEN" -H ACCEPT:application/xml https://<NodeManagementIP>:4443/vdc/truststore/settings --data-binary @truststoresettings.xml
Du kontrollerer LDAPS-indstillingerne på følgende måde:
# curl -s -k -X GET -H Content-Type:application/xml -H "$TOKEN" -H ACCEPT:application/xml https://10.xxx.xxx.21:4443/vdc/truststore/settings | xmllint --format - <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <truststore_settings> <accept_all_certificates>true</accept_all_certificates> </truststore_settings>
4. Brug LDAPS på siden ECS-godkendelsesudbyder med FQDN i stedet for en IP-adresse.
Med LDAPS-certifikatkæden uploadet til ECS truststore og accept_all_certificates flag indstillet til sand, gå til siden ECS UI-godkendelsesudbyder, og skift serverens URL-adresse fra.
< ldap://Domænecontroller IP eller FQDN>
Til
ldaps://< Domænecontroller FQDN>
Det vil sige:
FQDN med LDAPS-protokollen
Det skal være et FQDN til LDAPS-brug.
Et FQDN er nødvendigt i stedet for en IP-adresse som:
"Med SSL-certifikater skal certifikatet have et Subject Alternate Name (SAN) i certifikatet for at matche den forbindelse, der oprettes forbindelse til, SAN præsenteres kun med et DNS-navn, der matcher konfigurationen på ECS."
Bekræft derfor, at siden ECS-godkendelsesudbyder, serverens URL-dialogboks, bruger et FQDN i stedet for en IP-adresse.
Det vil sige:
ldaps://fqdn-domain-of-the-ad-or-ldap-server.com
Porte:
Standardporten til LDAP er 389.
Standardporten til LDAPS er 636.
URL-format, hvis ikke-standardport:
< ldap://Domænecontroller IP eller FQDN>:<port> eller ldaps://< domænecontroller FQDN>:<port>
5. Test domænets brugerlogin.
Test derefter domænebrugerens log ind, mens LDAPS-protokollen, om domænebrugerne kan logge ind med LDAPS.
Derfor fungerer ECS-LDAPS-protokolforbindelsen.
Andre oplysninger:
Hvis nødvendigt:
Hvis du vil fjerne et certifikat fra truststore, skal du oprette en xml-fil, der svarer til det certifikat, der skal fjernes, men i stedet for
"add" som nyttelast, skal du bruge "remove":
# cat cert_remove.xml | xmllint --format - <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <trusted_certificate_changes> <remove> <certificate>-----BEGIN CERTIFICATE----- MIIG2TCCBMGgAwIBAgITMQAAAATxxxxxxxxxxxxxxxxxxxxxxxxxhkiG9w0BAQsF ADBbMRIwEAYKCZImiZPyLGQBGRYxxxxxxxxxxxxxxxxxxxxxxxxxFgR2aXRjMRMw ....................... pkHgxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxzxhlGh2TaTC xqz4T/sO4ggWs0Yz5nBmCZMDn6nxxxxxxrjX+ahXI= -----END CERTIFICATE-----</certificate> <certificate>-----BEGIN CERTIFICATE----- MIIG2TCCBMGgAwIBAgxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxqhkiG9w0BAQsF ADBbMRIwEAYKCZImiZxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxZFgR2aXRjMRMw EQYKCZImiZPyLGQBGRxxxxxxxxxxxxxxxxxxxxxxxxxxRW50ZXJwcmlzZS1DQTAe Fw0yMDA2MDgwNzQwxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxIiMA0GCSqGSIb3DQEB .......................... 8wYIKWr2AqSKKxcBHxxxxxxxxxxxxxxxxxxxxxxxxxxxxx3ykeRMZJk7VpQDQDLN feFI4rHZ4JOqDWttiHxxxxxxxxxxxxxxxxxxxxxxxxxxxhpXsxyjQIRvrtaCZVXz GR7Na7Ah1o+9MWenMExxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxGQlsQ47nZE2YgV -----END CERTIFICATE-----</certificate> </remove> </trusted_certificate_changes>
Hvis du vil bruge datafilen, dvs. tilføje eller fjerne, skal du bruge denne kommando:
# curl -s -k -X PUT -H Content-Type:application/xml-H "$TOKEN" -H ACCEPT:application/xml https://10.xxx.xxx.21:4443/vdc/truststore --data-binary @cert_remove.xml
For at kontrollere, om dataene lykkedes, skal du køre kommandoen GET:
# curl -s -k -X GET -H Content-Type:application/xml -H "$TOKEN" -H ACCEPT:application/xml https://10.xxx.xxx.21:4443/vdc/truststore | xmllint --format - <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <trusted_certificates/>
Hvis du ikke er sikker på, om LDAPS-serveren ikke stemmer overens med det medfølgende certifikat, skal du køre følgende kommando for at kontrollere det forventede svar fra LDAPS-serverens anmodning om et matchende certifikat.
"verify error:num=21:unable to verify the first certificate".
I dette eksempel er LDAPS-serveren et selvsigneret certifikat i stedet for et tredjepartscertifikat, så det kan generere en ekstra advarsel om, at den er selvsigneret:
# sudo openssl s_client -connect LDAPS_server_IP:636 < /dev/null
CONNECTED(00000003)
depth=0 CN =
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN =
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
........
---
Server certificate
-----BEGIN CERTIFICATE-----
.......
A cert that it expects.
.......
-----END CERTIFICATE-----
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1
Peer signing digest: SHA1
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2223 bytes and written 487 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
.......................
SRP username: None
Start Time: 1610452553
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
DONE
Kontroller certifikatfilen, der opretter forbindelse til LDAPS-serveren, og om der er et matchende certifikat, der skal bruges, det vil sige Bekræft returkode: 0 (OK):
# openssl s_client -connect LDAPS_server_IP:636 -CAfile /home/admin/cert_file_to_be_used.crt
CONNECTED(00000003)
.......
---
Server certificate
-----BEGIN CERTIFICATE-----
.....
.....
-----END CERTIFICATE-----
.......
---
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1
Peer signing digest: SHA1
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2223 bytes and written 487 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
.........
Verify return code: 0 (ok)
---
For at kontrollere dette skal du bruge denne kommando:
# cat /home/admin/cert.crt | openssl x509 -dates -noout notBefore=Jan 12 13:43:52 2021 GMT notAfter=Jan 12 13:43:52 2022 GMT
JSON-version af kommandoeksemplet.
Hvis du ikke bruger ovenstående XML-kommandoer (bemærk, XML foretrækkes):
curl -s -k -X GET -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://<NodeManagementIP>:4443/vdc/truststore/settings
curl -s -k -X GET -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://10.xxx.xxx.21:4443/vdc/truststore/settings
{"accept_all_certificates":false}
Sådan opretter du en JSON-fil for at ændre truststore-indstillingerne ved hjælp af en curl-kommando med JSON-data:
# sudo vi truststoresettings.json
# sudo cat truststoresettings.json
{"accept_all_certificates": "true"}
json.tool-modulet på python kan validere et JSON-filformat. Hvis der er en fejl i, at filen muligvis ikke er en JSON-fil. I dette eksempel er der ingen fejl og outputter filen, så det er en formateret JSON-fil:
# python -m json.tool truststoresettings.json
{
"accept_all_certificates": "true"
}
Kør en curl-kommando med en JSON-fil som nyttelast med en curl PUT-kommando:
# curl -s -k -X PUT -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://<NodeManagementIP>:4443/vdc/truststore/settings -d @truststoresettings.json
XML-nyttelast PUT bruger --data-binary i curl-kommandoen, mens JSON-nyttelasten PUT bruger
-d I curl-kommandoen:
--data-binary
(HTTP) Dette sender data nøjagtigt som angivet uden ekstra behandling:--data-ascii aka -d
(HTTP) Dette er et alias for -d, --data.
For at kontrollere, at den er opdateret, skal du køre kommandoen curl GET:
# curl -s -k -X GET -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://10.xxx.xxx.21:4443/vdc/truststore/settings
{"accept_all_certificates":true}
Test domænebrugerens login på ECS-brugergrænsefladen med LDAPS-certifikater, der nu er tilladt.
Sådan undersøger du truststore:
# curl -s -k -X GET -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://<NodeManagementIP>:4443/vdc/truststore
Eksempel på et tomt LDAP-certifikat truststore:
# curl -s -k -X GET -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://10.xxx.xxx.xxx.21:4443/vdc/truststore
{"certificate":[]}
JSON-formatet for en curl add-kommando, en enkeltlinjefil med nye linjetegn erstattet med \n og \r\n:
{"add":["-----BEGIN CERTIFICATE-----\nxxxxx\r\n---END CERTIFICATE-----"]}
# cat cert.json
{"add":["-----BEGIN CERTIFICATE-----\nMIIF1DCCA7ygAwIBAgIUdK2Ao2/45jYdQP0q6Dr1/ULmnc8wDQYJKoZIhvcNAQEL\r\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nHhrV5ezjYHY=\r\n---END CERTIFICATE-----"]}
Se ECS-administrationsvejledningen "Tilføj tilpasset LDAP-certifikat". Brug denne kommando til at tilføje eller fjerne:
# curl -s -k -X PUT -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://10.xxx.xxx.21:4443/vdc/truststore -d @cert.json
Sådan kontrollerer du overførslen:
# curl -s -k -X GET -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://10.xxx.xxx.xxx.21:4443/vdc/truststore
{"certificate":["-----BEGIN CERTIFICATE-----\nMIIF1DCCA7ygAwIBAgIUdK2Ao2/45jYdQP0q6Dr1/ULmnc8wDQYJKoZIhvcNAQEL\r\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nHhrV5ezjYHY=\r\n---END CERTIFICATE-----"]}
For at kontrollere, at LDAPS-indstillingerne ikke er vendt tilbage, skal du køre kommandoen curl GET:
# curl -s -k -X GET -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://10.xxx.xxx.21:4443/vdc/truststore/settings
{"accept_all_certificates":false}
Hvis det vendte tilbage til falsk, skal du sætte det tilbage til sand. Når der er en ændring i truststore, kan indstillingen indstille sig selv til "falsk".
Kør en curl-kommando med en JSON-fil som nyttelast med en curl PUT-kommando:
# curl -s -k -X PUT -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://<NodeManagementIP>:4443/vdc/truststore/settings -d @truststoresettings.json
Du kontrollerer LDAPS-indstillingerne på følgende måde:
# curl -s -k -X GET -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://10.xxx.xxx.21:4443/vdc/truststore/settings
{"accept_all_certificates":true}
Hvis du vil fjerne et certifikat fra truststore, skal du oprette en JSON-fil, der matcher det certifikat, der skal fjernes, men i stedet for at "tilføje" som data skal du bruge "remove":
# cat cert.json
{"remove":["-----BEGIN CERTIFICATE-----\nMIIF1DCCA7ygAwIBAgIUdK2Ao2/45jYdQP0q6Dr1/ULmnc8wDQYJKoZIhvcNAQEL\r\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nHhrV5ezjYHY=\r\n---END CERTIFICATE-----"]}
Brug denne kommando til at tilføje eller fjerne:
# curl -s -k -X PUT -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://10.xxx.xxx.21:4443/vdc/truststore -d @cert.json
Sådan kontrollerer du overførslen:
# curl -s -k -X GET -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://10.xxx.xxx.xxx.21:4443/vdc/truststore
{"certificate":[]}