Il servizio systemd raggiunge il proxy, ma non il file CA
Controlla l’accesso ai file dell’utente del servizio e i vincoli systemd quando la configurazione del certificato proxy funziona solo nella shell interattiva.
Hai installato il bundle CA approvato e la richiesta funziona nel terminale. Il servizio segnala ancora un errore di caricamento del certificato. Prima di cambiare l’IP del proxy, verifica se quel processo riesce ad aprire lo stesso file.
Un servizio può girare con un altro utente Unix, partire da un’altra directory o vedere un filesystem limitato. Un percorso valido per il tuo accesso non lo è automaticamente per lui.
Parti da un percorso assoluto
Controlla il percorso impostato nel client effettivo. In curl, per esempio, --cacert sceglie il bundle CA della destinazione; un proxy HTTPS ha opzioni CA proxy separate. Gli altri client usano le proprie chiavi di configurazione o variabili d’ambiente.
Esamina il file e le directory che portano a esso:
namei -l /home/alex/certs/approved-ca.pem
systemctl show example.service -p User -p Group -p ProtectHome -p RootDirectory
Sono esempi diagnostici, non istruzioni per rendere il file scrivibile da chiunque. I permessi di attraversamento delle directory contano quanto la lettura del file finale.
I permessi potrebbero non essere tutto il problema
Con ProtectHome=yes, systemd rende inaccessibili al servizio le posizioni standard delle directory personali. Cambiare il modo del file di certificato non elimina il vincolo del namespace. Una directory radice configurata può anche cambiare a cosa si riferisce un percorso assoluto all’interno del servizio.
Usa una posizione di configurazione adatta al servizio, come una directory sotto /etc prevista per l’applicazione, e concedi solo la lettura necessaria. Aggiorna il percorso CA del client. Non togliere altri vincoli del filesystem solo perché la prima copia era nella tua home personale.
Leggi il primo errore utile
«Impossibile caricare il file CA» e «catena di certificati non attendibile» sono errori diversi. Il primo può avvenire prima di qualsiasi verifica. Il secondo può indicare che il bundle leggibile contiene l’autorità sbagliata o viene applicato alla connessione TLS sbagliata.
Dopo aver corretto l’accesso, riprova nel contesto del servizio. Un comando riuscito nel terminale resta un confronto utile, ma non dimostra quali file vede il servizio né quale configurazione di fiducia usa il suo client.