I am generating JWT token from WSOAM which is then passed as a header to API. I have my API created in nodejs and I am using jsonwebtoken plugin to verify and decode the JWT.
I am unable to find RSA Public key of Wso2carbon to verify/decode the token.
Please help me as how to generate the RSA Public key or where should I find this key ?
All WSO2 products use the default public/private key pairs installed into wso2carbon.jks keystore file found in <WSO2_AM>/repository/resources/security directory. It's advised to use your own keystore instead of this default keystore shipped with all WSO2 products.
It is recommended to replace this default keystore with a new keystore
that has self-signed or CA signed certificates when the products are
deployed in production environments. This is because wso2carbon.jks is
available with open source WSO2 products, which means anyone can have
access to the private key of the default keystore.
If you are going to use the default private/public keys, use the following command to extract the key.
keytool -export -keystore <WSO2_AM>/repository/resources/security/wso2carbon.jks -alias wso2carbon -file Example.cer
Related
I generated a keypair in Cloud HSM by giving a keystore file.
I downloaded the keystore file and opened it in keystore explorer and I see symmetric and asymmetric key entries. As per AWS documentation, only the certificate corresponding to keypair is stored in the local keystore file.
I exported the private key but it is not complete.
As the expected public is exportable and complete.
I assume, Cloud HSM maintains a reference to all the entries with partial key info. Is it correct?
Generate keypair with a certificate with store file
keytool -genkeypair -alias alias1 -keystore /home/user/my_cloudhsm/my-cloudhsm.store "CN=alias1.example.com, OU=Research, O=Acme, L=XYZ, ST=CA, C=US" -storetype CLOUDHSM -storepass password -keyalg rsa -keysize 2048 -sigalg sha512withrsa -validity 360 -dname -J-classpath '-J/opt/cloudhsm/java/*' -J-Djava.library.path=/opt/cloudhsm/lib
I still haven't been able to solve this problem..
when I call the API from "Tryout" in Publisher, it comes out like the error message below. No matter how much I regenerate the key, it keeps saying that it is not valid.
Please help me on this.
Command
curl -X 'GET' \
'https://xxxxx:8243/systemname/1.0.0/AMTSrestapi/api/getdoclist' \
-H 'accept: */*' \
-H 'Internal-Key: eyJraWQiOiJnYXRld2F5X2NlcnRpZmljYXRlX2FsaWFzIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiI0ODM3MDlAY2FyYm9uLnN1cGVyIiwiaXNzIjoiaHR0cHM6XC9cL3Nnc2RpYXBpbDAwMS5zZWFnYXRlLmNvbTo5NDQzXC9vYXV0aDJcL3Rva2VuIiwia2V5dHlwZSI6IlBST0RVQ1RJT04iLCJzdWJzY3JpYmVkQVBJcyI6W3sic3Vic2NyaWJlclRlbmFudERvbWFpbiI6bnVsbCwibmFtZSI6IkdBTVRTIiwiY29udGV4dCI6IlwvZ21hdHNcLzEuMC4wIiwicHVibGlzaGVyIjoiNDgzNzA5IiwidmVyc2lvbiI6IjEuMC4wIiwic3Vic2NyaXB0aW9uVGllciI6bnVsbH1dLCJleHAiOjE2MzM3MzI3MjgsInRva2VuX3R5cGUiOiJJbnRlcm5hbEtleSIsImlhdCI6MTYzMzY3MjcyOCwianRpIjoiNDg2YmY4MmItYTMyYi00ZWQ1LTk4NDItNmE4ODU5OTZkZWU4In0.n_DPcyZ7DfPwc_nQTbSB6buHQnacAHGAWsIqVE0UvezrFjF5wu9mQ0UGPO8rBzN_uABoEpscR1PxI5A0LLicP566_H61hwl2hy4dUvYhZwVrCLVneBCxlmO4o9b3d1nJcOcsBf9zAmUDn3_M0K-yBxVrXYZuiA3FFRBK0YyzZQAmhmUatVvh_D7gTXVHR2STYeaRYPqSalbxxyaWLCzhD2sY66BdSD2q476dmXGhYMYTRuMFZrqiALcdhlZpdjAlTHJz0G7q6rCv5EHzuUnGRpBvNaYzzQPjYmHYIBf7RKfXjHMXlHQIp7KCdi9WbrLIUYvQ-Tj5a5v8BVv1d8wW6Q'
Error message.
{
"code": "900901",
"message": "Invalid Credentials",
"description": "Invalid Credentials. Make sure you have provided the correct security credentials"
}
wso2carbon.log
Log file [2021-10-06 13:50:07,068] ERROR - InternalAPIKeyAuthenticator Invalid Internal Key.XXXXXUlMyNTYifQ [2021-10-06 13:50:07,069] WARN - APIAuthenticationHandler API authentication failure due to Invalid Credentials
https://i.stack.imgur.com/uHbWF.png
The mentioned error can occur when the API Manager was not able to validate or verify the Signature of the Internal Key access token.
Explanation
The API Manager generates the Internal Key access token (a JWT Token) and signs it with the private key of the Primary Keystore (which is configured under keystore.primary with alias).
During the validation process, the API Manager searches for the public cert of the specific private key using the alias gateway_certificate_alias (this can be configured as well from the TOML).
Hence, if the default shipped Keystore is changed or replaced and the Primary Keystore configurations are updated in the TOML, then it is also required to export and import the public certificate of the relevant private key with the alias gateway_certificate_alias to the client-truststore.jks.
Recovery Steps
*Go through the question comments to understand the steps and shared information
As per the shared information, you have generated a new Keystore with an existing cert for the SSL communication and have replaced the wso2carbon.jks as well as configured the new keystore in the TOML configurations. Therefore, it is required to update the public certs in the client-truststore with relevant credentials.
Follow the given steps to update the cert that has been aliased as gateway_certificate_alias in the client-truststore.jks
Export the public cert of your new Keystore (enter the Keystore password when prompted)
keytool -export -alias apimanagercert7 -file wso2.crt -keystore newkeystore7.jks
Import the public cert to the client-truststore with the alias gateway_certificate_alias (enter the Truststore password when prompted)
keytool -import -trustcacerts -keystore client-truststore.jks -alias gateway_certificate_alias -file wso2.crt
If you get any errors when trying to import the certs to the truststore mentioning the alias exists, then execute the following command to delete the alias and perform the above-given steps again to import it
keytool -delete -alias gateway_certificate_alias -keystore client-truststore.jks
After performing the steps, restart the API Manager server and try invoking the API using the Internal Key from the Publisher portal.
I need the public key certificate that Amazon cognito uses so my web app can verify the cognito JWT.
Is there anyway to get the public key certificate or do you have to use the cognito SDK to achieve this?
Use the get-signing-certificate method from AWS CLI to get the contents of the public x509 certificate for Cognito. Here is a sample command:
aws cognito-idp get-signing-certificate --user-pool-id ca-central-1_xxxxxxxxx
You will get a single line with the base64-encoded certificate. Surround that with the standard markers of -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----. The end result will look like this:
-----BEGIN CERTIFICATE-----
MIICdzCCAeCgAwIBAgIGANc+Ha2wMA0GCSqGSIb3DQEBBQUAMFMxCzAJBgNVBAYT
AlVTMRMwEQYDVQQKEwpBbWF6b24uY29tMQwwCgYDVQQLEwNBV1MxITAfBgNVBAMT
GEFXUyBMaW1pdGVkLUFzc3VyYW5jZSBDQTAeFw0wOTAyMDQxNzE5MjdaFw0xMDAy
MDQxNzE5MjdaMFIxCzAJBgNVBAYTAlVTMRMwEQYDVQQKEwpBbWF6b24uY29tMRcw
FQYDVQQLEw5BV1MtRGV2ZWxvcGVyczEVMBMGA1UEAxMMNTdxNDl0c3ZwYjRtMIGf
MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCpB/vsOwmT/O0td1RqzKjttSBaPjbr
dqwNe9BrOyB08fw2+Ch5oonZYXfGUrT6mkYXH5fQot9HvASrzAKHO596FdJA6DmL
ywdWe1Oggk7zFSXO1Xv+3vPrJtaYxYo3eRIp7w80PMkiOv6M0XK8ubcTouODeJbf
suDqcLnLDxwsvwIDAQABo1cwVTAOBgNVHQ8BAf8EBAMCBaAwFgYDVR0lAQH/BAww
CgYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQULGNaBphBumaKbDRK
CAi0mH8B3mowDQYJKoZIhvcNAQEFBQADgYEAuKxhkXaCLGcqDuweKtO/AEw9ZePH
wr0XqsaIK2HZboqruebXEGsojK4Ks0WzwgrEynuHJwTn760xe39rSqXWIOGrOBaX
wFpWHVjTFMKk+tSDG1lssLHyYWWdFFU4AnejRGORJYNaRHgVTKjHphc5jEhHm0BX
AEaHzTpmEXAMPLE=
-----END CERTIFICATE-----
There is no certificate chain on a Cognito JWK. The public JWK for your Cognito can be found here:
https://cognito-idp.{region}.amazonaws.com/{userPoolId}/.well-known/jwks.json
You can decode the JWK into a PEM Public Key format using a library such as https://www.npmjs.com/package/jwk-to-pem
var jwkToPem = require('jwk-to-pem');
var jwk = JWK_FROM_URL,
pem = jwkToPem(jwk);
Or you could do the complete verification using something like https://github.com/cisco/node-jose
jose.JWK.asKey(keys[key_index])
.then(result => jose.JWS.createVerify(result).verify)
.then(result => JSON.parse(result.payload))
There's a detailed guide to decoding Cognito JWT here https://aws.amazon.com/premiumsupport/knowledge-center/decode-verify-cognito-json-token/, with an sample of using jose on Cognito JWT's here: https://github.com/awslabs/aws-support-tools/blob/master/Cognito/decode-verify-jwt/decode-verify-jwt.js
There is no direct option available but you can do a workaround in openSSL,
Generate a private key and generate a Certificate signing request(CSR) using the available private key. Both can be done in a single line
openssl req -new -newkey rsa:2048 -nodes -keyout PrivateKey_FileName.key -out CSR_FileName.csr
Save the PublicKey from cognito in .pem format. You can convert from jwk to .pem using the online tool https://8gwifi.org/jwkconvertfunctions.jsp.
Self sign the CSR using the generated private key and force the CA to include your custom Public key saved in .pem format to create a certificate replacing whatever public key available when you have generated your CSR request, using the following command.
openssl x509 -req -days 1200 -in CSR_FileName.csr -force_pubkey cognito_publicKeyFileName.pem -signkey PrivateKey_FileName.key -out export_certificate_FileName.crt
Boom..you have created your x509 certificate with the public key from cognito
I'm trying to encrypt TLS traffic in transit between EMR nodes. The example on the AWS website uses a self-signed certificate.
Because this is all within my private network, I have generated a root CA certificate with a private key that is tightly secured. I then have a derived certificate which can perform key encipherment", digital signature, and server auth.
Let's call the root CA certificate A, and the derived certificate B.
EMR says that I need to upload a zipfile to s3 containing 2 required files and one optional file:
privateKey.pem is required,
certificateChain.pem is required
and trustedCertificates.pem is optional
For privateKey.pem, I assume I can just use the private key associated with certificate B.
For certificateChain.pem, do I need the contents of the certificate B concatenated with certificate A or do I just need the contents of certificate A?
For trustedCertificates.pem do I need the contents of certificate A or of certificate B?
If you follow this AWS script as per the documentation you will find that trustedCertificates.pem and certificateChain.pem are the same file (via a file copy).
openssl req -x509 -newkey rsa:2048 -keyout privateKey.pem -out certificateChain.pem -days 365 -nodes -subj '/C=US/S=Washington/L=Seattle/O=MyOrg/OU=MyDept/CN=*.ec2.internal'
cp certificateChain.pem trustedCertificates.pem
zip -r -X certs.zip privateKey.pem certificateChain.pem trustedCertificates.pem
EMR Create Certificate Script
You are complicating things by creating a root certificate, which is not necessary. Follow the AWS documentation on setting up TLS on EMR:
Secure Amazon EMR with Encryption
The zip file that you upload to S3 contains three files, privateKey.pem, certificateChain.pem and trustedCertificates.pem. Two of which are the same file with different names.
[EDIT after a very long comment thread on certificates]
When you create a self signed root certificate, all certificates that it signs are also self signed. A certificate is verified by verifying each certificate up the chain to the root. If the root certificate is untrusted, then all certificates are untrusted.
AWS offers a certificate management service where you can be your own CA. However, this is very expensive. If you are a large company, a bank or financial institution, etc. then this AWS service is very useful.
For Amazon EMR, using a single self signed certificate is OK. The reasoning is that you are in full control over the systems that are using the certificate. You would not want to use a self signed certificate if any part of the system is providing public access.
One item that confused the OP is the difference between a trusted certificate and the certificate chain. In his example, since their is only the root certificate and not intermediary certificates, the trusted and chain are the same item. Only if he had created another signing certificate that was used to sign the last certificate would the certificate chain be different (there would be the root certificate and the signing certificate).
I am trying to implement Allow only trusted devices feature on AWS Workspaces with simple AD.
Can someone please guide me how to generate self-signed root & client certificate with following features.
Certificates must be Base64-encoded certificate files in CRT, CERT, or PEM format.
Certificates must include a Common Name.
The maximum length of certificate chain supported is 4.
Amazon WorkSpaces does not currently support device revocation mechanisms, such as certificate revocation lists (CRL) or Online Certificate Status Protocol (OCSP), for client certificates.
Use a strong encryption algorithm. We recommend SHA256 with RSA, SHA256 with CEDSA, SHA381 with CEDSA, or SHA512 with CEDSA.
You need to create CA first:
SERVER_NAME=fred
DOMAIN_NAME=domain.local
export $SERVER_NAME $DOMAIN_NAME
openssl genrsa -out CA_$SERVER_NAME.$DOMAIN_NAME.key 2048
openssl req -x509 -new -nodes -key CA_$SERVER_NAME.$DOMAIN_NAME.key -sha256 -days 1024 -out CA_$SERVER_NAME.$DOMAIN_NAME.pem -subj "/C=GB/ST=MyCounty/L=MyTown/O=MyOrganisation/OU=MyOrganisationUnit/CN=$SERVER_NAME.$DOMAIN_NAME
Then you can create certificates signed from the CA you just created.
openssl genrsa -out $SERVER_NAME.$DOMAIN_NAME.key 2048
openssl req -new -key $SERVER_NAME.$DOMAIN_NAME.key -out $SERVER_NAME.$DOMAIN_NAME.csr -subj "/C=GB/ST=MyCounty/L=MyTown/O=MyOrganisation/OU=MyOrganisationUnit/CN=$SERVER_NAME.$DOMAIN_NAME.client"
openssl x509 -req -in $SERVER_NAME.$DOMAIN_NAME.csr -CA CA_$SERVER_NAME.$DOMAIN_NAME.pem -CAkey CA_$SERVER_NAME.$DOMAIN_NAME.key -CAcreateserial -out $SERVER_NAME.$DOMAIN_NAME.crt -days 365 -sha256
Now you have a CA and a certificate created, you can test that the certificate is created from the CA by running:
openssl verify -CAfile CA_fred.domain.local.pem fred.domain.local.crt
Thanks #IchingChang, article https://www.brunton-spall.co.uk/post/2020/04/28/Using-AWS-Workspaces/ is really helpful.
For future readers, if you still struggling with this problem, also try with bruntonspall's github link: https://github.com/bruntonspall/AWSWorkspacesCA
The following step is create all keys and certificates in same machine (CA machine), for prod use case, you should create client public and private key in client machine:
(only do this step if you want to renew or did not create and upload your CA public key before) run ./CA/gen_CA.sh, which will generate CA's private and public key, copy the public key (.pem file) and upload it onto AWS Workspaces's Directory Service's Access Control Options (https://docs.aws.amazon.com/workspaces/latest/adminguide/trusted-devices.html#configure-restriction).
run ./client/gen_client.sh, which will generate client private and public key and corresponding CA sign certificate.
copy pfx (or say p12) certificate file to your windows laptop, click install, select current user and personal store.
Now you should be able to login with your workspaces client (suppose you already setup AWS Workspaces side correctly with other settings).