Handling changes to ca-certificates correctly

cfr · 2014-12-11 13:29:22

I am aware of the ca-certificates-update news item but had a query about implementing step 2. I tried reading the suggested man page but, unfortunately, that seems to describe the old configuration rather than the new one.

Step 2 says

Do the same with all manually-added /etc/ssl/certs/*.pem files and rename them to *.crt

I was not sure which files, if any, were manually added so I moved all *.pem files, renaming them to *.crt. Was this the right thing to do?

I have a bunch of files remaining in /etc/ssl/certs/, including some *.crt files. However, the instructions did not mention moving these so I left them alone and just ran trust extract-compat.

Could somebody confirm if this was correct or, if not, what changes I should make? Alternatively, if an updated version of the manual page would answer these questions, information about where to find that instead would be great.

KlipperKyle · 2014-12-11 15:28:59

I also have a bunch of *.pem certificates in /etc/ssl/certs/, but all of their timestamps are the moment I ran pacman -Syu. (Huh?)

Is this a side effect of replacing ca-certificates-java with ca-certificates-utils? What should I do? Move them into /etc/ca-certificates/trust-source/anchors/?

$ la /etc/ssl/certs/*.pem
-r--r--r-- 1 root root 2849 Dec 11 07:13 /etc/ssl/certs/ACCVRAIZ1.pem
-r--r--r-- 1 root root 2122 Dec 11 07:13 /etc/ssl/certs/ACEDICOM_Root.pem
-r--r--r-- 1 root root 2382 Dec 11 07:13 /etc/ssl/certs/AC_Ra_xC3_xADz_Certic_xC3_xA1mara_S.A..pem
-r--r--r-- 1 root root 2138 Dec 11 07:13 /etc/ssl/certs/Actalis_Authentication_Root_CA.pem
-r--r--r-- 1 root root 1614 Dec 11 07:13 /etc/ssl/certs/AddTrust_External_Root.pem
-r--r--r-- 1 root root 1574 Dec 11 07:13 /etc/ssl/certs/AddTrust_Low-Value_Services_Root.pem
-r--r--r-- 1 root root 1582 Dec 11 07:13 /etc/ssl/certs/AddTrust_Public_Services_Root.pem
-r--r--r-- 1 root root 1602 Dec 11 07:13 /etc/ssl/certs/AddTrust_Qualified_Certificates_Root.pem
-r--r--r-- 1 root root 1273 Dec 11 07:13 /etc/ssl/certs/AffirmTrust_Commercial.pem
-r--r--r-- 1 root root 1273 Dec 11 07:13 /etc/ssl/certs/AffirmTrust_Networking.pem
-r--r--r-- 1 root root  822 Dec 11 07:13 /etc/ssl/certs/AffirmTrust_Premium_ECC.pem
-r--r--r-- 1 root root 1951 Dec 11 07:13 /etc/ssl/certs/AffirmTrust_Premium.pem
-r--r--r-- 1 root root 1448 Dec 11 07:13 /etc/ssl/certs/America_Online_Root_Certification_Authority_1.pem
-r--r--r-- 1 root root 2142 Dec 11 07:13 /etc/ssl/certs/America_Online_Root_Certification_Authority_2.pem
-r--r--r-- 1 root root 1415 Dec 11 07:13 /etc/ssl/certs/ApplicationCA_-_Japanese_Government.pem
-r--r--r-- 1 root root 1354 Dec 11 07:13 /etc/ssl/certs/Atos_TrustedRoot_2011.pem
-r--r--r-- 1 root root 1440 Dec 11 07:13 /etc/ssl/certs/A-Trust-nQual-03.pem
-r--r--r-- 1 root root 2309 Dec 11 07:13 /etc/ssl/certs/Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.pem
-r--r--r-- 1 root root 1346 Dec 11 07:13 /etc/ssl/certs/Baltimore_CyberTrust_Root.pem
<snip>

Update: It seems that these certificates used to be part of the ca-certificates-mozilla package (when they were in /usr/share/ca-certificates/mozilla/), but now, they aren't part of any package. Does this mean that Arch Linux is officially dropping these certificates entirely?

And their timestamps just changed to 07:30. I don't know why.

Update 2: The timestamps of the certificates were changed when I reinstalled ca-certificates-mozilla. I guess they are extracted during install. (?) Could someone please provide more info as to what changed during this update?

Last edited by KlipperKyle (2014-12-11 16:05:24)

bmanuel · 2014-12-11 16:05:05

I'm in the same boat: i never added certificates in there, and all .pem files there aren't owned by any package:

$ pacaur -Qo /etc/ssl/certs/*.pem
error: No package owns /etc/ssl/certs/ACCVRAIZ1.pem
error: No package owns /etc/ssl/certs/ACEDICOM_Root.pem
error: No package owns /etc/ssl/certs/AC_Ra_xC3_xADz_Certic_xC3_xA1mara_S.A..pem
error: No package owns /etc/ssl/certs/Actalis_Authentication_Root_CA.pem
error: No package owns /etc/ssl/certs/AddTrust_External_Root.pem
error: No package owns /etc/ssl/certs/AddTrust_Low-Value_Services_Root.pem
error: No package owns /etc/ssl/certs/AddTrust_Public_Services_Root.pem
error: No package owns /etc/ssl/certs/AddTrust_Qualified_Certificates_Root.pem
error: No package owns /etc/ssl/certs/AffirmTrust_Commercial.pem
error: No package owns /etc/ssl/certs/AffirmTrust_Networking.pem
error: No package owns /etc/ssl/certs/AffirmTrust_Premium_ECC.pem
error: No package owns /etc/ssl/certs/AffirmTrust_Premium.pem
error: No package owns /etc/ssl/certs/America_Online_Root_Certification_Authority_1.pem
error: No package owns /etc/ssl/certs/America_Online_Root_Certification_Authority_2.pem
error: No package owns /etc/ssl/certs/ApplicationCA_-_Japanese_Government.pem
error: No package owns /etc/ssl/certs/Atos_TrustedRoot_2011.pem
error: No package owns /etc/ssl/certs/A-Trust-nQual-03.pem
error: No package owns /etc/ssl/certs/Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.pem
error: No package owns /etc/ssl/certs/Baltimore_CyberTrust_Root.pem
error: No package owns /etc/ssl/certs/Bogus_Global_Trustee.pem
error: No package owns /etc/ssl/certs/Bogus_GMail.pem
error: No package owns /etc/ssl/certs/Bogus_Google.pem
error: No package owns /etc/ssl/certs/Bogus_live.com.pem
error: No package owns /etc/ssl/certs/Bogus_Mozilla_Addons.pem
error: No package owns /etc/ssl/certs/Bogus_Skype.pem
error: No package owns /etc/ssl/certs/Bogus_Yahoo_1.pem
error: No package owns /etc/ssl/certs/Bogus_Yahoo_2.pem
error: No package owns /etc/ssl/certs/Bogus_Yahoo_3.pem
error: No package owns /etc/ssl/certs/Buypass_Class_2_CA_1.pem
error: No package owns /etc/ssl/certs/Buypass_Class_2_Root_CA.pem
error: No package owns /etc/ssl/certs/Buypass_Class_3_CA_1.pem
error: No package owns /etc/ssl/certs/Buypass_Class_3_Root_CA.pem
error: No package owns /etc/ssl/certs/CAcert_Class_3_Root.pem
error: No package owns /etc/ssl/certs/CA_Cert_Signing_Authority.pem
error: No package owns /etc/ssl/certs/CA_Disig.pem
error: No package owns /etc/ssl/certs/CA_Disig_Root_R1.pem
error: No package owns /etc/ssl/certs/CA_Disig_Root_R2.pem
error: No package owns /etc/ssl/certs/Camerfirma_Chambers_of_Commerce_Root.pem
error: No package owns /etc/ssl/certs/Camerfirma_Global_Chambersign_Root.pem
error: No package owns /etc/ssl/certs/Certigna.pem
error: No package owns /etc/ssl/certs/Certinomis_-_Autorit___Racine.pem
error: No package owns /etc/ssl/certs/Certplus_Class_2_Primary_CA.pem
error: No package owns /etc/ssl/certs/certSIGN_ROOT_CA.pem
error: No package owns /etc/ssl/certs/Certum_Root_CA.pem
error: No package owns /etc/ssl/certs/Certum_Trusted_Network_CA.pem
error: No package owns /etc/ssl/certs/Chambers_of_Commerce_Root_-_2008.pem
error: No package owns /etc/ssl/certs/China_Internet_Network_Information_Center_EV_Certificates_Root.pem
error: No package owns /etc/ssl/certs/CNNIC_ROOT.pem
error: No package owns /etc/ssl/certs/Comodo_AAA_Services_root.pem
error: No package owns /etc/ssl/certs/COMODO_Certification_Authority.pem
error: No package owns /etc/ssl/certs/COMODO_ECC_Certification_Authority.pem
error: No package owns /etc/ssl/certs/COMODO_RSA_Certification_Authority.pem
error: No package owns /etc/ssl/certs/Comodo_Secure_Services_root.pem
error: No package owns /etc/ssl/certs/Comodo_Trusted_Services_root.pem
error: No package owns /etc/ssl/certs/ComSign_CA.pem
error: No package owns /etc/ssl/certs/ComSign_Secured_CA.pem
error: No package owns /etc/ssl/certs/Cybertrust_Global_Root.pem
error: No package owns /etc/ssl/certs/Deutsche_Telekom_Root_CA_2.pem
error: No package owns /etc/ssl/certs/DigiCert_Assured_ID_Root_CA.pem
error: No package owns /etc/ssl/certs/DigiCert_Assured_ID_Root_G2.pem
error: No package owns /etc/ssl/certs/DigiCert_Assured_ID_Root_G3.pem
error: No package owns /etc/ssl/certs/DigiCert_Global_Root_CA.pem
error: No package owns /etc/ssl/certs/DigiCert_Global_Root_G2.pem
error: No package owns /etc/ssl/certs/DigiCert_Global_Root_G3.pem
error: No package owns /etc/ssl/certs/DigiCert_High_Assurance_EV_Root_CA.pem
error: No package owns /etc/ssl/certs/DigiCert_Trusted_Root_G4.pem
error: No package owns /etc/ssl/certs/Digital_Signature_Trust_Co._Global_CA_1.pem
error: No package owns /etc/ssl/certs/Digital_Signature_Trust_Co._Global_CA_3.pem
error: No package owns /etc/ssl/certs/DST_ACES_CA_X6.pem
error: No package owns /etc/ssl/certs/DST_Root_CA_X3.pem
error: No package owns /etc/ssl/certs/D-TRUST_Root_Class_3_CA_2_2009.pem
error: No package owns /etc/ssl/certs/D-TRUST_Root_Class_3_CA_2_EV_2009.pem
error: No package owns /etc/ssl/certs/EBG_Elektronik_Sertifika_Hizmet_Sa_xC4_x9Flay_xc4_xb1_x63_xc4_xb1s_xc4_xb1.pem
error: No package owns /etc/ssl/certs/EC-ACC.pem
error: No package owns /etc/ssl/certs/EE_Certification_Centre_Root_CA.pem
error: No package owns /etc/ssl/certs/E-Guven_Kok_Elektronik_Sertifika_Hizmet_Saglayicisi.pem
error: No package owns /etc/ssl/certs/Entrust.net_Premium_2048_Secure_Server_CA.pem
error: No package owns /etc/ssl/certs/Entrust.net_Secure_Server_CA.pem
error: No package owns /etc/ssl/certs/Entrust_Root_Certification_Authority.pem
error: No package owns /etc/ssl/certs/ePKI_Root_Certification_Authority.pem
error: No package owns /etc/ssl/certs/Equifax_Secure_CA.pem
error: No package owns /etc/ssl/certs/Equifax_Secure_eBusiness_CA_1.pem
error: No package owns /etc/ssl/certs/Equifax_Secure_Global_eBusiness_CA.pem
error: No package owns /etc/ssl/certs/E-Tugra_Certification_Authority.pem
error: No package owns /etc/ssl/certs/Explicitly_Distrust_DigiNotar_Cyber_CA_2nd.pem
error: No package owns /etc/ssl/certs/Explicitly_Distrust_DigiNotar_Cyber_CA.pem
error: No package owns /etc/ssl/certs/Explicitly_Distrust_DigiNotar_Root_CA.pem
error: No package owns /etc/ssl/certs/Explicitly_Distrust_DigiNotar_Services_1024_CA.pem
error: No package owns /etc/ssl/certs/Explicitly_Distrusted_DigiNotar_PKIoverheid_G2.pem
error: No package owns /etc/ssl/certs/Explicitly_Distrusted_DigiNotar_PKIoverheid.pem
error: No package owns /etc/ssl/certs/Explicitly_Distrusted_Malaysian_Digicert_Sdn._Bhd.__cyb_.pem
error: No package owns /etc/ssl/certs/Explicitly_Distrusted_Malaysian_Digicert_Sdn._Bhd.__en_.pem
error: No package owns /etc/ssl/certs/GeoTrust_Global_CA_2.pem
error: No package owns /etc/ssl/certs/GeoTrust_Global_CA.pem
error: No package owns /etc/ssl/certs/GeoTrust_Primary_Certification_Authority_-_G2.pem
error: No package owns /etc/ssl/certs/GeoTrust_Primary_Certification_Authority_-_G3.pem
error: No package owns /etc/ssl/certs/GeoTrust_Primary_Certification_Authority.pem
error: No package owns /etc/ssl/certs/GeoTrust_Universal_CA_2.pem
error: No package owns /etc/ssl/certs/GeoTrust_Universal_CA.pem
error: No package owns /etc/ssl/certs/Global_Chambersign_Root_-_2008.pem
error: No package owns /etc/ssl/certs/GlobalSign_ECC_Root_CA_-_R4.pem
error: No package owns /etc/ssl/certs/GlobalSign_ECC_Root_CA_-_R5.pem
error: No package owns /etc/ssl/certs/GlobalSign_Root_CA.pem
error: No package owns /etc/ssl/certs/GlobalSign_Root_CA_-_R2.pem
error: No package owns /etc/ssl/certs/GlobalSign_Root_CA_-_R3.pem
error: No package owns /etc/ssl/certs/Go_Daddy_Class_2_CA.pem
error: No package owns /etc/ssl/certs/Go_Daddy_Root_Certificate_Authority_-_G2.pem
error: No package owns /etc/ssl/certs/GTE_CyberTrust_Global_Root.pem
error: No package owns /etc/ssl/certs/Hellenic_Academic_and_Research_Institutions_RootCA_2011.pem
error: No package owns /etc/ssl/certs/Hongkong_Post_Root_CA_1.pem
error: No package owns /etc/ssl/certs/IGC_A.pem
error: No package owns /etc/ssl/certs/Izenpe.com.pem
error: No package owns /etc/ssl/certs/Juur-SK.pem
error: No package owns /etc/ssl/certs/MD5_Collisions_Forged_Rogue_CA_25c3.pem
error: No package owns /etc/ssl/certs/Microsec_e-Szigno_Root_CA_2009.pem
error: No package owns /etc/ssl/certs/Microsec_e-Szigno_Root_CA.pem
error: No package owns /etc/ssl/certs/NetLock_Arany__Class_Gold__F__tan__s__tv__ny.pem
error: No package owns /etc/ssl/certs/NetLock_Business__Class_B__Root.pem
error: No package owns /etc/ssl/certs/NetLock_Express__Class_C__Root.pem
error: No package owns /etc/ssl/certs/NetLock_Notary__Class_A__Root.pem
error: No package owns /etc/ssl/certs/NetLock_Qualified__Class_QA__Root.pem
error: No package owns /etc/ssl/certs/Network_Solutions_Certificate_Authority.pem
error: No package owns /etc/ssl/certs/OISTE_WISeKey_Global_Root_GA_CA.pem
error: No package owns /etc/ssl/certs/PSCProcert.pem
error: No package owns /etc/ssl/certs/QuoVadis_Root_CA_1_G3.pem
error: No package owns /etc/ssl/certs/QuoVadis_Root_CA_2_G3.pem
error: No package owns /etc/ssl/certs/QuoVadis_Root_CA_2.pem
error: No package owns /etc/ssl/certs/QuoVadis_Root_CA_3_G3.pem
error: No package owns /etc/ssl/certs/QuoVadis_Root_CA_3.pem
error: No package owns /etc/ssl/certs/QuoVadis_Root_CA.pem
error: No package owns /etc/ssl/certs/Root_CA_Generalitat_Valenciana.pem
error: No package owns /etc/ssl/certs/RSA_Root_Certificate_1.pem
error: No package owns /etc/ssl/certs/RSA_Security_2048_v3.pem
error: No package owns /etc/ssl/certs/Secure_Global_CA.pem
error: No package owns /etc/ssl/certs/SecureSign_RootCA11.pem
error: No package owns /etc/ssl/certs/SecureTrust_CA.pem
error: No package owns /etc/ssl/certs/Security_Communication_EV_RootCA1.pem
error: No package owns /etc/ssl/certs/Security_Communication_RootCA2.pem
error: No package owns /etc/ssl/certs/Security_Communication_Root_CA.pem
error: No package owns /etc/ssl/certs/SG_TRUST_SERVICES_RACINE.pem
error: No package owns /etc/ssl/certs/Sonera_Class_1_Root_CA.pem
error: No package owns /etc/ssl/certs/Sonera_Class_2_Root_CA.pem
error: No package owns /etc/ssl/certs/Staat_der_Nederlanden_Root_CA_-_G2.pem
error: No package owns /etc/ssl/certs/Staat_der_Nederlanden_Root_CA.pem
error: No package owns /etc/ssl/certs/Starfield_Class_2_CA.pem
error: No package owns /etc/ssl/certs/Starfield_Root_Certificate_Authority_-_G2.pem
error: No package owns /etc/ssl/certs/Starfield_Services_Root_Certificate_Authority_-_G2.pem
error: No package owns /etc/ssl/certs/StartCom_Certification_Authority.1.pem
error: No package owns /etc/ssl/certs/StartCom_Certification_Authority_G2.pem
error: No package owns /etc/ssl/certs/StartCom_Certification_Authority.pem
error: No package owns /etc/ssl/certs/S-TRUST_Authentication_and_Encryption_Root_CA_2005_PN.pem
error: No package owns /etc/ssl/certs/Swisscom_Root_CA_1.pem
error: No package owns /etc/ssl/certs/Swisscom_Root_CA_2.pem
error: No package owns /etc/ssl/certs/Swisscom_Root_EV_CA_2.pem
error: No package owns /etc/ssl/certs/SwissSign_Gold_CA_-_G2.pem
error: No package owns /etc/ssl/certs/SwissSign_Platinum_CA_-_G2.pem
error: No package owns /etc/ssl/certs/SwissSign_Silver_CA_-_G2.pem
error: No package owns /etc/ssl/certs/Taiwan_GRCA.pem
error: No package owns /etc/ssl/certs/TC_TrustCenter_Class_2_CA_II.pem
error: No package owns /etc/ssl/certs/TC_TrustCenter_Class_3_CA_II.pem
error: No package owns /etc/ssl/certs/TC_TrustCenter_Universal_CA_III.pem
error: No package owns /etc/ssl/certs/TC_TrustCenter_Universal_CA_I.pem
error: No package owns /etc/ssl/certs/TeliaSonera_Root_CA_v1.pem
error: No package owns /etc/ssl/certs/Thawte_Premium_Server_CA.pem
error: No package owns /etc/ssl/certs/thawte_Primary_Root_CA_-_G2.pem
error: No package owns /etc/ssl/certs/thawte_Primary_Root_CA_-_G3.pem
error: No package owns /etc/ssl/certs/thawte_Primary_Root_CA.pem
error: No package owns /etc/ssl/certs/Thawte_Server_CA.pem
error: No package owns /etc/ssl/certs/Trustis_FPS_Root_CA.pem
error: No package owns /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.pem
error: No package owns /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_3.pem
error: No package owns /etc/ssl/certs/TURKTRUST_Certificate_Services_Provider_Root_1.pem
error: No package owns /etc/ssl/certs/TURKTRUST_Certificate_Services_Provider_Root_2007.pem
error: No package owns /etc/ssl/certs/TURKTRUST_Certificate_Services_Provider_Root_2.pem
error: No package owns /etc/ssl/certs/TWCA_Global_Root_CA.pem
error: No package owns /etc/ssl/certs/TWCA_Root_Certification_Authority.pem
error: No package owns /etc/ssl/certs/T_xc3_x9c_x42_xC4_xB0TAK_UEKAE_K_xC3_xB6k_Sertifika_Hizmet_Sa_xC4_x9Flay_xc4_xb1_x63_xc4_xb1s_xc4_xb1_-_S_xC3_xBCr_xC3_xBCm_3.pem
error: No package owns /etc/ssl/certs/USERTrust_ECC_Certification_Authority.pem
error: No package owns /etc/ssl/certs/USERTrust_Legacy_Secure_Server_CA.pem
error: No package owns /etc/ssl/certs/USERTrust_RSA_Certification_Authority.pem
error: No package owns /etc/ssl/certs/UTN_DATACorp_SGC_Root_CA.pem
error: No package owns /etc/ssl/certs/UTN_USERFirst_Email_Root_CA.pem
error: No package owns /etc/ssl/certs/UTN_USERFirst_Hardware_Root_CA.pem
error: No package owns /etc/ssl/certs/UTN-USERFirst-Network_Applications.pem
error: No package owns /etc/ssl/certs/UTN_USERFirst_Object_Root_CA.pem
error: No package owns /etc/ssl/certs/ValiCert_Class_1_VA.pem
error: No package owns /etc/ssl/certs/ValiCert_Class_2_VA.pem
error: No package owns /etc/ssl/certs/Verisign_Class_1_Public_Primary_Certification_Authority_-_G2.pem
error: No package owns /etc/ssl/certs/Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.pem
error: No package owns /etc/ssl/certs/Verisign_Class_1_Public_Primary_Certification_Authority.pem
error: No package owns /etc/ssl/certs/Verisign_Class_2_Public_Primary_Certification_Authority_-_G2.pem
error: No package owns /etc/ssl/certs/Verisign_Class_2_Public_Primary_Certification_Authority_-_G3.pem
error: No package owns /etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority.1.pem
error: No package owns /etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority_-_G2.pem
error: No package owns /etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority_-_G3.pem
error: No package owns /etc/ssl/certs/VeriSign_Class_3_Public_Primary_Certification_Authority_-_G4.pem
error: No package owns /etc/ssl/certs/VeriSign_Class_3_Public_Primary_Certification_Authority_-_G5.pem
error: No package owns /etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority.pem
error: No package owns /etc/ssl/certs/VeriSign_Class_3_Secure_Server_CA_-_G2.pem
error: No package owns /etc/ssl/certs/Verisign_Class_4_Public_Primary_Certification_Authority_-_G3.pem
error: No package owns /etc/ssl/certs/VeriSign_Universal_Root_Certification_Authority.pem
error: No package owns /etc/ssl/certs/Visa_eCommerce_Root.pem
error: No package owns /etc/ssl/certs/WellsSecure_Public_Root_Certificate_Authority.pem
error: No package owns /etc/ssl/certs/WoSign_China.pem
error: No package owns /etc/ssl/certs/WoSign.pem
error: No package owns /etc/ssl/certs/XRamp_Global_CA_Root.pem

KlipperKyle · 2014-12-11 16:27:28

I just found this mailing list thread a few months back.

https://lists.archlinux.org/pipermail/a … 26586.html

Another problem I have is related to NetworkManager. My school uses WPA2 Enterprise, and I normally select the correct certificate from /usr/share/ca-certificates/mozilla/. However, all of those certs have been moved to /etc/ssl/certs/ with their extension changed from .crt to .pem. For whatever reason, NetworkManager does not like the .pem version of the certificate. I will play around with it later, but any suggestions are welcome.

x_nik2468 · 2014-12-11 16:54:16

I also tried to move all .pem files but I was having problems with pacman, so I cp'd them back. Now I have a bunch of .pem and .crt files in both directories. Very dirty.

Running

trust extract-compat

gives errors about every .crt file, like this:

p11-kit: certificate with distrust in location for anchors: certname.crt

Obviously moving every .pem file was the wrong thing to do.

colegui · 2014-12-11 18:37:28

Hello, I am a little confused about it, I moved the files:

$ cd /etc/ssl/certs/

$ sudo mv *.pem  /etc/ca-certificates/trust-source/anchors/

... after i renamed them to * .crt

Next...:

#trust extract-compat

... and i gives errors about every .crt file:

p11-kit: certificate with distrust in location for anchors: xxxxx.crt

Note: after moving the files .pem to /etc/ca-certificates/trust-source/anchors/, renamed them and execute # trust extract-compat, files return in /etc/etc/ssl/certs/*.pem

I do not know why this happens..

Best Regards

brix · 2014-12-11 18:50:58

As the OP observed,

cfr wrote:

Step 2 says
Do the same with all manually-added /etc/ssl/certs/*.pem files and rename them to *.crt
I was not sure which files, if any, were manually added

A strict interepretation would suggest that if I can't remember manually adding any files to /etc/ssl/certs/ by consciously doing something, likely via the command line, I have no such manually-added files.

Sticking to a narrow interpretation of "manually-added" (not to mention "if you have added any locally trusted certificates"), I've done nothing.

mcloaked · 2014-12-11 19:09:30

I noticed that the item said "The way local CA certificates are handled has changed. " I also noted that most of the files/links in /etc/ssl/certs are not local ( in the sense that I didn't generate them locally)! I only had a single dovecot.pem file there that I had made but I hadn't seen the news item before running the pacman update and after the update my local ssl cert had been removed completely - so it was very lucky that I had a backup copy of the file.

Now in my case I copied the backup file to /etc/ca-certificates/trust-source/anchors/ and changed its name from dovecot.pem to dovecot.crt and then ran trust extract-compat

After rebooting since there was a new kernel today as well I found that the dovecot service had failed - this was due to the wrong file path in the file /etc/dovecot/conf.d/10-ssl.conf - so I edited it to point to the correct new location using the line:

ssl_cert = </etc/ca-certificates/trust-source/anchors/dovecot.crt

and then when I restarted the dovecot service with systemctl restart dovecot then the service started up without error.

So it seems that you do have to be careful to look for followup effects of the certificate change for any config file where the original file path may no longer apply. Also it is important to execute the changes of your own cert files before updating!

By the way I also note that in my case there is a corresponding dovecot file in /etc/ssl/private/ which I left alone but I don't know if that ought to be moved as well? Anyone know the answer to that question? Thanks.

Last edited by mcloaked (2014-12-11 19:41:28)

cfr · 2014-12-11 22:29:54

I basically deleted everything and reinstalled ca-certificates ca-certificates-cacert and ca-certificates-mozilla. And everything seems reasonably happy so far. (At least, no more errors on installing them.)

I don't know that I needed to reinstall all of those packages - I just did them all at once.

I won't mark this thread solved yet as others have outstanding queries about the process, and it seems better to have those answered together with my original question.

Last edited by cfr (2014-12-11 22:31:04)

cfr · 2014-12-11 22:32:45

brix wrote:

As the OP observed,
cfr wrote:
Step 2 says
Do the same with all manually-added /etc/ssl/certs/*.pem files and rename them to *.crt
I was not sure which files, if any, were manually added
A strict interepretation would suggest that if I can't remember manually adding any files to /etc/ssl/certs/ by consciously doing something, likely via the command line, I have no such manually-added files.

The trouble is, I don't count on my memory to be that reliable! Plus I have definitely installed such certificates in the past, and I could not remember if I was currently using such things or not.

irb · 2014-12-12 02:50:31

Is it expected behavior for the "trust list" command to return nothing? Also, running trust extract-compat as directed yields "the placeholder extract-compat command has not been customized by your distribution."

I do have a custom CA cert and a wildcard cert; moving them to the new dir and running "trust extract-compat" gives me, "the placeholder extract-compat command has not been customized by your distribution.". Again, being new to these tools I don't know if this is all the way it's supposed to be, but I suspect not.

Thanks for any help,

irb · 2014-12-12 03:57:18

Ah, figured it out: needed to upgrade p11-kit as well. Didn't due to being new to pacman/Arch and getting stumped by nvidia-dkms causing updates to fail (as it's out of date at the moment).

hcra · 2014-12-12 04:27:23

irb wrote:

Ah, figured it out ….

This is as unhelpful as the Notice about certificate upgrades on the Arch front page.

If someone could please answer the question asked by the OP, many of us would be greatly appreciative.

irb · 2014-12-12 05:22:34

I'm sorry you didn't find my posts helpful. I was trying to keep related questions in one place, instead of creating a new topic.

As far as I can see, yes. The process seems to be:
* Upgrading ca-certificates* and p11-kit
* copying or moving your non-bundled certs to /etc/ca-certificates/trust-source/anchors/
* enaming <file>.pem to <file>.crt in the process, and
* running "trust extract-compat"

Ultimately this worked for me. I *did not* rename the bundled PEM certs. If you did, you can likely recover by removing them and re-installing p11-kit.

I hope that is more helpful.

mcloaked · 2014-12-12 10:36:01

It would seem to me that if you create your own certificates that ( unless I am completely wrong!) there you can in fact put them wherever you like provided the package configs that need them are referred to the certificates via the correct path? The example was my dovecot certs - I have now placed them in /opt/Local/certs/ssl/ for the public one and /opt/Local/certs/private/ for the private one - and then simply changed the path for these in the dovecot ssl config file. Dovecot runs fine with that, and it also then means that any future update to ca-certificates will not impact my private certificates at all.

Presumably if you have certificates for web servers that these could be handled in the analogous way? Maybe someone who has examples could post if that works OK or not?

beardedlinuxgeek · 2014-12-12 12:52:19

None of the Common CAs are suppose to move? Is this just the new standard? Your private certs now live in

/etc/ca-certificates/trust-source/anchors/

and all the common ones live in

/etc/ssl/certs/

fsckd · 2014-12-12 12:59:03

irb wrote:

Ah, figured it out: needed to upgrade p11-kit as well. Didn't due to being new to pacman/Arch and getting stumped by nvidia-dkms causing updates to fail (as it's out of date at the moment).

I strongly suggest not doing partial upgrades.

ratcheer · 2014-12-12 14:30:50

I'm sorry, but I'm not really grasping the problem or the explanations. I don't have any locally installed certificates that I know of, so, I did not take any special action. Was that the wrong thing to do?

Tim

alphaniner · 2014-12-12 15:03:40

@ratcheer

In my case every file and link in /etc/ssl/certs is unowned, so I would probably consider them all locally installed. But the news talks about manually-added files, which is a bit ambiguous IMO. Used loosely, manually-added could mean anything not installed by pacman...

berbae · 2014-12-12 15:40:04

From 'man update-ca-trust':

/etc/ssl/certs
Classic directory, contains individual CA certificates ..., which are created by the update-ca-trust extract command.
Don't edit files in this directory, because they will be overwritten.
See section EXTRACTED CONFIGURATION for additional details.

So it is normal that the files in this directory do not belong to any package: they are created by the 'update-ca-trust' command in the .install file of the ca-certificates-* packages; they are not a physical part of the packages.
If nothing has been added to the ca-certificates packages, there is nothing to do in this directory which is automatically populated from the source configuration files in the directories where they are put by the ca-certificates-* packages:

extract
Instruct update-ca-trust to scan the SOURCE CONFIGURATION and produce updated versions of the
consolidated configuration files stored below the /etc/ssl/certs and /etc/ca-certificates/extracted directory hierarchies.

That's why the manually added ca-certificates files should be moved to a SOURCE CONFIGURATION directory and renamed .crt; the .pem is then generated by the 'update-ca-trust' command and written again in the /etc/ssl/certs directory.
That's what I understand and what I observed in my system.

Edit: fix typo .mem instead of .pem

Last edited by berbae (2014-12-12 15:58:39)

irb · 2014-12-12 18:14:52

fsckd wrote:

irb wrote:
Ah, figured it out: needed to upgrade p11-kit as well. Didn't due to being new to pacman/Arch and getting stumped by nvidia-dkms causing updates to fail (as it's out of date at the moment).
I strongly suggest not doing partial upgrades.

Just to be clear, I completely agree; and that's what caused my issue to begin with. I'm new to Arch and had a dependency problem I've since figured out.

nstgc · 2014-12-12 22:27:39

berbae wrote:

From 'man update-ca-trust':
/etc/ssl/certs
Classic directory, contains individual CA certificates ..., which are created by the update-ca-trust extract command.
Don't edit files in this directory, because they will be overwritten.
See section EXTRACTED CONFIGURATION for additional details.
So it is normal that the files in this directory do not belong to any package: they are created by the 'update-ca-trust' command in the .install file of the ca-certificates-* packages; they are not a physical part of the packages.
If nothing has been added to the ca-certificates packages, there is nothing to do in this directory which is automatically populated from the source configuration files in the directories where they are put by the ca-certificates-* packages:
extract
Instruct update-ca-trust to scan the SOURCE CONFIGURATION and produce updated versions of the
consolidated configuration files stored below the /etc/ssl/certs and /etc/ca-certificates/extracted directory hierarchies.
That's why the manually added ca-certificates files should be moved to a SOURCE CONFIGURATION directory and renamed .crt; the .pem is then generated by the 'update-ca-trust' command and written again in the /etc/ssl/certs directory.
That's what I understand and what I observed in my system.
Edit: fix typo .mem instead of .pem

Does this answer the OP's question or Ratcheer's?

dice · 2014-12-13 10:02:22

I have a similar problem like KlipperKyle in post #4. My university wlan uses the Deutsche_Telekom_Root_CA_2 certificate.
I used the one in /usr/share/ca-certificates/mozilla/ but now it is gone. Instead there is Deutsche_Telekom_Root_CA_2.pem in /etc/ssl/certs but I can't select this one in NetworkManager. Actually there are a lot of files in /etc/ssl/certs but none of them show up in Networkmanager except ca-certificates.crt

I also tried to copy the Deutsche_Telekom_Root_CA_2.pem to /etc/ca-certificates/trust-source/anchors/ and renaming it to *.crt
After running "trust extract-compat " nothing has changed. If I navigate with NM's dialog to /etc/ca-certificates/trust-source/anchors/ the certificate file Deutsche_Telekom_Root_CA_2.crt doesn't show up. Although it is there in this directory.

It would be really nice if someone could clear up all the confusion about the upgraded handling of certificates.

berbae · 2014-12-15 10:07:22

dice wrote:

Actually there are a lot of files in /etc/ssl/certs but none of them show up in Networkmanager except ca-certificates.crt

I think you can choose this file; it contains the Deutsche_Telekom_Root_CA_2 certificate.
From 'man update-ca-trust':

/etc/ssl/certs/ca-certificates.crt
Classic filename, file contains a list of CA certificates trusted for TLS server authentication usage, in the simple
BEGIN/END CERTIFICATE file format, without distrust information. This file is a symbolic link that refers to
consolidated output created by the update-ca-trust command.

micsnare · 2014-12-15 10:07:49

Hello,

i seem to have the exact problem, when running "sudo trust extract-compat" I see the following output:
http://pastebin.com/uUxz9rec

p11-kit: certificate with distrust in location for anchors: mozilla.trust.crt
......

I basically followed the steps mentioned in the Arch News.....

Arch Linux

#1 2014-12-11 13:29:22

Handling changes to ca-certificates correctly

#2 2014-12-11 15:28:59

Re: Handling changes to ca-certificates correctly

#3 2014-12-11 16:05:05

Re: Handling changes to ca-certificates correctly

#4 2014-12-11 16:27:28

Re: Handling changes to ca-certificates correctly

#5 2014-12-11 16:54:16

Re: Handling changes to ca-certificates correctly

#6 2014-12-11 18:37:28

Re: Handling changes to ca-certificates correctly

#7 2014-12-11 18:50:58

Re: Handling changes to ca-certificates correctly

#8 2014-12-11 19:09:30

Re: Handling changes to ca-certificates correctly

#9 2014-12-11 22:29:54

Re: Handling changes to ca-certificates correctly

#10 2014-12-11 22:32:45

Re: Handling changes to ca-certificates correctly

#11 2014-12-12 02:50:31

Re: Handling changes to ca-certificates correctly

#12 2014-12-12 03:57:18

Re: Handling changes to ca-certificates correctly

#13 2014-12-12 04:27:23

Re: Handling changes to ca-certificates correctly

#14 2014-12-12 05:22:34

Re: Handling changes to ca-certificates correctly

#15 2014-12-12 10:36:01

Re: Handling changes to ca-certificates correctly

#16 2014-12-12 12:52:19

Re: Handling changes to ca-certificates correctly

#17 2014-12-12 12:59:03

Re: Handling changes to ca-certificates correctly

#18 2014-12-12 14:30:50

Re: Handling changes to ca-certificates correctly

#19 2014-12-12 15:03:40

Re: Handling changes to ca-certificates correctly

#20 2014-12-12 15:40:04

Re: Handling changes to ca-certificates correctly

#21 2014-12-12 18:14:52

Re: Handling changes to ca-certificates correctly

#22 2014-12-12 22:27:39

Re: Handling changes to ca-certificates correctly

#23 2014-12-13 10:02:22

Re: Handling changes to ca-certificates correctly

#24 2014-12-15 10:07:22

Re: Handling changes to ca-certificates correctly

#25 2014-12-15 10:07:49

Re: Handling changes to ca-certificates correctly

Board footer