I had assumed that the RSA key size would be 256. But it can't.
On trying to generate RSA keystore using keytool it gives error "rsa keys must be at least 512 bits long".
The command used is - "keytool -genkey -alias mydomain -keyalg RSA -keystore RSAkeystore.jks -keysize 256".
This cipher suite defines the key size for the AES algorithm but not for the RSA algorithm. The details about the cipher suite string you provided can be understood by reading RFC 4492
Related
I working on a project that uses JSON Web Tokens (JWT). I already have the code that creates the token that is signed by an RSA algorithm which was created by the openssl genrsa -des3 -out <private key file name>.pem 3076. I want to check the validity of the tokens I produce on the jwt.io website, but i need "[public/private] Key in...X.509 certificate, or JWK string format".
Format of private key:
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,4AE3D092CB847166
(The actual key)
-----END RSA PRIVATE KEY-----
Format of public key:
-----BEGIN PUBLIC KEY-----
(The actual key)
-----END PUBLIC KEY-----
Is there any command/tools that can be used to convert these into X.509 certificates or JWK strings?
I have already tried using the openssl x509 -in <public or private key file name>.pem -inform PEM -out <X509 certificate file name>.der -outform DER command.
That would always return this error:
unable to load certificate
140258002609472: error: 0909006C: PEM routines: get_name:no start line:../crypto/pem/pem lib.c:745: Expecting: TRUSTED CERTIFICATE
All of the commands have been run using the terminal from a replit project. I am not sure if that plays a role or not but I mention it just in case.
Do you use Windows? Check the encoding. Change to UTF-8 through the Notepad and create it.
I'm trying to connect to the Exasol database using Powershell with ADO.NET driver.
I can successfully connect from my Windows 10 PC, but can't from Windows Server 2016.
The error message is:
Error: SSL authentication failed. AuthenticationException: A call to SSPI failed, see inner exception.
Error: Inner exception: The client and server cannot communicate, because they do not possess a common algorithm
Debug: Exasol.EXADataProvider.EXAClientException (0x80004005): TLS connection to host (exadb1) failed: A call to SSPI failed, see inner exception.
at Exasol.EXADataProvider.backend.BackendFactory.ConnectToServer(String hostIp, Int32 serverPort, String serverName, String userFingerprint)
at Exasol.EXADataProvider.backend.BackendFactory.PerformLogin(EXAConnectionStringBuilder connectString)
I checked that TLS 1.2 is enabled on Windows Server.
I thought, maybe Windows Server doesn't have proper Cipher Suites, which Exasol accepts.
Below is what Get-TlsCipherSuite command returns on my computer. Last column shows which Cipher Suites were mentioned in Wireshark log.
Name
Certificate
Cipher
CipherLength
Wireshark
TLS_AES_256_GCM_SHA384
AES
256
TLS_AES_128_GCM_SHA256
AES
128
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
0
Client Hello
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
ECDSA
AES
128
Client Hello
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
RSA
AES
256
Client & Server Hello
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
RSA
AES
128
Client Hello
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
RSA
AES
256
Client Hello
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
RSA
AES
128
Client Hello
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
0
Client Hello
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
ECDSA
AES
128
Client Hello
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
RSA
AES
256
Client Hello
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
RSA
AES
128
Client Hello
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
ECDSA
AES
256
Client Hello
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
ECDSA
AES
128
Client Hello
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
RSA
AES
256
Client Hello
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
RSA
AES
128
Client Hello
TLS_RSA_WITH_AES_256_GCM_SHA384
RSA
AES
256
Client Hello
TLS_RSA_WITH_AES_128_GCM_SHA256
RSA
AES
128
Client Hello
TLS_RSA_WITH_AES_256_CBC_SHA256
RSA
AES
256
Client Hello
TLS_RSA_WITH_AES_128_CBC_SHA256
RSA
AES
128
Client Hello
TLS_RSA_WITH_AES_256_CBC_SHA
RSA
AES
256
Client Hello
TLS_RSA_WITH_AES_128_CBC_SHA
RSA
AES
128
Client Hello
TLS_RSA_WITH_3DES_EDE_CBC_SHA
RSA
3DES
168
Client Hello
TLS_RSA_WITH_NULL_SHA256
RSA
0
TLS_RSA_WITH_NULL_SHA
RSA
0
TLS_PSK_WITH_AES_256_GCM_SHA384
0
TLS_PSK_WITH_AES_128_GCM_SHA256
AES
128
TLS_PSK_WITH_AES_256_CBC_SHA384
AES
256
TLS_PSK_WITH_AES_128_CBC_SHA256
AES
128
TLS_PSK_WITH_NULL_SHA384
0
TLS_PSK_WITH_NULL_SHA256
0
Here is result of Get-TlsCipherSuite command on Windows Server 2016. Last column shows which Cipher Suites were mentioned in Wireshark log.
Name
Certificate
Cipher
CipherLength
Wireshark
TLS_AES_256_GCM_SHA384
0
TLS_AES_128_GCM_SHA256
0
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
ECDSA
AES
256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
ECDSA
AES
128
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
RSA
AES
256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
RSA
AES
128
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
RSA
AES
256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
RSA
AES
128
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
0
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
ECDSA
AES
128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
RSA
AES
256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
RSA
AES
128
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
ECDSA
AES
256
Client Hello
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
ECDSA
AES
128
Client Hello
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
RSA
AES
256
Client & Server Hello
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
RSA
AES
128
Client Hello
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
RSA
AES
256
Client Hello
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
RSA
AES
128
Client Hello
TLS_RSA_WITH_AES_256_GCM_SHA384
RSA
AES
256
TLS_RSA_WITH_AES_128_GCM_SHA256
RSA
AES
128
TLS_RSA_WITH_AES_256_CBC_SHA256
RSA
AES
256
TLS_RSA_WITH_AES_128_CBC_SHA256
RSA
AES
128
TLS_RSA_WITH_AES_256_CBC_SHA
RSA
AES
256
Client Hello
TLS_RSA_WITH_AES_128_CBC_SHA
RSA
AES
128
Client Hello
TLS_RSA_WITH_3DES_EDE_CBC_SHA
RSA
3DES
168
Client Hello
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
0
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
DSA
AES
128
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
DSA
AES
256
Client Hello
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
DSA
AES
128
Client Hello
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
DSA
3DES
168
Client Hello
TLS_RSA_WITH_RC4_128_SHA
RSA
RC4
128
Client Hello
TLS_RSA_WITH_RC4_128_MD5
RSA
RC4
128
Client Hello
TLS_RSA_WITH_NULL_SHA256
RSA
0
TLS_RSA_WITH_NULL_SHA
RSA
0
TLS_PSK_WITH_AES_256_GCM_SHA384
0
TLS_PSK_WITH_AES_128_GCM_SHA256
AES
128
TLS_PSK_WITH_AES_256_CBC_SHA384
AES
256
TLS_PSK_WITH_AES_128_CBC_SHA256
AES
128
TLS_PSK_WITH_NULL_SHA384
0
TLS_PSK_WITH_NULL_SHA256
0
For some reason lists of Cipher Suites in Powershell and Wireshark don't match.
Do you know how to "activate" Cipher Suites on Windows Server? Why some of them are not used? Looks like Exasol would like to use TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, but Windows Server for some reason can't use it.
You can use Enable-TlsCipherSuite to add additional ciphers to your server.
Enable-TlsCipherSuite -Name "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
The above in an elevated powershell instance should give you an idea of where to go next
After all, setting SystemDefaultTlsVersions and SchUseStrongCrypto registry keys helped.
https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls#systemdefaulttlsversions
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
Before this change, [System.Net.ServicePointManager]::SecurityProtocol was returning Ssl3, Tls. After the change it started to return SystemDefault. And no more errors occur.
Also, I checked, now TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 cipher suite is used now.
Thanks to everyone for your help.
Try enforcing the tls protocol at the start of your script:
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12 -bor [System.Net.SecurityProtocolType]::Tls13
I have a keystore, which contains only 1 keypair (foo). From that keypair, I generated a csr, which was signed by a CA using the certificate bar (bar is the issuer of foo). The issue I have is that I'm unable to import back the certificate foo in my keystore with this command
keytool -importcert -alias foo -file foo.p7b keypass 123456 -keystore keystore.jks -storepass 123456
It failed with the error
Failed to establish chain from reply.
If add the public certificate bar in my keystore, then it is working fine.
Therefore, one will simply think that I absolutely need to insert the public certificate bar in my keystore, but what is bugging me here is that if I use KeyStore Explorer to import the certificate foo in my keystore (which is only containing the keypair foo), then it is working fine. In other word, I able to import the certificate with KeyStore Explorer ("Import CA reply"), but not keytool.
Is anyone have an idea what I'm doing wrong ?
I'm trying to upload an SSL certificate for a custom domain in Bluemix, but I'm getting a generic error:
BXNUI2081E: An unknown error occurred when modifying certificates and keys: local:///deploySNIArtifacts/mbaasUtilities.xsl:793: Type of the left-hand side of / operator must be a nodeset..
I've followed the documentation, using openssl to generate a self-signed certificate, using the wildcard form of my domain. Any ideas on what I might have missed?
Here's a slightly redacted version of the output from the certificate:
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 17167458275182091963 (0xee3f10581c919ebb)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=Massachusetts, L=Littleton, O=IBM, OU=CLMServices, CN=*.clmsvcs.ibmcloud.com/emailAddress=<email removed>
Validity
Not Before: Apr 19 13:36:39 2016 GMT
Not After : May 19 13:36:39 2016 GMT
Subject: C=US, ST=Massachusetts, L=Littleton, O=IBM, OU=CLMServices, CN=*.clmsvcs.ibmcloud.com/emailAddress=<email removed>
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
<<data removed>>
Exponent: 65537 (0x10001)
Signature Algorithm: sha1WithRSAEncryption
<<data removed>>
The only case I've seen this error was when the private key you are using does not match the certificate.
You can run the following 2 commands to check if the private key and certificate you are trying to upload match:
openssl x509 -noout -modulus -in certificate.crt | openssl md5
openssl rsa -noout -modulus -in privateKey.key | openssl md5
Output from both commands needs to be the same.
This problem went away after a few days. I was able to upload the keys successfully.
I have a program that create self-sign certificate of RSA algorithm.
The problem is that if I create certificate of RSAES OAEP parameters,
when I open the certificate I see that the size of the public key is 0 bits .
Do anyone know what is the problem?
I already checked that the ASN 1.0 Encoding of the RSA OAEP Pararmeters is ok.
And if I create certificate RSA without OAEP Parameters than the size of the public key is present ok (not as 0 bits).
I checked in the internet and I didn’t find any certificate of RSA with OAEP pararms for example to compare with my certificate.
I will be glad for any suggestion.
This is the certificate in PEM File:
-----BEGIN CERTIFICATE-----
MIIFyzCCA7OgAwIBAgIDMaTyMA0GCSqGSIb3DQEBBAUAMG0xETAPBgNVBAMTCFN0YW0gSXNo
MRQwEgYDVQQHEwtQZXRhaCBUaWt2YTEPMA0GA1UECBMGSXNyYWVsMQwwCgYDVQQKEwNBUlgx
FjAUBgNVBAsTDVByaXZhdGVTZXJ2ZXIxCzAJBgNVBAYTAklMMB4XDTAwMDEwMTEwMDAwMFoX
DTk5MTAxMzIxNTYxNVowbTERMA8GA1UEAxMIU3RhbSBJc2gxFDASBgNVBAcTC1BldGFoIFRp
a3ZhMQ8wDQYDVQQIEwZJc3JhZWwxDDAKBgNVBAoTA0FSWDEWMBQGA1UECxMNUHJpdmF0ZVNl
cnZlcjELMAkGA1UEBhMCSUwwggJnMFIGCSqGSIb3DQEBBzBFoA8wDQYJYIZIAWUDBAIBBQCh
HDAaBgkqhkiG9w0BAQgwDQYJYIZIAWUDBAIBBQCiFDASBgkqhkiG9w0BAQkEBVRDUEEAA4IC
DwAwggIKAoICAQCizEvm86uS4/f8e7EC81OqNK+fIoCWOYJdc7iDNEbI+7l9C/zD//KiETMD
x1V4WgBXvhokc05a0oLdJ8MlcTFUGsmrX8mxesGnY87wVeJBJ+jPQipZ+ZoA16U9d4xOQU8b
erXUf+w6VFwoL4M3jLyL2lspHiMJPagsukxjzh1Dj/xA6tIVsSnJkffDyRC9l267pP1mXi2u
vAT4zhSX1FLtoO3XkJ0pJarIyJeTnBLMQ5ga1gnDmUFve4tI/cLbb9fxeTF7zA+XNrTTdYrY
9zkiMXBvnT7h0ZpGhfvobC7ULbmO/XyR3tVmuMoTu9mwNgjwCgp5f5Jt7cZbUJNbBateglcv
+Gb9FjFjneCRU4adN87GpyAMfclq5MIO+KCoRWSDRbL/6exYMf0sE3g4ARSru/7Wm82xITNA
fRn2qDErR421SiiuwkIlh97eiyfYeEb+n5eSOr1Qscr+tXOpEuArBDPzg0g5fo0dgomAVZvK
hwfOS+URUmobRPuUN5ecB4dALBJkkN02qaGkCXZmzWicnheXmhTYe3og0fQpajFXUwgwguXl
CDfy91Tn9PBYdRs0G0/gkiRABTP3sZvG3ru9I20W9tdfvN3NssBb+2AadRhSvpgP1wkHIVmZ
/VOQN893TdmaS+WQOiocxh2LxJv7QeC8j8fi9k8LTeM4JCqJ0wIDAQABoy8wLTArBgNVHRAE
JDAigA8xOTk4MDEwMTA4MDAwMFqBDzIwMDAwMTAxMDgwMDAyWjANBgkqhkiG9w0BAQQFAAOC
AgEAODPOHhl4J519jEExA2TIwSWLC23lloBQQPJysE0gelbyTv3xGVmJJZF+JAGvxrkvYado
UMPc9pBF57RsB7tznhCHpcYpSRcEIEArZoxfiVkevheLsm9/gyd5RA/oD6xx8WZBFFjHW+fs
urdJPEfR0lBHGmOKBKTa9aeqwJ5Bfi6Rm6/OvbalWBgZh2+5KYhdtMZH7JnsCCR6ZrJzLp8D
uo5M0iIQ/J6D9pDsPBmYK3/P/c7mVhLhjUBtqelkRGO690VzoBykf9MsWE3IT58gq1Av3dGe
J1LSgijha65s/A+l7zEC0fL7UFSXUnNCghEz+PkpcO14wFeg9UIypM0R85IOO0PBg4FVLACT
hmBmFFJCDOCgMwO+xMQZE+eG5gOEUgESHaQfEUoU7JxPHYB/9Xxl2G69nHr2Fx0KuLrjnrym
SgrFubQ3d+XuSTLxr/Lr7gl7EZP68uEsPcw2CXXdpsq4pvmVbrNspfHGn9SimFkEA8qmPqkt
4wiUPCwLkvY+qZ55JnmtPWoeaekJDx7iox0TtiHlQH6Y+/Rl18zU0lITePKPbc5thPZjiwIl
rR5O1PYzlIzE9m/7mFNitIAR2CixJRNiykgz5Q2gjYu4itmb2aHE1UuzK2mORny2gYnG7mdr
dD2y8hDouRCuxND/kkfdDyspGSRQcnqnmpkt7nQ=
-----END CERTIFICATE-----
Public key is 4096 bits long in the attached certificate. Using MD5 hash with 4k keys is very strange combination as MD5 hash is too weak and all strength of 4k key is eliminated by weakness of a hash.