I'm trying to automate running of mitmdump binary in ubuntu. I'm providing self generated certs to it using command: ./mitmdump --cert *=mycert.pem. But help doesn't define any commands to provide the private key pass phrase. How do i provide the password during the start up?
I have tried to provide the input to it using command: ./mitmdump --cert *=mycert.pem <<< "mypassword", as suggested here, but it still asks my PEM pass phrase.
If it helps, I'm starting the mitmdump process from java code using Runtime.getRuntime().exec(COMMAND). Generating the certs without password isn't really a possibility.
As shown in the mitmproxy documentation the mycert.pem has to contain both, the certificate as well as the private key:
-----BEGIN PRIVATE KEY-----
<private key>
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
<cert>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<intermediary cert (optional)>
-----END CERTIFICATE-----
As you can see Mitmproxy expects a BEGIN PRIVATE KEY and not an BEGIN ENCRYPTED PRIVATE KEY hence the provided key is not protected by a password at all.
Optionally you can also add intermediate certificate at the end in case the provided certificate is not a root-CA certificate or a direct child certificate of a known root-CA.
Related
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.
I am trying to add an existing elliptic curve intermediate CA certificate to Vault using the following
vault write pki/config/ca pem_bundle=#bundle.json
bundle.json contains
{
"pem_bundle":"-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----\n-----BEGIN EC PRIVATE KEY-----\...\n-----END EC PRIVATE KEY-----"
}
this gives the error 'no data found in PEM block' - which I believe is because it is expecting an RSA certificate.
Looking at https://www.vaultproject.io/api-docs/secret/pki
there is a key_type parameter that can be set to EC. but this does not appear to be available for pki/config/ca
The API docs to submit a CA specifically note the following:
Note that if you provide the data through the HTTP API it must be
JSON-formatted, with newlines replaced with \n, like so...
This applies only to the HTTP API (eg: curl ... https://.../v1/pki/config/ca).
However, you are using the vault write CLI command which does the translation from inputs to json format for you. The pem_bundle argument to the CLI command should be a path to a plain .pem file containing the normal PEM-formatted certificate and key. eg:
-----BEGIN CERTIFICATE-----
...
...
-----END CERTIFICATE-----
-----BEGIN EC PRIVATE KEY-----
...
...
-----END EC PRIVATE KEY-----
Your final invocation will be:
vault write pki/config/ca pem_bundle=#ca_bundle.pem
Note also that the key_type argument is only needed when a key is being generated by Vault. Since you are providing the key, Vault will properly detect the key type (see certutil.ParsePemBundle).
This is the certificate that needs to be passed as a string.
-----BEGIN CERTIFICATE-----
MIICyTCCAbTCEF+F3G/7tLCJj9mZ/RiaPQEwDQYJKoZIhvcNAQELBQAwIzEhMB8G
A1UEAxMYc2FjLWh2bTAwODc5LnN3aW5mcmEubmV0MB4XDTE5MDkyMDEwMDk1NloX
DTQ0MDkxMzEwMDk1NlowIzEhMB8GA1UEAxMYc2FjLWh2bTAwODc5LnN3aW5mcmEu
bmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtmBCXjv7/8pjzUyq
O52/NAVgOpVAj+i4d1bMdFvfonUzZVzvTfmTxLoHVXAAYrivYq5Y9hpTVIxM0rWj
AsomYfH3AEgGYax8YGSdF0LW0USEeXZiaMf+Z5+N43d8BoCdGOkPZZQEIMaQwnxM
ouLisTV113x0vzHZR7b1JzZyMF5zYw88Lsul+TEOfkpY0zjmoptFM26pYSkx8J87
n0aTe1ZN7TFDZ3zu629BHYfcwvy2F/m0E6rnFRa7o4o6qXJSfZIe1kqqvbRc
-----END CERTIFICATE-----
Variable in helm chart is
global:
dbvalues:
dbcacertificate:
I found a way to pass the certificate which worked.
global:
dbvalues:
dbcacertificate: |
-----BEGIN CERTIFICATE-----
MIICyTCCAbTCEF+F3G/7tLCJj9mZ/RiaPQEwDQYJKoZIhvcNAQELBQAwIzEhMB8G
A1UEAxMYc2FjLWh2bTAwODc5LnN3aW5mcmEubmV0MB4XDTE5MDkyMDEwMDk1NloX
DTQ0MDkxMzEwMDk1NlowIzEhMB8GA1UEAxMYc2FjLWh2bTAwODc5LnN3aW5mcmEu
bmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtmBCXjv7/8pjzUyq
O52/NAVgOpVAj+i4d1bMdFvfonUzZVzvTfmTxLoHVXAAYrivYq5Y9hpTVIxM0rWj
AsomYfH3AEgGYax8YGSdF0LW0USEeXZiaMf+Z5+N43d8BoCdGOkPZZQEIMaQwnxM
ouLisTV113x0vzHZR7b1JzZyMF5zYw88Lsul+TEOfkpY0zjmoptFM26pYSkx8J87
n0aTe1ZN7TFDZ3zu629BHYfcwvy2F/m0E6rnFRa7o4o6qXJSfZIe1kqqvbRc
-----END CERTIFICATE-----
My solution for this problem was to base64 encode the value, and afterwards decode it in the chart.
You can store a certificate in config map or in secret and pass it further.
You can create secret and store value in it and use it as env variable or else you can save the value in values.yaml and point it in helm chart.
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.