Linux Mint 21
Success install openvpn.
OpenVPN 2.5.5 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 22 2022
Now want to connect to remote setup via openvpn.
sudo openvpn Leo.ovpn
but get error:
2022-08-15 09:29:10 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2022-08-15 09:29:10 --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
2022-08-15 09:29:10 WARNING: file 'client.key' is group or others accessible
2022-08-15 09:29:10 OpenVPN 2.5.5 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Mar 22 2022
2022-08-15 09:29:10 library versions: OpenSSL 3.0.2 15 Mar 2022, LZO 2.10
2022-08-15 09:29:10 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
2022-08-15 09:29:10 OpenSSL: error:0A00018E:SSL routines::ca md too weak
2022-08-15 09:29:10 Cannot load certificate file client.crt
2022-08-15 09:29:10 Exiting due to fatal error
P.S. I check folder. Exist files: client.crt and ca.crt
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
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
I am using WebSphere 6.1 server.
In my application, we use web services for the communication of standalone client(Swing) with web part.
From web part, we use WebSphere MQ to communicate with the Pro*C part. When we trigger a button in client part, the web is called which in turn invokes the MQ for a response.
We face the below error when we do the above operation:
LTPAServerObj W SECJ0371W: Validation of the LTPA token failed because the token expired with the following info: Token expiration Date: Thu Nov 20 07:56:12 CET 2014, current Date: Thu Nov 20 13:58:28 CET 2014.
SRTServletRes W WARNING: Cannot set header. Response already committed.
LTPAServerObj W SECJ0371W: Validation of the LTPA token failed because the token expired with the following info: Token expiration Date: Thu Nov 20 08:06:03 CET 2014, current Date: Thu Nov 20 14:01:36 CET 2014.
The MQ responses are OK as we trace the logs.
My Question:
Does this LTPA token expiration prevent my websphere server from sending the SOAP response to client part?
I have added two certificates into my server's(jboss) keystore with domain name in both as "localhost". So now if a local client accesses the server which of the certificates will be sent to the client.
There is no error thrown in jboss, and it is working fine. I just want to know how jboss is choosing which certificate to send?
Listing the contents of the truststore used by java program.
Your keystore contains 2 entries
tomcat, 5 Mar, 2012, trustedCertEntry,
Certificate fingerprint (SHA1): B0:F0:98:5F:E5:D0:D6:24:58:B6:38:07:97:38:95:D5:
AB:28:E1:1E
tomcat1, 6 Mar, 2012, trustedCertEntry,
Certificate fingerprint (SHA1): C4:2B:E8:14:F9:85:5A:05:F2:1F:58:AE:65:FB:0E:8F:
DD:23:97:87
both tomcat and tomcat1 have the cn=localhost
Listing the contents of the keysttore used by jboss.
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 2 entries
tomcat, 5 Mar, 2012, PrivateKeyEntry,
Certificate fingerprint (SHA1): B0:F0:98:5F:E5:D0:D6:24:58:B6:38:07:97:38:95:D5:
AB:28:E1:1E
tomcat1, 6 Mar, 2012, PrivateKeyEntry,
Certificate fingerprint (SHA1): C4:2B:E8:14:F9:85:5A:05:F2:1F:58:AE:65:FB:0E:8F:
DD:23:97:87<br>
Displaying the keystore entry using th keytool's list "-v" option asper Kevin's request.
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 2 entries
Alias name: tomcat
Creation date: 5 Mar, 2012
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=localhost
Issuer: CN=localhost
Serial number: 5aaac34c
Valid from: Mon Mar 05 15:04:46 IST 2012 until: Sun Jun 03 15:04:46 IST 2012
Certificate fingerprints:
MD5: 6A:9D:10:37:4F:98:7F:85:D5:93:95:CC:C3:84:07:D8
SHA1: B0:F0:98:5F:E5:D0:D6:24:58:B6:38:07:97:38:95:D5:AB:28:E1:1E
SHA256: FB:F5:BC:9F:17:E9:28:8C:77:1B:40:17:8B:D3:12:71:05:0D:CF:9C
99:00:C4:25:76:46:CE:E0:0C:E6:6B
Signature algorithm name: SHA256withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: F6 B3 2E B5 A0 76 78 7E 9D B6 2A D6 4A 6A 8D 96 .....vx...*.Jj..
0010: FA 7D 47 9B ..G.
]
]
*******************************************
*******************************************
Alias name: tomcat1
Creation date: 6 Mar, 2012
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=localhost
Issuer: CN=localhost
Serial number: 4891416
Valid from: Tue Mar 06 06:41:21 IST 2012 until: Mon Jun 04 06:41:21 IST 2012
Certificate fingerprints:
MD5: B9:31:FE:75:E9:28:E6:BC:F2:94:60:93:7B:0C:00:63
SHA1: C4:2B:E8:14:F9:85:5A:05:F2:1F:58:AE:65:FB:0E:8F:DD:23:97:87
SHA256: 58:7B:D3:A1:2C:8E:C1:C9:26:0A:9F:A1:86:D1:79:76:34:D2:83:6A
88:0C:E1:36:F5:88:3F:DC:F7:D7:89
Signature algorithm name: SHA256withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: F1 BF 69 B4 CA D6 9E 72 AC C3 26 9F CD 57 58 7A ..i....r..&..WXz
0010: 62 19 8B B8 b...
]
]
*******************************************
*******************************************
By default, JBoss (or Apache Tomcat) will use the default settings the default X509KeyManager to choose which certificate to use: it will pick the first one it finds in the keystore that is valid for the type of key (e.g. RSA for an RSA-based cipher suite) and at the time of connection.
Failing that, if an alias is explicitly specified in keyAlias, it will pick the certificate in that alias (and it will fail if the key type isn't correct).
If, instead of this, the name of a custom class implementing SSLImplementation is given in the SSLImplementation attribute, it will be used to provide the SSLSocketFactory (so the alias choice will be done however its SSLContext/KeyManager is configured).
Support for Server Name Indication (SNI), which is what would allow the key manager to use the requested host name to help make a choice, was only introduced in Java 7, and only on the client side, so the JSSE cannot use it on the server side currently.
What exactly are you trying to achieve ? The certs are stored in the keystore and presented to the user based on hostname match. This is incorrect, please see below.
Logically speaking it would load only one of these which in turn will be served to the user.
--Edit--
Trying to simplify by pointing to another link
Say you specify "keyAlias" in your jboss configuration to "tomcat" ; then the tomcat alias will be picked up
If you do not specify an alias then the "first key read in the keystore will be used"