I have installed Strimzi Kafka and created TLS enabled cluster as follows:
listeners:
plain: {}
tls:
authentication:
type: tls
The Kafka cluster CA certificate created automatically and looks like this:
Entry type: trustedCertEntry
Owner: CN=cluster-ca v0, O=io.strimzi
Issuer: CN=cluster-ca v0, O=io.strimzi
Serial number: def376173b64bf84
Valid from: Tue Jan 26 23:25:07 MSK 2021 until: Wed Jan 26 23:25:07 MSK 2022
Certificate fingerprints:
SHA1: 4D:AA:27:0F:84:61:88:D0:B8:1C:CB:9A:DD:5F:D3:E8:3D:52:B4:65
The question is: what should I do after a year passed (as the certificate automatically created with 1 year period). I use TLS authentication for the clients (producers/consumers) -- and as a result I add this certificate to SSL truststore on the client side. What should I need on the client after a year passed? I guess update truststore with new cluster CA certificate?
The CA will be automatically renewed by Strimzi. You can just update your truststore and keep using your cluster. If you prefer, you can also provide your own certificate for the listener: https://strimzi.io/docs/operators/latest/full/using.html#kafka-listener-certificates-str or your own CA: https://strimzi.io/docs/operators/latest/full/using.html#installing-your-own-ca-certificates-str
Related
I have three node MongoDB cluster in GCP kubernetes cluster following [1], [2]. I can properly connect with tls=false using mongosh client. Then I enabled tls following [3]. Mongo cluster start properly but I cannot connect from mongosh.
Following is the connection details.
{
"connectionString.standard": "mongodb://mongo-user:stl-m0ng0-dev#mongodb-dev-0.mongodb-dev-svc.dev.svc.cluster.local:27017,mongodb-dev-1.mongodb-dev-svc.dev.svc.cluster.local:27017,mongodb-dev-2.mongodb-dev-svc.dev.svc.cluster.local:27017/dev?replicaSet=mongodb-dev&ssl=true",
"connectionString.standardSrv": "mongodb+srv://mongo-user:stl-m0ng0-dev#mongodb-dev-svc.dev.svc.cluster.local/dev?replicaSet=mongodb-dev&ssl=true",
"password": "xxxxxxx",
"username": "mongo-user"
}
Followings are the certificate details.
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = TLSGenSelfSignedtRootCA, L = $$$$
Validity
Not Before: Jul 27 09:07:50 2022 GMT
Not After : Jul 24 09:07:50 2032 GMT
Subject: CN = *.mongodb-dev-svc.dev.svc.cluster.local, O = client
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:c4:44:a6:21:95:85:9a:dc:96:63:8e:76:ed:d9:
3a:59
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Subject Alternative Name:
DNS:mongodb-dev-1.mongodb-dev-svc.dev.svc.cluster.local, DNS:mongodb-dev-2.mongodb-dev-svc.dev.svc.cluster.local, DNS:mongodb-dev-3.mongodb-dev-svc.dev.svc.cluster.local
Signature Algorithm: sha256WithRSAEncryption
7b:78:43:73:ae:2f:ce:97:de:b2:19:56:4c:38:71:8e:3d:ff:
5b:15:79:c1
Will display server certificate info
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = TLSGenSelfSignedtRootCA, L = $$$$
Validity
Not Before: Jul 27 09:07:50 2022 GMT
Not After : Jul 24 09:07:50 2032 GMT
Subject: CN = *.mongodb-dev-svc.dev.svc.cluster.local, O = server
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:bc:1e:4a:a7:4f:c4:01:71:2c:78:eb:ac:c9:53:
24:c1
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Subject Alternative Name:
DNS:mongodb-dev-0.mongodb-dev-svc.dev.svc.cluster.local, DNS:mongodb-dev-1.mongodb-dev-svc.dev.svc.cluster.local, DNS:mongodb-dev-2.mongodb-dev-svc.dev.svc.cluster.local
Signature Algorithm: sha256WithRSAEncryption
16:0f:09:02:66:05:69:7b:91:3b:93:73:86:64:d5:8f:53:2d:
08:19:68:a7
Client side has following error
root#xxxxxxxxxxxxxxxxxx-55955c9fcd-bpp98:/usr/src/app# mongosh "mongodb+srv://mongo-user:stl-m0ng0-dev#mongodb-dev-svc.dev.svc.cluster.local/dev?replicaSet=mongodb-dev&ssl=false&tlsCAFile=ca.pem&tlsCertificateKeyFile=key.pem"
Current Mongosh Log ID: 62e1029487b960f1bd204b1d
Connecting to: mongodb+srv://<credentials>#mongodb-dev-svc.dev.svc.cluster.local/dev?replicaSet=mongodb-dev&ssl=false&tlsCAFile=ca.pem&tlsCertificateKeyFile=key.pem&appName=mongosh+1.5.1
MongoServerSelectionError: connection <monitor> to 10.120.6.8:27017 closed
Server side has following error
2022-07-27T09:25:44.992+0000 I NETWORK [conn25852] end connection 10.120.6.9:33914 (14 connections now open)
2022-07-27T09:25:44.993+0000 I NETWORK [listener] connection accepted from 10.120.6.9:33918 #25855 (15 connections now open)
2022-07-27T09:25:44.993+0000 E NETWORK [conn25854] SSL peer certificate validation failed: unsupported certificate purpose
2022-07-27T09:25:44.994+0000 I NETWORK [conn25854] Error receiving request from client: SSLHandshakeFailed: SSL peer certificate validation failed: unsupported certificate purpose. Ending connection from 10.120.8.127:58220 (connection id: 25854)
2022-07-27T09:25:44.994+0000 I NETWORK [conn25854] end connection 10.120.8.127:58220 (14 connections now open)
2022-07-27T09:25:44.995+0000 I NETWORK [listener] connection accepted from 10.120.8.127:58224 #25856 (15 connections now open)
2022-07-27T09:25:44.998+0000 E NETWORK [conn25855] SSL peer certificate validation failed: unsupported certificate purpose
2022-07-27T09:25:44.998+0000 I NETWORK [conn25855] Error receiving request from client: SSLHandshakeFailed: SSL peer certificate validation failed: unsupported certificate purpose. Ending connection from 10.120.6.9:33918 (connection id: 25855)
2022-07-27T09:25:44.998+0000 I NETWORK [conn25855] end connection 10.120.6.9:33918 (14 connections now open)
2022-07-27T09:25:45.000+0000 E NETWORK [conn25856] SSL peer certificate validation failed: unsupported certificate purpose
2022-07-27T09:25:45.000+0000 I NETWORK [conn25856] Error receiving request from client: SSLHandshakeFailed: SSL peer certificate validation failed: unsupported certificate purpose. Ending connection from 10.120.8.127:58224 (connection id: 25856)
2022-07-27T09:25:45.000+0000 I NETWORK [conn25856] end connection 10.120.8.127:58224 (13 connections now open)
2022-07-27T09:25:45.001+0000 I REPL_HB [replexec-2] Heartbeat to mongodb-dev-1.mongodb-dev-svc.dev.svc.cluster.local:27017 failed after 2 retries, response status: HostUnreachable: stream truncated
2022-07-27T09:25:45.003+0000 I NETWORK [listener] connection accepted from 10.120.8.127:58228 #25858 (14 connections now open)
2022-07-27T09:25:45.007+0000 E NETWORK [conn25858] SSL peer certificate validation failed: unsupported certificate purpose
2022-07-27T09:25:45.007+0000 I NETWORK [conn25858] Error receiving request from client: SSLHandshakeFailed: SSL peer certificate validation failed: unsupported certificate purpose. Ending connection from 10.120.8.127:58228 (connection id: 25858)
2022-07-27T09:25:45.007+0000 I NETWORK [conn25858] end connection 10.120.8.127:58228 (13 connections now open)
Operator log has TLS configuration issue.
2022-07-27T10:06:05.893Z INFO controllers/mongodb_status_options.go:110 TLS config is not yet valid, retrying in 10 seconds
2022-07-27T10:06:15.899Z INFO controllers/replica_set_controller.go:140 Reconciling MongoDB {"ReplicaSet": "dev/mongodb-replica-set"}
2022-07-27T10:06:15.900Z DEBUG controllers/replica_set_controller.go:142 Validating MongoDB.Spec {"ReplicaSet": "dev/mongodb-replica-set"}
2022-07-27T10:06:15.900Z DEBUG controllers/replica_set_controller.go:151 Ensuring the service exists {"ReplicaSet": "dev/mongodb-replica-set"}
2022-07-27T10:06:15.900Z DEBUG agent/agent_readiness.go:101 The Pod '' doesn't have annotation 'agent.mongodb.com/version' yet {"ReplicaSet": "dev/mongodb-replica-set"}
2022-07-27T10:06:15.900Z DEBUG agent/agent_readiness.go:101 The Pod '' doesn't have annotation 'agent.mongodb.com/version' yet {"ReplicaSet": "dev/mongodb-replica-set"}
2022-07-27T10:06:15.900Z DEBUG agent/agent_readiness.go:101 The Pod '' doesn't have annotation 'agent.mongodb.com/version' yet {"ReplicaSet": "dev/mongodb-replica-set"}
2022-07-27T10:06:15.900Z DEBUG agent/replica_set_port_manager.go:122 No port change required {"ReplicaSet": "dev/mongodb-replica-set"}
2022-07-27T10:06:15.906Z INFO controllers/replica_set_controller.go:462 Create/Update operation succeeded {"ReplicaSet": "dev/mongodb-replica-set","operation": "updated"}
2022-07-27T10:06:15.906Z INFO controllers/mongodb_tls.go:40 Ensuring TLS is correctly configured {"ReplicaSet": "dev/mongodb-replica-set"}
2022-07-27T10:06:15.906Z WARN controllers/mongodb_tls.go:47 CA resource not found: Secret "tls-ca-key-pair" not found {"ReplicaSet": "dev/mongodb-replica-set"}
[1]. https://github.com/mongodb/mongodb-kubernetes-operator/blob/v0.7.4/docs/install-upgrade.md
[2]. https://github.com/mongodb/mongodb-kubernetes-operator/blob/v0.7.4/docs/deploy-configure.md
[3]. https://github.com/mongodb/mongodb-kubernetes-operator/blob/v0.7.4/docs/secure.md
It had two main reasons.
I followed [1] to enable SSL. It create another Statefulset. After that there are two mongo servers. Uninstall operator and re-install and followed last stable release documentation [2]. After it properly detect configmap and secret.
But it gave SSL issue in certificates as Unsupported Certificate in server modules. Following [3] found the issue. We need to remove extended_key_useage from openssl.conf. Otherwise it not work properly.
Important thread [4]
Hope this help.
[1]. https://github.com/mongodb/mongodb-kubernetes-operator/blob/master/docs/secure.md
[2]. https://github.com/mongodb/mongodb-kubernetes-operator/blob/v0.7.4/docs/secure.md
[3]. https://stackoverflow.com/a/61964464/5607943
[4]. https://groups.google.com/g/mongodb-user/c/EmESxx5KK9Q/m/xH6Ul7fTBQAJ
I am trying to set up OpenVPN on Ubuntu 20.04. I'm not experienced in this area. After I set up OpenVPN, I perform test connectivity. I received handshake error message:
Sun Jul 26 05:53:17 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]68.228.217.219:1194
Sun Jul 26 05:53:17 2020 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sun Jul 26 05:53:17 2020 UDP link local: (not bound)
Sun Jul 26 05:53:17 2020 UDP link remote: [AF_INET]My_Public_ISP_IP:1194
Sun Jul 26 05:54:17 2020 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Jul 26 05:54:17 2020 TLS Error: TLS handshake failed
Sun Jul 26 05:54:17 2020 SIGUSR1[soft,tls-error] received, process restarting
Sun Jul 26 05:54:17 2020 Restart pause, 5 second(s)
Then I check to log
journalctl --identifier openvpn
I found two error message I believe why my OpenVPN cannot connect:
This is one of the error messages:
Could not determine IPv4/IPv6 protocol. Using AF_INET
I notice it's using my old client .conf file:
Error Message
My new .conf file is local.ovpn/
I tried removing client conf. sudo rm -vf BigK and replace it with local.ovpn. but it didnt work.
I need help figuring this issue out. i tried researching on my own but i came up short.
UPDATE
After several hours of researching online. the closet post I see helping me is this post https://unix.stackexchange.com/questions/385966/openvpn-error-status-2-and-cant-connect-to-internet-while-usingwhich didn't help.
I checked my client.conf
client
dev tun
proto udp
remote Public_IP 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
ignore-unknown-option block-outside-dns
block-outside-dns
verb 3
<ca>
Here is my server.conf
local IP
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
crl-verify crl.pem
explicit-exit-notify
Here is localvpn.ovpn
client
dev tun
proto udp
remote Public_IP 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
ignore-unknown-option block-outside-dns
block-outside-dns
verb 3
I faced the same problem and didn't find any solution. I was looking for another way to connect to OpenVPN server and it helped me.
Ubuntu 20.04 has a default tool for using OpenVPN:
Settings -> Network
Click + icon on one line with the VPN title
Choose Import from file... option and select your .ovpn config file in the popup window
Click Add button and that's it
PS: I hope it will help somebody to save any hours
I have used kubeadm alpha phase certs to recreate the certificates used in my Kubernetes cluster. Also, use the alpha phase for kubeconfig. Now when trying to join a new worker - it is giving me errors that my token is invalid even when the token has been regenerate 3 times using - kubeadm token create --print-join-command.
The error that I keep getting is:
[discovery] Created cluster-info discovery client, requesting info from "https://x.x.x.x:6443"
[discovery] Failed to connect to API Server "x.x.x.x:6443": token id "bvw4cz" is invalid for this cluster or it has expired. Use "kubeadm token create" on the master node to creating a new valid token
Anyone run into the same problems or have a suggestion?
Thanks!
EDIT--
This is the tail end of /var/log/syslog --
Nov 5 09:40:01 master01 kubelet[755]: E1105 09:40:01.892304 755 kubelet.go:2236] node "master01" not found
Nov 5 09:40:01 master01 kubelet[755]: E1105 09:40:01.928937 755 reflector.go:134] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:47: Failed to list *v1.Pod: Get https://x.x.x.x:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dkubernetserver&limit=500&resourceVersion=0: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kubernetes")
Nov 5 09:40:01 master01 kubelet[755]: E1105 09:40:01.992427 755 kubelet.go:2236] node "master01" not found
EDIT 2 - 1. Now the real question is - if regenerating certs do not enable trust to itself as a CA, how do you fix this problem? 2. Is this a problem that is well known?
I am new to windows drivers and the signing procedure that's required for production use.
I recently purchased a GoDaddy Driver Signing Certificate and they ensured me that it should be working for kernel mode drivers, however I can not seem to be able to make it work.
After compiling I sign the .cat file with signtool with this command:
"C:\Program Files (x86)\Windows Kits\8.1\bin\x86\signtool" sign /n "COMPANY_NAME" /t http://timestamp.verisign.com/scripts/timstamp.dll mydriver.cat
This finishes successfully and I verify the certificate with this command:
"C:\Program Files (x86)\Windows Kits\8.1\bin\x86\signtool" verify /kp /v mydriver.cat
The output of the above commands states that is successful. You can see the output below
Verifying: mydriver.cat
Signature Index: 0 (Primary Signature)
Hash of file (sha1): AB24DC3601D29CE37CC2611EDEB7C8E3FBD89D04
Signing Certificate Chain:
Issued to: Go Daddy Class 2 Certification Authority
Issued by: Go Daddy Class 2 Certification Authority
Expires: Thu Jun 29 19:06:20 2034
SHA1 hash: 2796BAE63F1801E277261BA0D77770028F20EEE4
Issued to: Go Daddy Secure Certification Authority
Issued by: Go Daddy Class 2 Certification Authority
Expires: Mon Nov 16 03:54:37 2026
SHA1 hash: 7C4656C3061F7F4C0D67B319A855F60EBC11FC44
Issued to: <COMPANY_NAME>
Issued by: Go Daddy Secure Certification Authority
Expires: Sat Jul 23 19:23:39 2016
SHA1 hash: B53404B368EED5A734D332C10702B5D5B5C8E5DE
The signature is timestamped: Sat Jul 25 11:37:02 2015
Timestamp Verified by:
Issued to: Thawte Timestamping CA
Issued by: Thawte Timestamping CA
Expires: Fri Jan 01 01:59:59 2021
SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656
Issued to: Symantec Time Stamping Services CA - G2
Issued by: Thawte Timestamping CA
Expires: Thu Dec 31 01:59:59 2020
SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1
Issued to: Symantec Time Stamping Services Signer - G4
Issued by: Symantec Time Stamping Services CA - G2
Expires: Wed Dec 30 01:59:59 2020
SHA1 hash: 65439929B67973EB192D6FF243E6767ADF0834E4
Cross Certificate Chain:
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 15:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3
Issued to: Go Daddy Class 2 Certification Authority
Issued by: Microsoft Code Verification Root
Expires: Sun Aug 27 19:48:23 2023
SHA1 hash: D9612472EF0F2787E2B2D9E063A06B32FA5E333D
Issued to: Go Daddy Secure Certification Authority
Issued by: Go Daddy Class 2 Certification Authority
Expires: Mon Nov 16 03:54:37 2026
SHA1 hash: 7C4656C3061F7F4C0D67B319A855F60EBC11FC44
Issued to: <COMPANY_NAME>
Issued by: Go Daddy Secure Certification Authority
Expires: Sat Jul 23 19:23:39 2016
SHA1 hash: B53404B368EED5A734D332C10702B5D5B5C8E5DE
Successfully verified: mydriver.cat
Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0
The cross certificate part seems to be good. I noticed from a similar output I found online (which was signed from GlobalSign) that the Signing Certificate Chain also led all the way up to Microsoft Code Verification Root. Could this be the problem? And if so how would I go about fixing that?
Installing the .inf goes smoothly, but when I start the driver using
net start mydriver
I get the error:
System error 577 has occurred.
Windows cannot verify the digital signature for this file. A recent hardware or
software change might have installed a file that is signed incorrectly or damage
d, or that might be malicious software from an unknown source.
If I reboot with driver signing enforcement off the above command works fine and the driver works. I have also checked that files in C:\Windows\System32\DriverStore\FileRepository is also signed the same way after installing them.
Does anyone know why the signing does not work, or how I could go about fixing this issue?
Thank you in advance!
I managed to solve my problem, thanks to Ashigore for directing me the right direction.
The problem was related to my intermediate certificates. It seemed like my certificate store was messed up where some intermediate certificates did not have a valid path up to a root CA.
I deleted every certificate that was related to my certificate and started from scratch.
Now the path is correct as:
Microsoft Code Verification Root
Go Daddy Class 2 Certification Authority
Go Daddy Secure Certification Authority
My companies certificate
The Microsoft Code Verification Root was not found at all, and I read somewhere that this certificate is hidden in the kernel somewhere and can not be found be certmgr. However it is possible to install it from microsoft if need be from here http://www.microsoft.com/pki/certs/MicrosoftCodeVerifRoot.crt
I don't think it is necessary tho...
I signed the driver files using these commands:
"C:\Program Files (x86)\Windows Kits\8.1\bin\x86\signtool" sign /v /ac "Go Daddy Class 2 Certification Authority.cer" /n "MY COMPANY" /t http://timestamp.verisign.com/scripts/timestamp.dll mydriver.cat
"C:\Program Files (x86)\Windows Kits\8.1\bin\x86\signtool" sign /v /ac "Go Daddy Class 2 Certification Authority.cer" /n "MY COMPANY" /t http://timestamp.verisign.com/scripts/timestamp.dll mydriver.sys
New output from verification command:
Verifying: mydriver.sys
File is signed in catalog: kaac.cat
Hash of file (sha1): 0AFAFD987F9C4B1D0BCBBD7851C0EA89AEF413C0
Signing Certificate Chain:
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 15:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3
Issued to: Go Daddy Class 2 Certification Authority
Issued by: Microsoft Code Verification Root
Expires: Sun Aug 27 19:48:23 2023
SHA1 hash: D9612472EF0F2787E2B2D9E063A06B32FA5E333D
Issued to: Go Daddy Secure Certification Authority
Issued by: Go Daddy Class 2 Certification Authority
Expires: Mon Nov 16 03:54:37 2026
SHA1 hash: 7C4656C3061F7F4C0D67B319A855F60EBC11FC44
Issued to: MY COMPANY
Issued by: Go Daddy Secure Certification Authority
Expires: Sat Jul 23 19:23:39 2016
SHA1 hash: B53404B368EED5A734D332C10702B5D5B5C8E5DE
The signature is timestamped: Sat Jul 25 14:14:29 2015
Timestamp Verified by:
Issued to: Thawte Timestamping CA
Issued by: Thawte Timestamping CA
Expires: Fri Jan 01 01:59:59 2021
SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656
Issued to: Symantec Time Stamping Services CA - G2
Issued by: Thawte Timestamping CA
Expires: Thu Dec 31 01:59:59 2020
SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1
Issued to: Symantec Time Stamping Services Signer - G4
Issued by: Symantec Time Stamping Services CA - G2
Expires: Wed Dec 30 01:59:59 2020
SHA1 hash: 65439929B67973EB192D6FF243E6767ADF0834E4
Cross Certificate Chain:
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 15:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3
Issued to: Go Daddy Class 2 Certification Authority
Issued by: Microsoft Code Verification Root
Expires: Sun Aug 27 19:48:23 2023
SHA1 hash: D9612472EF0F2787E2B2D9E063A06B32FA5E333D
Issued to: Go Daddy Secure Certification Authority
Issued by: Go Daddy Class 2 Certification Authority
Expires: Mon Nov 16 03:54:37 2026
SHA1 hash: 7C4656C3061F7F4C0D67B319A855F60EBC11FC44
Issued to: MY COMPANY
Issued by: Go Daddy Secure Certification Authority
Expires: Sat Jul 23 19:23:39 2016
SHA1 hash: B53404B368EED5A734D332C10702B5D5B5C8E5DE
Successfully verified: mydriver.sys
Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0
Not sure why, but when using Code Signing using symantec's timestamp server it sets the expiration for the year 2020. This defeats the purpose of using a timestamp server if my program is still going to expire.
Following is the output when using signtool.exe to verify the timestamp application:
Signature Index: 0 (Primary Signature)
Hash of file (sha1): A6F0CEC09F02900D7977C60A87567031D0D96C7A
Signing Certificate Chain:
Issued to: thawte Primary Root CA
Issued by: thawte Primary Root CA
Expires: Wed Jul 16 19:59:59 2036
SHA1 hash: 91C6D6EE3E8AC86384E548C299295C756C817B81
Issued to: Thawte Code Signing CA - G2
Issued by: thawte Primary Root CA
Expires: Fri Feb 07 19:59:59 2020
SHA1 hash: 808D62642B7D1C4A9A83FD667F7A2A9D243FB1C7
Issued to: My Company
Issued by: Thawte Code Signing CA - G2
Expires: Tue Aug 11 19:59:59 2015
SHA1 hash: E45B4CBFBA095DB9465F2371C161EF500201561B
The signature is timestamped: Wed Oct 22 12:15:44 2014
Timestamp Verified by:
Issued to: Thawte Timestamping CA
Issued by: Thawte Timestamping CA
Expires: Thu Dec 31 19:59:59 2020
SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656
Issued to: Symantec Time Stamping Services CA - G2
Issued by: Thawte Timestamping CA
Expires: Wed Dec 30 19:59:59 2020
SHA1 hash: 6C07453FFDDA08B83707C09B82FB3D15F35336B1
Issued to: Symantec Time Stamping Services Signer - G4
Issued by: Symantec Time Stamping Services CA - G2
Expires: Tue Dec 29 19:59:59 2020
SHA1 hash: 65439929B67973EB192D6FF243E6767ADF0834E4
Successfully verified: SetupGoVivoConsole.exe
Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0
Please note that this certificate is set for 1 year expiry, so it is using a timestamp from the server that Symantec provides. According to the (limited) documentation on this subject, using a timestamp server when signing an application should eliminate the application from expiring after the certificate has expired. According to the information I see above, this is not the case as my application will stop functioning on Tue Dec 29 19:59:59 2020.
The command I am using for signtool is as follows :
signtool.exe sign /f "certificate.pfx" /ac "thawte.crt" /p "mypassword" /t http://timestamp.verisign.com/scripts/timstamp.dll "ExecutableToSign.exe"
The purposes of using time stamping is not to make your signature valid forever. Its purposes it to extend the useful life of your signature, from the usual 1 to 3 years that code-signing certificates are valid, to up to 10 years. This is long enough for most needs -who really thinks their code will be traveling through insecure networks (and therefore in need of code signing)and executing 10 years from now.
A time stamping service does nothing more than signing a hash of your own digital signature, plus the current time (as provided by the time stamping service) with the time-stamping sevice's certificate which they (hopefully) guard a lot better than most users of digital certificates and which has been therefore granted a much longer shelf-life. Long-lived as they are, they are still just digital certificates and for basic security every one of those eventually must expire. Given that computers keep getting more powerful even the most secure algorithms and longest signing keys supported today will eventually be insecure.
Note that the expiration date is nothing more than the longest time a certificate (either your code signing one or the time-stamping one) could be valid for. Even today some time-stamping servers use SHA-1 for signing (e.g. that is what your time-stamping example is using). When that algorithm is no longer trusted (and it shouldn't be too long now), all those SHA-1 time stamps will no longer be trusted. That will happen even if the expiration date hasn't been reached.
You should look into other time-stamping services. There are a few out there that will expire a lot further out and use SHA256
If someone ever comes up with an encryption that can never be broken even as computers get better someone will finally create that "forever" timestamp that you ask for. Don't hold your breath.
Cheers!
I can verify from my painful experience today: an expired timestamp certificate (in my case, Comodo's timestamp cert) will cause Windows (7) to fail the overall code signing check with error 0x80096005.
So yeah, contrary to what's being stated by all cert providers I've looked at, timestamping does not guarantee that your signed executable remains valid in perpetuity.
Look for a timestamp service using a cert. with an expiration date loooong in the future.
According to the information I see above, this is not the case as my application will stop functioning on Tue Dec 29 19:59:59 2020.
Why would it stop functioning? Have you tried it? Try to set date on your computer to 2021 and see what happens. Personally I have not tried it but my colleague did. Windows will still run the program. It will validate the application to the date of signing. TSA server certificate was valid then so it should not be a problem.
If you wouldn't have timestamp on the application's signature that would be a problem. After the certificate of signer expires windows will not run the application. But when using timestamp windows does not care about expiry date of TSA certificate.