I got into very odd situation were im not able to create JWT sign token in sap netweaver server.
currently the encryption is done using p12 file instead of pem file in sap server.
Docusign only provide the RSA key in .pem format. Which at the moment is not feasible for me.
Is there a way to download/create RSA key in .p12 format like it is provided in google api's instead of text/pem format or how can we create JWT sign token using RSA private key in .pem format in sap netweaver server.
Thanks and regards,
Rahul.
DocuSign creates the public/private key pairs for JWT signing. You download the private key in pem format from DocuSign. Something like this:
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAuv1+cIU9ashbXUxkJXzsqoeN3rNjcwcRMI17njwHpOh+ljV6
CNLRu+VAvtFdluK/TN+idb7jlFBe2CIdNbev/sYX1lB0+zJw1vsgSSk31d9vdPQb
n5R0FZUTsAYXv27JB6kc5N/6n2uroeNmeABkZZTLvXSmibYOjVYeB+Ig5HBS2Xxw
...lines omitted...
O2F4bIUOh1pdRydwHH0bMLXfyqn7sOxdEJwIq6Is5DwKeLJUEyfiuaGGjHQBfs+u
eoySeQKBgQC1aRTK4g4c5dgxdywCRTje/kUh5Ion6vFLLrTmEKtV9LFyFvLtFrVL
iX9G3qm0a3raSNwXylfbs88tPDrTGaTEM2opt5YpDWExpS7sLknDQxGcCzgyjTqc
/p6p+tOzgoc+osBMCNvBPS8tEAmdfTk7LFxVh8UY49JIpwoAnJ7c5Q==
-----END RSA PRIVATE KEY-----
Converting to p12 format
You can run open source applications locally to do this conversion.
There are also online converters available. See google for a list.
Related
Examples using powershell use [Security.Cryptography.X509Certificates.X509Certificate2] to sign data. The data present here is in the form of what I believe is a Json Web Key (JWK).
How do you convert a JWK to a compliant cert that can be used by X509Certifate2?
https://www.googleapis.com/oauth2/v1/certs gives you the X509 certificates in PEM format, but I believe this endpoint is deprecated.
I am trying to validate how one uses the nifty debugger at jwt.io to validate a JWT but I cannot find out how to format the public key so that it works in that "debugger".
The answer turns out to be the PEM format of the key--specifically the text between
-----BEGIN CERTIFICATE-----
and
-----END CERTIFICATE-----
inclusive. Transforming into the PEM format can be done using Java's keytool along with the openssl tool. The details of the transformation can be found elsewhere.
I have a use case for a .NET application that stores certificates in a database. One of the requirements is for the application to reject certificates that contain private keys. The user will upload a certificate file (specifically .CER or .CRT) and the application will import it as an X509Certificate2 object so that I can check the HasPrivakeKey property.
I know that .PFX files can contain private keys, but is it possible for .CER or .CRT files to also contain private keys? If so, how can I generate a test certificate in order to test the application logic?
First, .NET do not support PEM format with private key. But if such format is presented the following outcome is defined:
1) if certificate header/footer is first in the file, .NET will ignore the rest content of the file (e.g. private key information) and creates valid X509Certificate2 object without private key (because PKCS#1 and PKCS#8 keys are not supported by CryptoAPI functions which are called by a X509Certificate2 constructor. Though, there are functions to work with PKCS#1).
2) if private key header/footer is first in the file, .NET will raise exception about invalid certificate.
p.s. this combination is possible only when Base64 encoding is used and each section uses header and footer (e.g. -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----). It is impossible to combine them in binary form without using PKCS#12 container.
update: if you want to test it yourself, here is an example of such PEM file:
-----BEGIN CERTIFICATE-----
MIIEIDCCA+CgAwIBAgIUHSle8379VhDdbksPu2S6q+CkCMQwCQYHKoZIzjgEAzAjMSEwHwYDVQQD
ExhUb2tlbiBTaWduaW5nIFB1YmxpYyBLZXkwHhcNMTMwNzAzMTkzNDIzWhcNMTMwNzEwMTkzNDIz
WjAtMSswKQYDVQQDHiIAYgBiADEANAAxADkAYQAyAGMAZgBjADEAZQAwADAAOAAAMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQDbU9p4AwJy2RZxHYMXKalKv6K6cwrUB2RnFHZbelPgggfJyIZm
kL5pbB7u6tFYCBiNcMR6t8ItfVsi9iL33Uuluov7YZ3DPjRAVx4MZqXN3YR9bhzmOZpMgzKNxzoR
Kdhxy3qWYFAKdYZ9P1ln+9aUGJE3f1MuM7OPg1vWFUZ2VwIDAQABo4ICoDCCApwwDgYDVR0PAQH/
BAQDAgWgMBMGA1UdJQQMMAoGCCsGAQUFBwMCMIIB/wYDVR0gBIIB9jCCAfIwggHuBgorBgEEAYI3
MwMCMIIB3jCCAdoGCCsGAQUFBwICMIIBzB6CAcgATQBpAGMAcgBvAHMAbwBmAHQAIABkAG8AZQBz
ACAAbgBvAHQAIAB3AGEAcgByAGEAbgB0ACAAbwByACAAYwBsAGEAaQBtACAAdABoAGEAdAAgAHQA
aABlACAAaQBuAGYAbwByAG0AYQB0AGkAbwBuACAAZABpAHMAcABsAGEAeQBlAGQAIABpAG4AIAB0
AGgAaQBzACAAYwBlAHIAdABpAGYAaQBjAGEAdABlACAAaQBzACAAYwB1AHIAcgBlAG4AdAAgAG8A
cgAgAGEAYwBjAHUAcgBhAHQAZQAsACAAbgBvAHIAIABkAG8AZQBzACAAaQB0ACAAbQBhAGsAZQAg
AGEAbgB5ACAAZgBvAHIAbQBhAGwAIABzAHQAYQB0AGUAbQBlAG4AdABzACAAYQBiAG8AdQB0ACAA
dABoAGUAIABxAHUAYQBsAGkAdAB5ACAAbwByACAAcwBhAGYAZQB0AHkAIABvAGYAIABkAGEAdABh
ACAAcwBpAGcAbgBlAGQAIAB3AGkAdABoACAAdABoAGUAIABjAG8AcgByAGUAcwBwAG8AbgBkAGkA
bgBnACAAcAByAGkAdgBhAHQAZQAgAGsAZQB5AC4wUwYDVR0jBEwwSoAUaISoloVlkV/P4JGkgUGj
gzjrVSChJ6QlMCMxITAfBgNVBAMTGFRva2VuIFNpZ25pbmcgUHVibGljIEtleYIJAKs+FSwkyech
MB0GA1UdDgQWBBQQOhVxyI6GdpyHsij3PQU1ep0k7DAJBgcqhkjOOAQDAy8AMCwCFAPO2/xwhf37
xELxJhiMFEGvQXmgAhRNgAk/L2YWq1SlQ7Ax/XH5c8Ep0w==
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
MIICeAIBADANBgkqhkiG9w0BAQEFAASCAmIwggJeAgEAAoGBANtT2ngDAnLZFnEdgxcpqUq/orpz
CtQHZGcUdlt6U+CCB8nIhmaQvmlsHu7q0VgIGI1wxHq3wi19WyL2IvfdS6W6i/thncM+NEBXHgxm
pc3dhH1uHOY5mkyDMo3HOhEp2HHLepZgUAp1hn0/WWf71pQYkTd/Uy4zs4+DW9YVRnZXAgMBAAEC
gYAKMnja0ZEAk/VGJxAcOJSlZAmFz6l2OC3D2SCzmhliO8lu6ULOa/ZeYmeBxisbg6zYjqCj7/04
LjbZhkYT7hcBNH6lns7yGZzkdly4y0Ud7tjsM+E31Y0Wb7jh/t3pvETUtTUxwhGT5nheiE3iDDj1
RQATdYxAL57Hr5R1+jc5SQJBAPjrJtZN21JJSlrpZIGB2KKrK6thy/oMWGsw1B3TyZWZt1Q06Fe3
MwTrJ1K4YWRyhRy9ib4yqQKMq0mcMqPCMGMCQQDhkTGDSG+lbZnhjop9YwmmJpxiaXZELphc9Tr8
Kf0f6vcfe4mh0OIwpatlqaZiCh5yQwv4GTuwGsRv199f8LJ9AkEA2qeuAPh5XUoWL8/vQrgt9Y7J
GI4a4PaxQM+utNjSrkBOQ4EKS+sYvQxYCZj/rH3QolN4yQO1ZRDucgXskd9GIwJBANk3n+2j6Nfu
trwuLxFWOSmGjxx6IMjB8jm6ckX5DWgaNkZcCgsJA3kDYQ2ylKZexjkUdcdCTWdmL3rg8JwMR2UC
QQCXhPLLIjtcdHzUHjy9dqzPyATduAmD23K7UPBDytFRyNcvUE+0Yfw3Lnvd/wATuUiFqHkhjD4v
qkICcfVum6Yi
-----END PRIVATE KEY-----
when you instantiate an X509Certificate2 object from this file, the call will succeed. Swap sections and you will see exception about invalid format.
An X509 certificate in PEM format is just a text file. It is not uncommon for people to append both the certificate and key to the same file, so you end up with something that looks like:
-----BEGIN CERTIFICATE-----
...certificate data...
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY-----
...key data...
-----END RSA PRIVATE KEY-----
Software expecting to read a private key will ignore everything outside the BEGIN RSA PRIVATE KEY/END RSA PRIVATE KEY lines, and software expecting to read a public certificate will ignore everything outside the BEGIN CERTIFICATE/END CERTIFICATE lines.
The easiest way to test for a private key in this case is just to look for the BEGIN RSA PRIVATE KEY marker.
I don't believe it is possible to concatenate DER encoded certificates in this fashion.
I am signing saml Response and assertion with x509 certificate. The response is posted to a java app, which throws error Signature length not correct…". I am asked to make sure that the xml doc is signed with certificate in JKS format and not pkcs12.
Is there a way to sign xml document in jks format in c# and then post the saml response to java app?
There is no such thing as a XML document signed in JKS format. These are apples and oranges.
XML digital signatures are specified in XMLDsig standard (assuming that you use XML digital signatures). http://www.w3.org/TR/xmldsig-core/
When you sign something you use the private key of an asymmetric key pair, probably an RSA key pair. http://en.wikipedia.org/wiki/RSA_%28algorithm%29
When you verify the signature you use the public key, commonly wrapped in an X.509 Certificate. http://en.wikipedia.org/wiki/Public_key_certificate
JKS and PKCS#12 are two different formats for storing the private key and the certificate in a container, encrypted using a password (since the private key is supposed to be private you want to protect it using a password).
When you sign an XML document you open the JKS/P12 keystore and use the private key to sign, and optionally include the certificate for easier verification for the recipient.
The private key and the certificate are identical in both cases, i.e. it does not matter if you use JKS or P12, the XML signature is bit for bit identical.
Probably you are sending both the XML document and the PKCS12 keystore to the recipient, and the recipient is unable to open PKCS12 keystore properly?
Java can open both JKS and PKCS12 with no problems at all, most likely your problem is related to something else than JKS vs PKCS12.
I do not know if C# can read and/or write JKS files (JKS == Java Key Store)
I purchased a wildcard certificate from GoDaddy and I want to associate this certificate with a website on AppHarbor.
AppHarbor only allows me to upload a PFX certificate. So, how do I convert a .CRT to a .PFX?
If the contents of the .CRT files is a base-64 encoded certificate and it starts with BEGIN CERTIFICATE, you can dispense with the .pfx file and use keypair certificate entry method on AppHarbor.
PFX is the private information exchange format (Windows calls them like this) and is actually the PKCS12 keystore.
All you have to do is import the certificate in your keystore that already has your private key and use that. You don't need to transform the certificate