I was forwarded a p12 file from a client with the push cert.
Can I change the password of this p12 file without any ramifications and if yes, can I use something like this:
openssl pkcs12 -in Certificates.p12 -out temp.pem -passin pass: -passout
pass:temppassword
openssl pkcs12 -export -in temp.pem -out Certificates-final.p12 -passin
pass:temppassword -passout pass:newpassword
rm -rf temp.pem
I found this on this website here
No you cannot do so without ramifications.
Exporting PKCS#12 contents with openssl will lose information which won't be restored upon re-creation of the PKCS#12.
Whether that metadata is important to you will depend on your PKCS#12 contents and your use-case.
There does not seem to be a way of simply "changing the password of the container" with openssl. (However, you can use Java's keytool to do this, as I explain later.)
TL;DR: use this instead of your openssl command:
keytool -importkeystore -srckeystore source.p12 -srcstoretype PKCS12 -srcstorepass:file ssp -destkeystore dest.p12 -deststoretype PKCS12 -deststorepass:file dsp -destkeypass:file dsp
OpenSSL
Here is a comparison between a re-created PKCS#12 and it's original,
from an old (and invalid) german tax login keystore I had for testing.
In my case a PKCS#12 re-created in this way was no longer valid/working for the intended application (certificate-based login) so I had to find a different solution.
Short overview (the original, then the re-created file):
$ openssl pkcs12 -info -in Certificates.p12 -noout
Enter Import Password:
MAC:sha1 Iteration 1024
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 1024
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 1024
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 1024
Certificate bag
Certificate bag
Certificate bag
Certificate bag
Certificate bag
Certificate bag
$ openssl pkcs12 -info -in Certificates-final.p12 -noout
Enter Import Password:
MAC:sha1 Iteration 2048
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Certificate bag
Certificate bag
Certificate bag
Certificate bag
Certificate bag
Certificate bag
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
And now a diff between the original exported PEM file contents, and the re-exported PEM of the re-created PKCS#12.
(I have redacted some base64 lines and also re-ordered the PEM data in the output
to make the diff shorter and the changes more obvious.)
You can see the original had two private keys (a signaturekey and an encryptionkey) while the new one only has one, as well as lost metadata on the Certificate bags.
Also note how the localKeyID's have been changed:
$ openssl pkcs12 -in Certificates.p12 -out temp.pem
$ openssl pkcs12 -in Certificates-final.p12 -out temp2.pem
$ diff -up temp.pem temp2.pem
--- temp.pem
+++ temp2.pem
## -1,74 +1,38 ##
Bag Attributes
- friendlyName: encryptionkey
- localKeyID: 54 4B 6A 30 42 67 43 63 35 33 6D 7A 30 45 44 47 47 44
+ localKeyID: DD 42 1D 23 0E 11 BB D7 0D 54 B7 10 D0 C6 F5 40 B6 B5 2C A4
Key Attributes: <No Attributes>
-----BEGIN ENCRYPTED PRIVATE KEY-----
-MIIFHDBOBgkqhkiG9w0BBQ0wQTApBgkqhkiG9w0BBQwwHAQIpJIbNX5suS8CAggA
-MAwGCCqGSIb3DQIJBQAwFAYIKoZIhvcNAwcECEUOqFMc2ya4BIIEyKcSq/QtaSQe
-KaGI+xHwWXmJ8kPova4Ypjy9ELFYH/qpOlfyvE2NUE8sTPfMmTGZfVgmzajZiAkv
-2bGbJJqotmBnX7Kq4R+p8rAsMNQeyc6Hz6HOFHB2u51m/+v6U89BnxZjzYPfBLrL
-mtEJJoEKLrwjh4lCZuEQjQ==
+MIIFHDBOBgkqhkiG9w0BBQ0wQTApBgkqhkiG9w0BBQwwHAQIStmsb0FWO6ECAggA
+MAwGCCqGSIb3DQIJBQAwFAYIKoZIhvcNAwcECFnnIOcMl607BIIEyJeDvQMny+9a
+g38QaURLMHGW1ZcSl1SQL3aISeF9OOVNDT6SdpH9ta+ZiBL47KYYRmzb/mrkAk8w
+xEdaY/v8/l4zo86XS3ZXX9/59rieb3YAm6GfyTAYyAwU+xMz0FHPtWjN0sWKFamx
+49Gel9yYCtfc9oRKdvaBuQ==
-----END ENCRYPTED PRIVATE KEY-----
Bag Attributes
- friendlyName: signaturekey
- localKeyID: 54 4B 6A 30 42 67 43 63 35 33 6D 7A 30 45 44 47 41 41
-Key Attributes: <No Attributes>
------BEGIN ENCRYPTED PRIVATE KEY-----
-MIIFHDBOBgkqhkiG9w0BBQ0wQTApBgkqhkiG9w0BBQwwHAQIw8wbVkc1YxICAggA
-MAwGCCqGSIb3DQIJBQAwFAYIKoZIhvcNAwcECCUFgpxoljgKBIIEyCIseTm0Y7uL
-6IaAqRqwPxb64iBLLN9E/XOkA5ZAzO4MgSsZieZQfpXLJPdTdnKx9WauzpDGVfs5
-p+i5Dmrl9olI2wEOCGdoG7YzzVh4SoTAf/4v9yJRylCXREoYDdK/EM09Am1XWRVa
-fqNaWVRO/1vfv7Rgc2Mwbw==
------END ENCRYPTED PRIVATE KEY-----
-Bag Attributes
- friendlyName: encryptionkey
- localKeyID: 54 4B 6A 30 42 67 43 63 35 33 6D 7A 30 45 44 47 47 44
+ localKeyID: DD 42 1D 23 0E 11 BB D7 0D 54 B7 10 D0 C6 F5 40 B6 B5 2C A4
subject=/serialNumber=991954729C/CN=991954729
issuer=/C=DE/O=Elster/OU=CA/CN=ElsterIdNrSoftCA
-----BEGIN CERTIFICATE-----
## -96,8 +60,7 ## QmpEFSHJxYXOtyar3x9Viad9r9KtcVViJxe/cpVE
u4rfbLegLqZsXPVlY+6+k/vokTD9Oc0IdXHNk1u1dSTUc4rvxohZAxKW+5/EoLar
+AajwQNu5CmFz76Y6tDOS7XqUFkdu6JNMvBfuFNAng2GXwo/l8LsstAz/w==
-----END CERTIFICATE-----
-Bag Attributes
- friendlyName: CN=ElsterIdNrSoftCA,OU=CA,O=Elster,C=DE
+Bag Attributes: <No Attributes>
subject=/C=DE/O=Elster/OU=CA/CN=ElsterIdNrSoftCA
issuer=/C=DE/O=Elster/OU=RootCA/CN=ElsterRootCA
-----BEGIN CERTIFICATE-----
## -126,8 +89,7 ## SxtMZZVZ6RuHLwfz+QYJ+uKghjImnZ7Gy93+S1yD
FwWQnJ1RBEUTIwMI9rrIGH5R4sUzfeS6YvJOCTcO372IC1CKRpx3odvLFR+FYM7/
nO/mlyfpTHkJrRm1IavqyBq0rUKbTUP7
-----END CERTIFICATE-----
-Bag Attributes
- friendlyName: CN=ElsterRootCA,OU=RootCA,O=Elster,C=DE
+Bag Attributes: <No Attributes>
subject=/C=DE/O=Elster/OU=RootCA/CN=ElsterRootCA
issuer=/C=DE/O=Elster/OU=RootCA/CN=ElsterRootCA
-----BEGIN CERTIFICATE-----
## -156,9 +118,7 ## EgzvybfTPjUTXr4G1FZyAJkUAw4EdHZ8K2fIijy6
VThgfYVrIfjKr00WsIW1QC3aWWCfgs19UjeLOPtydDgsU+UBAZg/fFTKYwQpx1Jg
n8L8DNLudrfbsj6m7Ir39fVi634a+v9k
-----END CERTIFICATE-----
-Bag Attributes
- friendlyName: signaturekey
- localKeyID: 54 4B 6A 30 42 67 43 63 35 33 6D 7A 30 45 44 47 41 41
+Bag Attributes: <No Attributes>
subject=/serialNumber=991954729A/CN=991954729
issuer=/C=DE/O=Elster/OU=CA/CN=ElsterIdNrSoftCA
-----BEGIN CERTIFICATE-----
## -186,8 +146,7 ## vByFoXLDf57jp0k2wGws31IBsPDmzlhlwziMstzk
u4rfbLegLqZsXPVlY+6+k/vokTD9Oc0IdXHNk1u1dSTUc4rvxohZAxKW+5/EoLar
zH7xfL59iS81Ok7F3kyWroq7Y6L5iG3+aXEVJyA9FfuGY2dKSVliqNQzEA==
-----END CERTIFICATE-----
-Bag Attributes
- friendlyName: CN=ElsterIdNrSoftCA,OU=CA,O=Elster,C=DE
+Bag Attributes: <No Attributes>
subject=/C=DE/O=Elster/OU=CA/CN=ElsterIdNrSoftCA
issuer=/C=DE/O=Elster/OU=RootCA/CN=ElsterRootCA
-----BEGIN CERTIFICATE-----
## -216,8 +175,7 ## SxtMZZVZ6RuHLwfz+QYJ+uKghjImnZ7Gy93+S1yD
jftsxZFkkWV/2zx5Lw/pTruKSlWx4bSC9oWB9Tk1w10ST80JsVCFoeezonHq8zLF
nO/mlyfpTHkJrRm1IavqyBq0rUKbTUP7
-----END CERTIFICATE-----
-Bag Attributes
- friendlyName: CN=ElsterRootCA,OU=RootCA,O=Elster,C=DE
+Bag Attributes: <No Attributes>
subject=/C=DE/O=Elster/OU=RootCA/CN=ElsterRootCA
issuer=/C=DE/O=Elster/OU=RootCA/CN=ElsterRootCA
-----BEGIN CERTIFICATE-----
Besides the lost metadata, losing a private key on import here, seems actually quite problematic to me.
So make certain to test your new PKCS#12, and possibly back up your old one in a safe location!
Tested with
$ openssl version
OpenSSL 1.1.0f 25 May 2017
keytool
keytool is a key and certificate management utility and is part of the Java JRE, for managing Java's keystore. In this case I use OpenJDK's version.
You might find this (on Linux) as /usr/bin/keytool, or in your Java installation, e.g. at /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/keytool.
With keytool you can change only the container password (keystore password),
without touching any keys inside (which is probably not what you want, though):
$ keytool -list -storetype pkcs12 -keystore Certificates.p12
Enter keystore password:
Keystore type: PKCS12
Keystore provider: SunJSSE
Your keystore contains 2 entries
encryptionkey, Jan 1, 2012, PrivateKeyEntry,
Certificate fingerprint (SHA1): DD:42:1D:23:0E:11:BB:D7:0D:54:B7:10:D0:C6:F5:40:B6:B5:2C:A4
signaturekey, Jan 1, 2012, PrivateKeyEntry,
Certificate fingerprint (SHA1): 18:F6:3F:FA:29:79:08:18:34:9A:99:CA:B7:47:AD:B0:36:49:A2:EB
Now we change the container password:
This overwrites the old file
$ keytool -storetype pkcs12 -keystore Certificates.p12 -storepasswd
Enter keystore password:
New keystore password:
Re-enter new keystore password:
And compare the results:
$ keytool -list -storetype pkcs12 -keystore Certificates.p12
Enter keystore password:
Keystore type: PKCS12
Keystore provider: SunJSSE
Your keystore contains 2 entries
encryptionkey, Jan 1, 2012, PrivateKeyEntry,
Certificate fingerprint (SHA1): DD:42:1D:23:0E:11:BB:D7:0D:54:B7:10:D0:C6:F5:40:B6:B5:2C:A4
signaturekey, Jan 1, 2012, PrivateKeyEntry,
Certificate fingerprint (SHA1): 18:F6:3F:FA:29:79:08:18:34:9A:99:CA:B7:47:AD:B0:36:49:A2:EB
$ openssl pkcs12 -info -in Certificates.p12 -noout
Enter Import Password:
MAC:sha1 Iteration 100000
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 1024
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 1024
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 50000
Certificate bag
Certificate bag
Certificate bag
Certificate bag
Certificate bag
Certificate bag
So keytool upgraded the iteration count, but the key alias information (encryptionkey/signaturekey) and file order in the container has been retained.
Note, however, that this only changes the password of the PKCS#12 keystore,
it does not touch the passwords of any encrypted private keys.
This is useful if you use PKCS#12 to store different keys with different encryption passphrases.
But it also means that you need to remember all of them, and you can no longer export these keys using openssl, as openssl can only handle keys that share the same password as the PKCS#12 container:
$ openssl pkcs12 -in Certificates.p12 -out temp0.pem
Enter Import Password:
Error outputting keys and certificates
140661347983616:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:../crypto/evp/evp_enc.c:535:
140661347983616:error:23077074:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 cipherfinal error:../crypto/pkcs12/p12_decr.c:63:
140661347983616:error:2306A075:PKCS12 routines:PKCS12_item_decrypt_d2i:pkcs12 pbe crypt error:../crypto/pkcs12/p12_decr.c:94:
You can then only export certificates from this file, using -nokeys:
$ openssl pkcs12 -in Certificates.p12 -out temp0.pem -nokeys
Finally, to actually change the keystore/container password and the encrypted key password(s) inside
(WHICH IS most likely WHAT YOU WANT), you can use this magic invocation:
$ keytool -importkeystore \
-srckeystore "${SRCFILE}" -srcstoretype PKCS12 -srcstorepass:file ssp \
-destkeystore "${DSTFILE}" -deststoretype PKCS12 -deststorepass:file dsp -destkeypass:file dsp
Importing keystore Certificates.p12 to Certificates-final.p12...
Entry for alias encryptionkey successfully imported.
Entry for alias signaturekey successfully imported.
Import command completed: 2 entries successfully imported, 0 entries failed or cancelled
$ rm ssp dsp
Where SRCFILE and DSTFILE are your PKCS#12 files respectively, and ssp and dsp
are files that you safely wrote your source- and dest-passphrases to, earlier (keytool can also read from environment variables using :env instead of :file.
And you can pass the passphrases on the commandline, but remember that that is unsafest and logged in your shell history.)
After now having re-created the PKCS#12, you can verify that the metadata and order of the contents was preserved:
$ keytool -list -storetype pkcs12 -keystore Certificates-final.p12
Enter keystore password:
Keystore type: PKCS12
Keystore provider: SunJSSE
Your keystore contains 2 entries
encryptionkey, Jun 17, 2018, PrivateKeyEntry,
Certificate fingerprint (SHA1): DD:42:1D:23:0E:11:BB:D7:0D:54:B7:10:D0:C6:F5:40:B6:B5:2C:A4
signaturekey, Jun 17, 2018, PrivateKeyEntry,
Certificate fingerprint (SHA1): 18:F6:3F:FA:29:79:08:18:34:9A:99:CA:B7:47:AD:B0:36:49:A2:EB
$ openssl pkcs12 -info -in Certificates-final.p12 -noout
Enter Import Password:
MAC:sha1 Iteration 100000
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 50000
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 50000
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 50000
Certificate bag
Certificate bag
Certificate bag
Certificate bag
Certificate bag
Certificate bag
$ openssl pkcs12 -in Certificates-final.p12 -out temp3.pem
Enter Import Password:
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
(again, I have redacted some base64 lines of the PEM for brevity)
$ diff -up temp.pem temp3.pem
--- temp.pem
+++ temp3.pem
## -1,74 +1,74 ##
Bag Attributes
friendlyName: encryptionkey
- localKeyID: 54 4B 6A 30 42 67 43 63 35 33 6D 7A 30 45 44 47 47 44
+ localKeyID: 54 4B 6A 30 42 67 45 62 39 32 65 75 33 40 45 47 47 42
Key Attributes: <No Attributes>
-----BEGIN ENCRYPTED PRIVATE KEY-----
-MIIFHDBOBgkqhkiG9w0BBQ0wQTApBgkqhkiG9w0BBQwwHAQI/f7cW8Pvi6MCAggA
-MAwGCCqGSIb3DQIJBQAwFAYIKoZIhvcNAwcECErznPIoMLg5BIIEyImqsql6iZH7
-I+ig1yWIlimEVNmSlgT1klEFnR83b8rIohq4cvX8lcrCs/5POc22023zlHx8dSnB
-+3OxV/uoGIwU3IhXlNb41dt3fF349dbnwJrDcv4Fw3lfc0v2Wl3P1b17P9/LJeUa
-EmmUy4UHQU2THwLQctyD1A==
+MIIFHDBOBgkqhkiG9w0BBQ0wQTApBgkqhkiG9w0BBQwwHAQI9UYIDREjVVYCAggA
+MAwGCCqGSIb3DQIJBQAwFAYIKoZIhvcNAwcECLWYUFhHE9lJBIIEyOIA+7TqLJ+V
+lpHBcm4GIwfiEuCRHBBxHg1QGeEN7MHW5imXe4ktFPlYJFU5jCZeHVyP+mkEEiNL
+PbozodEkdGweAGnpE2+wbOQOl67q+XdICgqRZAosjBUSnBOFYH0Lk8Gr/n0NNrdR
+yohBYL8PfeKyAzL4wKm5hQ==
-----END ENCRYPTED PRIVATE KEY-----
Bag Attributes
friendlyName: signaturekey
- localKeyID: 54 4B 6A 30 42 67 43 63 35 33 6D 7A 30 45 44 47 41 41
+ localKeyID: 54 4B 6A 30 42 67 45 62 39 32 65 75 33 40 45 46 43 40
Key Attributes: <No Attributes>
-----BEGIN ENCRYPTED PRIVATE KEY-----
-MIIFHDBOBgkqhkiG9w0BBQ0wQTApBgkqhkiG9w0BBQwwHAQI8VzhkYDa8/oCAggA
-MAwGCCqGSIb3DQIJBQAwFAYIKoZIhvcNAwcECIP5tmyQb2b/BIIEyNGpbxkv286e
-5gjectU9q6yecwP6/w2jGLN3jNwsUN3+3Zn92BRoPKsn5j5WryP4G/mu0QJnLmFM
-Cy92Cu41oUeR+q9ePmj+Z1Tjj//8uq4D5F0wZhcPjnhNqdnENfLxkt+CGywoX25A
-4Ia+Pt5EmZmx9vpca4j13Q==
+MIIFHDBOBgkqhkiG9w0BBQ0wQTApBgkqhkiG9w0BBQwwHAQIN7z1PFx1ONACAggA
+MAwGCCqGSIb3DQIJBQAwFAYIKoZIhvcNAwcECFI18ERY6QXpBIIEyIDmBKgCkqbK
+HF9qm8etjBpoyuBtElaNNyeQA9QwYCD2I0vYsPVcOGRE8VO6LmmFXIvx/KcK8rxi
+QSb4K6eM2VcrZqBqw6hHONi5/CkxYQpBcHCLOH+V/CR4i2BHu7pl/JdAIx/7emMX
+ul0+m+zoGCHlpWuOkCSe+A==
-----END ENCRYPTED PRIVATE KEY-----
Bag Attributes
friendlyName: encryptionkey
- localKeyID: 54 4B 6A 30 42 67 43 63 35 33 6D 7A 30 45 44 47 47 44
+ localKeyID: 54 4B 6A 30 42 67 45 62 39 32 65 75 33 40 45 47 47 42
subject=/serialNumber=991954729C/CN=991954729
issuer=/C=DE/O=Elster/OU=CA/CN=ElsterIdNrSoftCA
-----BEGIN CERTIFICATE-----
## -158,7 +158,7 ## n8L8DNLudrfbsj6m7Ir39fVi634a+v9k
-----END CERTIFICATE-----
Bag Attributes
friendlyName: signaturekey
- localKeyID: 54 4B 6A 30 42 67 43 63 35 33 6D 7A 30 45 44 47 41 41
+ localKeyID: 54 4B 6A 30 42 67 45 62 39 32 65 75 33 40 45 46 43 40
subject=/serialNumber=991954729A/CN=991954729
issuer=/C=DE/O=Elster/OU=CA/CN=ElsterIdNrSoftCA
-----BEGIN CERTIFICATE-----
And we see that the private keys have been re-encrypted (updated timestamp shown by keytool), but compared to openssl's output, this time, aside from the change in iteration count, only the localKeyID has changed.
Everything is still in there, and in the original order. Much better!
Whether that is close enough to the original file, again, depends on your use-case.
The upgraded iteration count better protects against brute-force attacks
on the keys, but could potentially be fatal if you need to use them with an
old Browser or OS which can't handle such high iteration counts.
(Since those are of the IE 4.0 and WinNT age, however, this should not be a problem in most cases.)
Using this procedure with keytool, I could change the password of my PKCS#12 keys in a way that was still useable and valid for my application.
I just stumbled across this page. Does it work?
To avoid dead links here is the contents of the blog post:
With following procedure you can change your password on an .pfx certificate using openssl.
Export you current certificate to a passwordless pem type:
[user#hostname]>openssl pkcs12 -in mycert.pfx -out tmpmycert.pem -nodes
Enter Import Password:
MAC verified OK
Convert the passwordless pem to a new pfx file with password:
[user#hostname]openssl pkcs12 -export -out mycert2.pfx -in tmpmycert.pem
Enter Export Password:
Verifying - Enter Export Password:
Remove the temporary file:
[user#hostname]rm tmpmycert.pem
Now you are done and can use the new mycert2.pfx file with your new password.
There will be no problem.
PFX is an encrypted container, changing the password of the container will have no effect on the certificates inside the container.
Using keytool there is no need to export anything and you won't lose any information. keytool can be used to change both passwords (keystore and private key). The key (excuse the pun) here is to change to password of the private key first. Otherwise, if the keystore password is different than the private key, keytool will not be able to change the password of the private key.
First change the password of the private key:
keytool -keystore <your.p12> -keypasswd -alias <alias_of_private_key>
Then change the password of the keystore:
keytool -keystore <your.p12> -storepasswd
That's all there is to it.
(Note: This method will still modify the iteration count the same way that #nyov's method does.)
Use the IKEYMAN tool for changing the password for the .p12 and key file.
Related
I’m trying to acces a private nexus repo. using docker login from a remote machine on the same network and despite i have followed instuctions in the documentation of docker i still get the x509: certfificate signed by unknown authority error,
I’m on a centOs 8 machine, with nexus OSS 3.29.2-02, i’ve configured the the repo according to the following documentation Configuring SSL
and i’ve created the self signed certificate using java keytool and it works when i access it from the browser on the same machine and from the remote machine, in the /app/sonatype-work/nexus3/log/nexus.log log file there is no errors.
i’ve copied the certificate .cer to the /etc/docker/certs.d/domain:port/ location then i also copied it to /etc/pki/ca-trust/source/anchors/ and ran sudo update-ca-trust according to docker docs:
docker insecure registry
when i keytool -printcert -sslserver domain:port -v from the remote machine the certificate is printed.
when i wget from the remote machine it works and the certificate is successfully validated and data downloaded.
i’ve checked many topics but all are talking about putting the certificate in the above mentioned locations what i’ve already done.
thanks in advance.
----------------------update--------------------------
[mehdilapin#localhost ~]$ wget https://mycustomregistry.com:7575
--2021-04-11 14:53:59-- https://mycustomregistry.com:7575/
Auflösen des Hostnamens mycustomregistry.com (mycustomregistry.com)… 192.168.1.9
Verbindungsaufbau zu mycustomregistry.com (mycustomregistry.com)|192.168.1.9|:7575 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 8903 (8,7K) [text/html]
Wird in »index.html.2« gespeichert.
index.html.2 100%[=====================================================================================================================>] 8,69K --.-KB/s in 0s
2021-04-11 14:53:59 (287 MB/s) - »index.html.2« gespeichert [8903/8903]
[mehdilapin#localhost ~]$ sudo keytool -printcert -sslserver mycustomregistry.com:4563/registry/api -v
Certificate #0
====================================
Eigentümer: CN=mycustomregistry.com, OU=organization Unit, O=organization, L=USA, ST=NewYork, C=US
Aussteller: CN=mycustomregistry.com, OU=organization Unit, O=organization, L=USA, ST=NewYork, C=US
Seriennummer: 68e917a2
Gültig von: Sun Apr 11 14:34:54 CET 2021 bis: Mon Apr 11 14:34:54 CET 2022
Zertifikatsfingerprints:
SHA1: 05:95:71:99:93:D1:30:A0:D1:82:0C:73:61:47:69:F0:2A:A4:52:B3
SHA256: EA:8A:0A:0C:C6:4B:BE:73:57:78:CC:DC:08:DE:92:8E:04:6F:B8:3E:8F:2A:71:C8:AD:5A:E7:19:BB:31:7C:AE
Signaturalgorithmusname: SHA256withRSA
Public Key-Algorithmus von Subject: 2048-Bit-RSA-Schlüssel
Version: 3
Erweiterungen:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: EF C5 91 38 62 ED 54 12 4E AA 9C 0F C6 73 F2 0C ...8b.T.N....s..
0010: 83 BF CA 5E ...^
]
]
[mehdilapin#localhost ~]$ sudo keytool -printcert -file /etc/docker/certs.d/mycustomregistry.com\:4563/ca-certificate.cer
Eigentümer: CN=mycustomregistry.com, OU=organization Unit, O=organization, L=USA, ST=NewYork, C=US
Aussteller: CN=mycustomregistry.com, OU=organization Unit, O=organization, L=USA, ST=NewYork, C=US
Seriennummer: 68e917a2
Gültig von: Sun Apr 11 14:34:54 CET 2021 bis: Mon Apr 11 14:34:54 CET 2022
Zertifikatsfingerprints:
SHA1: 05:95:71:99:93:D1:30:A0:D1:82:0C:73:61:47:69:F0:2A:A4:52:B3
SHA256: EA:8A:0A:0C:C6:4B:BE:73:57:78:CC:DC:08:DE:92:8E:04:6F:B8:3E:8F:2A:71:C8:AD:5A:E7:19:BB:31:7C:AE
Signaturalgorithmusname: SHA256withRSA
Public Key-Algorithmus von Subject: 2048-Bit-RSA-Schlüssel
Version: 3
Erweiterungen:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: EF C5 91 38 62 ED 54 12 4E AA 9C 0F C6 73 F2 0C ...8b.T.N....s..
0010: 83 BF CA 5E ...^
]
]
[mehdilapin#localhost ~]$ sudo keytool -printcert -file /etc/pki/ca-trust/source/anchors/ca-certificate.cer -v
Eigentümer: CN=mycustomregistry.com, OU=organization Unit, O=organization, L=USA, ST=NewYork, C=US
Aussteller: CN=mycustomregistry.com, OU=organization Unit, O=organization, L=USA, ST=NewYork, C=US
Seriennummer: 68e917a2
Gültig von: Sun Apr 11 14:34:54 CET 2021 bis: Mon Apr 11 14:34:54 CET 2022
Zertifikatsfingerprints:
SHA1: 05:95:71:99:93:D1:30:A0:D1:82:0C:73:61:47:69:F0:2A:A4:52:B3
SHA256: EA:8A:0A:0C:C6:4B:BE:73:57:78:CC:DC:08:DE:92:8E:04:6F:B8:3E:8F:2A:71:C8:AD:5A:E7:19:BB:31:7C:AE
Signaturalgorithmusname: SHA256withRSA
Public Key-Algorithmus von Subject: 2048-Bit-RSA-Schlüssel
Version: 3
Erweiterungen:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: EF C5 91 38 62 ED 54 12 4E AA 9C 0F C6 73 F2 0C ...8b.T.N....s..
0010: 83 BF CA 5E ...^
]
]
Certificates in /etc/docker/certs.d/ need to be x509 formatted and named with a crt extension (it's actually possible to configure client tls settings with this same folder). So rename:
/etc/docker/certs.d/mycustomregistry.com\:4563/ca-certificate.cer
to an x509/pem formatted certificate named:
/etc/docker/certs.d/mycustomregistry.com\:4563/ca-certificate.crt
That doesn't explain why the OS certificates aren't working. When checking with wget and curl, you should be able to reach the v2 api, even if it gives you a permission denied error:
curl https://mycustomregistry.com:4563/v2/
I can view the openSSL certifcate with this command
openssl x509 -text -in myCertificate.pem
I just wanted to see when the cert will expire only. The line which I want to read is,
Not After : Jul 28 14:09:57 2015 GMT
I tried using the grep command but it doesn't display anything.
grep "After" myCertificate.pem
Is there a way that I can read only that line of the certificate??
Thanks in advance
The short way is to use -enddate -noout (print the notAfter value, and don't re-output the cert PEM contents)
$ openssl x509 -in github.cer -enddate -noout
notAfter=Apr 12 12:00:00 2016 GMT
In order to use grep you need to continue using the -text option, because the phrase "Not After" doesn't appear in the cert, it's just an encoded representation. And then combine that with the pipe (|) operation:
$ openssl x509 -in github.cer -text -noout | grep After
Not After : Apr 12 12:00:00 2016 GMT
After building my own eventmachine/thin with SSL support on windows (Install OpenSSL with Ruby for eventmachine on Windows 7 x86) I got another problem with SSL certificate: when I use build-in self-signed one thin works fine but it does not respond to any request while using corporate certificate
Here is my path for obtaining the certificate:
I generated private key with puttygen (ssl-private.key)
I generated CSR using following command:
openssl req -out ssl.csr -key ssl-private.key -new
I sent CSR to CA and received P7B file
I converted P7B using following command:
openssl pkcs7 -inform DER -outform PEM -in cert.p7b -print_certs > cert.crt
What could go wrong here?
What have I checked:
openssl rsa -in ssl-private.key -check
says "RSA key ok"
openssl x509 -in cert.crt -text -noout
says
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
***
Signature Algorithm: sha1WithRSAEncryption
Issuer: ***
Validity
Not Before: Feb 16 08:47:25 2004 GMT
Not After : Feb 16 08:55:36 2024 GMT
Subject: ***
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
***
Exponent: 3 (0x3)
X509v3 extensions:
X509v3 Key Usage:
Digital Signature, Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
***
1.3.6.1.4.1.311.21.1:
...
Signature Algorithm: sha1WithRSAEncryption
***
while the same check made on self-signed cert, created using
openssl genrsa -des3 -out server.orig.key 2048
openssl rsa -in server.orig.key -out server.key
openssl req -new -key server.key -out server.csr
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
says
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
***
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=PL, ST=-, O=Internet Widgits Pty Ltd, CN=test.org
Validity
Not Before: Jun 24 14:42:07 2015 GMT
Not After : Jun 23 14:42:07 2016 GMT
Subject: C=PL, ST=-, O=Internet Widgits Pty Ltd, CN=test.org
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
***
Exponent: 65537 (0x10001)
Signature Algorithm: sha256WithRSAEncryption
***
ok some change: I have changed certs order in crt file so that final cert is not last but first and the result is different: chrome drops an error of NET::ERR_CERT_INVALID, IE similar and both does not navigate further
openssl s_client output (looks ok, *** Root CA 1 is trusted in windows):
Loading 'screen' into random state - done
CONNECTED(000001E8)
depth=1 DC = com, DC = ***, CN = *** Enterprise CA 1
verify error:num=20:unable to get local issuer certificate
---
Certificate chain
0 s:/C=***/ST=***/O=***/CN=***.com
i:/DC=com/DC=***/CN=*** Enterprise CA 1
1 s:/DC=com/DC=***/CN=*** Enterprise CA 1
i:/DC=com/DC=***/CN=*** Root CA 1
---
Server certificate
-----BEGIN CERTIFICATE-----
***
-----END CERTIFICATE-----
subject=/C=***/ST=***/O=***/CN=***.com
issuer=/DC=com/DC=***/CN=*** Enterprise CA 1
---
No client certificate CA names sent
---
SSL handshake has read 3404 bytes and written 665 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : AES256-GCM-SHA384
Session-ID: ***
Session-ID-ctx:
Master-Key: ***
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket: ***
Start Time: 1435319943
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
read:errno=0
I have made a simple https server (lib/emtestssl):
require 'rubygems'
require 'bundler/setup'
Bundler.require
class ServerHandler < EM::Connection
def post_init
puts "post_init"
start_tls :private_key_file => 'private.key', :cert_chain_file => 'comb.crt', :verify_peer => false
end
def receive_data(data)
puts "Received data in server: #{data}"
send_data("HTTP/1.1 200 OK\n\nHello world!")
close_connection_after_writing
end
end
EventMachine.run do
puts 'Starting server...'
EventMachine.start_server('145.245.202.233', 443, ServerHandler)
end
it works fine without tls, with tls browser won't allow to connect :(
as per http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#verify private key and certificate do match
it looks like (patched) eventmachine is completely fine: i have taken key/cert pair from existing server and (after a url mismatch warning from the browser) it works fine
after comparing the certificates it looks like my CA has failed and brought me a cert with wrong properties: working one is described as Server Authentication (1.3.6.1.5.5.7.3.1) while failing one is Client Authentication (1.3.6.1.5.5.7.3.2)
i will issue another csr and charge them for lost day... :/
maybe one important discovery is an order of certificates within cert file: one must go from the final cert to the root being at the end of the chain
I need to get the expiry date of our iOS enterprise certificate used in an ipa's embedded.mobileprovision file using the command line.
I've got this so far:
security cms -D -i Payload/*.app/embedded.mobileprovision > tmp.plist && /usr/libexec/PlistBuddy -c 'Print :DeveloperCertificates' tmp.plist | base64 -d - | openssl x509 -inform DER -noout -text
The response:
Apr 22 12:28:47 c01892 base64[14721] <Info>: Read 510 bytes.
Apr 22 12:28:47 c01892 base64[14721] <Info>: Wrote 680 bytes.
Apr 22 12:28:47 c01892 base64[14721] <Info>: Read 510 bytes.
Apr 22 12:28:47 c01892 base64[14721] <Info>: Wrote 680 bytes.
Apr 22 12:28:47 c01892 base64[14721] <Info>: Read 440 bytes.
Apr 22 12:28:47 c01892 base64[14721] <Info>: Wrote 588 bytes.
unable to load certificate
14722:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:/SourceCache/OpenSSL098/ OpenSSL098-52.20.2/src/crypto/asn1/tasn_dec.c:1323:
14722:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:/SourceCache/ OpenSSL098/OpenSSL098-52.20.2/src/crypto/asn1/tasn_dec.c:379:Type=X509
The openssl command works on our certificate file just fine:
openssl x509 -inform DER -noout -text -in "iPhone Distribution: XXXX.cer"
So what I am missing is getting the certificate out of the embedded.mobileprovision, decode it and save it to a file or pass it by piping.
If I split the sommand up, we get the following:
a. Get the certificate out of the embedded.mobileprovision:
security cms -D -i Payload/*.app/embedded.mobileprovision > tmp.plist && /usr/libexec/PlistBuddy -c 'Print :DeveloperCertificates' tmp.plist > encodedcert.b64
b. Decode the retrieved base64 to a .cer file:
base64 -d encodedcert.b64 certificate.cer
c. Read it with openssl:
openssl x509 -inform DER -noout -text -in certificate.cer
Unfortunatly, the generated certificate.cer file by my base64 command is zero bytes long...
Who can help me out further?
I've successfully been able to get to the certificate information.
The problem was that my PlistBuddy command was wrong. I should have used 'DeveloperCertificates:0' instead of ':DeveloperCertificates'.
I also did not need the base64 stuff.
So the working commandline to get the info from the enterprise certificate in an embedded.mobileprovision profile is
security cms -D -i Payload/*.app/embedded.mobileprovision > tmp.plist && /usr/libexec/PlistBuddy -c 'Print DeveloperCertificates:0' tmp.plist | openssl x509 -inform DER -noout -enddate
Split up into three parts:
Get a plist from the embedded.mobileprovision:
security cms -D -i Payload/*.app/embedded.mobileprovision > tmp.plist
Get the first certificate from the plist:
/usr/libexec/PlistBuddy -c 'Print DeveloperCertificates:0' tmp.plist |
Read the certificate passed through the pipe and extract the enddate (-text instead of -enddate gives you the entire certificate information):
openssl x509 -inform DER -noout -enddate
Edit: Here is the command without a temporary plist file:
/usr/libexec/PlistBuddy -c 'Print DeveloperCertificates:0' /dev/stdin <<< $(security cms -D -i Payload/*.app/embedded.mobileprovision) | openssl x509 -inform DER -noout -enddate
I am using a self generated wildcard SSL certificate and I would like to know if the following is a problem and, if so, what I can do to fix that. Certificate is for my web Ruby on Rails 3 application running on localhost.
I am using a Mac OS running "Snow Leopard" 1.6.6. Typing in the Terminal
<my_user_name>$ openssl s_client -connect localhost.com:443
I get the following:
CONNECTED(00000003)
depth=1 C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = My Name\Surname
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=*localhost.com
i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=My Name\Surname
1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=My Name\Surname
i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=My Name\Surname
---
Server certificate
-----BEGIN CERTIFICATE-----
MIICJDCCAY0CAQEwDQYJKoZIhvcNAQEEBQAwWTELMAkGA1UEBhMCQVUxEzARBgNV
BAgMClNvbWUtU3RhdGUxITAfBgNVBAoMGEludGVybmV0IFdpZGdpdHMgUHR5IEx0
ZDESMBAGA1UEAwwJU2VyZ2lvIEwuMB4XDTExMDIxODIwMDAwOFoXDTEyMDIxODIw
MDAwOFowXDELMAkGA1UEBhMCQVUxEzARBgNVBAgMClNvbWUtU3RhdGUxITAfBgNV
BAoMGEludGVybmV0IFdpZGdpdHMgUHR5IEx0ZDEVMBMGA1UEAwwMKnBqdG5hbWUu
Y29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDM46dH9rWKy5sNKBwJ7oo
wytsjw8fFLRskJGE0QqgKpz5ZtYK8yC/kifI4gpWZYVySePmVqHR6+wpv8Ry1KVx
Bl2qhF6ssLBbc5bvOK4eF2Rx9LNAZ/ndy+0q07DVsnAMMCxhNmegltCG1JZhazCG
g7elPm2pIQLAQvKlFSJwkQIDAQABMA0GCSqGSIb3DQEBBAUAA4GBADO7XJbOASZM
Bm/XElq1AuVU1dR6/wkowLOxCn8+KWsUmyIdZj1yL8+83nhhG/yekzOr25n/I0SQ
zN1aUi3oX5vXlx8vp2xQsnug2BM/InfQxOn+90JjhZYPbCokH9ifzYsNj7fvGg57
KZ4et2jSfchxFMRqqoPutdOp/gNKw3me
-----END CERTIFICATE-----
subject=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=*localhost.com
issuer=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=My Name\Surname
---
No client certificate CA names sent
---
SSL handshake has read 1944 bytes and written 409 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 63BE474E62950D542BCBE30F72F80C28851EE23EA15BA34AE3E3E46AB5615505
Session-ID-ctx:
Master-Key: 9E8A8F7F4E824A2B251D5A28E3A133AC761BA8EDB237073973D2B1AE0AE0A31ADDADA2315F33B443B3F29D382070FC6C
Key-Arg : None
PSK identity: None
PSK identity hint: None
TLS session ticket:
0000 - 10 b0 f3 4d 96 90 d3 65-22 d4 bf 09 27 8c a0 af ...M...e"...'...
0010 - d3 79 5c 9a cf d9 5b e1-3f aa 46 56 55 9b 55 50 .y\...[.?.FVU.UP
0020 - 8b 49 99 07 bc 35 e0 bc-e1 1d 4e 61 f0 aa 33 57 .I...5....Na..3W
0030 - 1d 37 0b dd 51 ae 81 ea-df 8e 6e 25 ff f7 2b ff .7..Q.....n%..+.
0040 - e9 88 79 e4 57 2a b2 f2-61 22 df 86 f0 24 57 a7 ..y.W*..a"...$W.
0050 - 06 13 b5 71 47 dc d5 ac-c2 61 89 75 6e 03 45 cc ...qG....a.un.E.
0060 - 14 69 0c 72 3a 4a 00 b3-4f d8 8d 44 2d 66 cb 40 .i.r:J..O..D-f.#
0070 - 80 c8 9b e2 12 9f 0d b4-58 6e a1 c7 bb fe 92 6d ........Xn.....m
0080 - b8 b7 b7 f0 dc 1c ab fd-44 a4 25 96 c6 09 09 a1 ........D.%.....
0090 - aa ff c0 dc 53 6b 30 13-30 f3 44 f6 78 b1 43 c7 ....Sk0.0.D.x.C.
00a0 - ca 88 9d 63 41 d3 c1 a1-af fa 36 e2 9c fd 0e 62 ...cA.....6....b
00b0 - c4 44 6b 5c 74 da ff be-a8 98 3f 54 f9 fa 59 15 .Dk\t.....?T..Y.
Compression: 1 (zlib compression)
Start Time: 1298072476
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
The issue, maybe, is on line 3: verify error:num=19:self signed certificate in certificate chain. What that means? Is my certificate working for localhost.com?
UPDATE
In browser I accepted my sel-signed certificate (I explicitly added my certificate to the list of private certificates in the system), so, even I get verify error:num=19:self signed certificate in certificate chain and in my application I use the following code to make HTTP requests over SSL
require 'uri'
require 'net/https'
host = "https://<subdomain>.localhost.com"
path = "/users/1.json"
uri = URI.parse("#{host}#{path}")
http = Net::HTTP.new(uri.host, uri.port)
http.use_ssl = true
http.verify_mode = OpenSSL::SSL::VERIFY_NONE
# I think here is necessary to verify connections using 'http.verify_mode = OpenSSL::SSL::VERIFY_PEER':
# in localhost using that the connection will fault, but in production mode
# (when I will deploy the application) I think I MUST use 'VERIFY_PEER'
http.ca_file = File.join(File.dirname("<certificate_folder>/wildcard.certificate/ca.db.certs/"), "01.pem")
http.start do
response = http.get("#{host}#{path}")
#test_response = JSON(response.body)["profile"]
end
the connection is actually going over SSL? 'VERIFY_PEER' means something?
SSL verifies the validity of a host by checking the certificate of the host.
Every certificate is either:
Self-Signed
Signed by another certificate.
If it is signed by another certificate, it checks the certificate that signed it.
Now, at some point, to verify if a certificate is valid or not, it has to match that certificate against a store of 'valid' certificates it has on the system (Eg: Firefox maintains its own store, Windows has its own store, etc.). If it matches some certificate in the hierarchy against the store, then it treats that certificate as valid, and therefore all certificates signed by it are valid.
However, if the certificate is self-signed and isn't in the store, then it will reject it, or warn you that it cannot verify the certificate.
If the certificate is for you to test out an application, or for a very limited scale deployment where you can ask people to add your certificate to their store, this is alright. However, if you are planning to move your application to a production site at somedomain.com, then you will probably need to buy a certificate for that domain.
Note: in either case, the self-signed certificate you have for localhost is valid only for 'localhost', not even if it is accessed on an intranet via IP
The purpose of certificates [in SSL] is to prove that the host is the one it claims to be and not the fake one. To do this certificates are issued by certificate authorities, who [are supposed to properly] check the identity of the person or organization that requests a certificate. Consequently, self-signed certificate doesn't reliably identify the host (even if it's a localhost). So most applications report a validation error when they see a self-signed certificate in a chain of certificates. The only exception is [usually] when the certificate is explicitly added to the list of private certificates in the system - in this case it's accepted as valid.
Consequently, if you have created your self-signed certificate for test purposes on your computer, then you can add it to trusted list. Otherwise (if you need a certificate for a public host), you will need to buy a certificate from one of certificate authorities.