Can't generate a JWT token in jwt.io with Private key - jwt

I'm trying to test a feature of a software I'm building regarding JWTs to learn about it, which is using Firebase JWT PHP package
I'm trying to create a test case for using keys pairs as encoding/decoding, but can't get the http://jwt.io page to create a token with my key.
These are the keys I created using ssh-keygen command, without any modification.
I go to the page, select HS256 / 384 / 512 and remove the keys that the page have by default. Then I paste my private key so to sign my data. However the page won't generate any JWT.
What am I doing wrong?
I did notice that the example keys in the page say RSA KEY and they are shorter than mine, that's why I tried the other HS* options
Also, if I choose to set a password on my key, will it work for JWT?
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
NhAAAAAwEAAQAAAYEA2CAysx8LEzGu3EvWKTf7Yx8N364ifJfW9aJ7brtrg2kAhaBmH2Mw
DO+oo/vl+8fNSON7ADZeo/kjf9XgvDyKxWyCUXIxuFOWKy94tPCwIBJb7YR/tPh3XcMNel
trL/knhhjTnBzTRaApjv2g2kb8JEdn6egfSwhBu/zMjQtkWqLKTO7qZ+b32zaXQvLxiAYl
fL9wKKMqlfRv4Uu6TDzXZDghfSZ3TI5+EITctaLW4wI+suV3xm9zn8+LSnqdkRhXBwWzhU
5CCkWKlMAq6REKsn0V3kyaj582gjlb4zdf/uJc3nWn75uPSl1DhMLT1kgbn6ooQlWo7SlT
vdm2TbScAgLXyPT2RwceTk3vwUc5oZE84jV7YCqrwovnncFk4siBMs/n2pHQac681YtioE
smp3Py1T1PBjTLkqi9Q1q5mSL3RmDY89SKxA6aCbb+uEfwS/qTSYwf6pPR0tXd5JPBoE9d
hfzsYGXegLDAf9XS+GvOcCfRk5DWt4zImMuMChczAAAFiNM40NLTONDSAAAAB3NzaC1yc2
EAAAGBANggMrMfCxMxrtxL1ik3+2MfDd+uInyX1vWie267a4NpAIWgZh9jMAzvqKP75fvH
zUjjewA2XqP5I3/V4Lw8isVsglFyMbhTlisveLTwsCASW+2Ef7T4d13DDXpbay/5J4YY05
wc00WgKY79oNpG/CRHZ+noH0sIQbv8zI0LZFqiykzu6mfm99s2l0Ly8YgGJXy/cCijKpX0
b+FLukw812Q4IX0md0yOfhCE3LWi1uMCPrLld8Zvc5/Pi0p6nZEYVwcFs4VOQgpFipTAKu
kRCrJ9Fd5Mmo+fNoI5W+M3X/7iXN51p++bj0pdQ4TC09ZIG5+qKEJVqO0pU73Ztk20nAIC
18j09kcHHk5N78FHOaGRPOI1e2Aqq8KL553BZOLIgTLP59qR0GnOvNWLYqBLJqdz8tU9Tw
Y0y5KovUNauZki90Zg2PPUisQOmgm2/rhH8Ev6k0mMH+qT0dLV3eSTwaBPXYX87GBl3oCw
wH/V0vhrznAn0ZOQ1reMyJjLjAoXMwAAAAMBAAEAAAGAUdPW/kR5n/nGl7fKzO5aKow+Z3
r5qayfgX7UNveU3DssLGuvXqDiN3OhqPyddbePPNKL5meva2vPif4DSaGudNMBgC65Lm3P
RGiDzhX2yR3KWmI5K96K6yAHgVUNfytZUIcjz06Gmyzpry7N8PbBTkcOy9vLxU/J+4/aLm
iqxTovV/N5In+rRf8kQ//RfMu+871TjL9CR2Y12dofHfBHKLWr0EN5Fa45gq2bFtYhf++A
p6EDuUjHQTGGLlvAPog08JRPInT02faYBXyD2MeTa3zFOOVK2GjFzCSyNL2aNU0qjXtq2p
BlbRTogui6xbtCFrqU72JcaZJgjA1W9X3I5WEuMusW1rXxj1zGecFwWYjzBGNkKlnMvc4q
LHApFDcczuHY0aAT6RZTgo3qPIG016zGk+obdX2OTzLrbyXSy5xcrjR1cX4s6PgxAF0wN1
1qfGo3WDbzFHHWtYrrNAOzd2IfNkR1LZ20lIrv+fdv5tqbAR9oFkt8LWfkhA0cffiBAAAA
wG4uOaKun9qtJa5oHJWgYYU3ZTiTwCtbgOSY3xEJEQ4XUk6vn02Et1KH2I/d/1C+5OG0nm
Eow7Ok+6kqmACARyssGOqTvrFOr7i9W5Dl3qOYOX9qOk7wj7KrBS29Xru3CGkB1yTHRWk0
N+PrbIVq1Ecnr3EGXS4zJnvI+GSWOqRaqSw6MyilFpjjtT0lXAltkXx74GvTzX9ayj8HKr
6mCeNg44a0M+UZPD1x1PgyAAe9ZtF3hw8yTX3LLymxB0WrUgAAAMEA+URIfElLoBI3koqE
BxxjNvMRMenoHql3wdqSvxfIs2RG1t76uWEF9/TDkV7+6ydhrFQsrhESMtBQLzt2StlnBs
Q8VScCNhq4GZjMsHyEwn5Rdzq7jPdfrutcIhtXhhSALy/p2XmUSUH0k3eJvtJv9SISUybv
1xr/+7pgdKEIjjfyFUpNYymTbXex079YUs7DqBuRSxbLgWRgdzZqjXwM8fJHd32nQ41HV3
THhG9FUElb4DVlYPlfL3PF2CyNra9BAAAAwQDd9r1+E7vLItPGxE3SX1TshUE1KlD9Alm/
SCgTQb3KDKZ2n08BhAFOQdsa1yEgbRCis0OFayAh+b5wHIg5CM4LmLN9h9cjibEq1KBskF
9FI3u4f55T6vPEB/bjjKgDPa+3A2FvsiFvVvjXyR8/9PBqzh0f7t0OwZsscfjf6+Kct/0Q
+CI/dx5DcJQ+cjZGIjEb9K0kH49elIIb6wwOQR0sLOthe0hvHcvJUgvFRb8ANP/Oo+Lbxu
5th77q55mqHXMAAAANam9yZ2VlQGpvcmdlZQECAwQFBg==
-----END OPENSSH PRIVATE KEY-----
Public
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDYIDKzHwsTMa7cS9YpN/tjHw3friJ8l9b1ontuu2uDaQCFoGYfYzAM76ij++X7x81I43sANl6j+SN/1eC8PIrFbIJRcjG4U5YrL3i08LAgElvthH+0+Hddww16W2sv+SeGGNOcHNNFoCmO/aDaRvwkR2fp6B9LCEG7/MyNC2RaospM7upn5vfbNpdC8vGIBiV8v3AooyqV9G/hS7pMPNdkOCF9JndMjn4QhNy1otbjAj6y5XfGb3Ofz4tKep2RGFcHBbOFTkIKRYqUwCrpEQqyfRXeTJqPnzaCOVvjN1/+4lzedafvm49KXUOEwtPWSBufqihCVajtKVO92bZNtJwCAtfI9PZHBx5OTe/BRzmhkTziNXtgKqvCi+edwWTiyIEyz+fakdBpzrzVi2KgSyanc/LVPU8GNMuSqL1DWrmZIvdGYNjz1IrEDpoJtv64R/BL+pNJjB/qk9HS1d3kk8GgT12F/OxgZd6AsMB/1dL4a85wJ9GTkNa3jMiYy4wKFzM= jorgee#jorgee

It turns out that the key must be in PEM format and is not what I had, the default format.
ssh-keygen -t rsa -b 2048 -m PEM -f mykey.key
# Don't add passphrase
openssl rsa -in mykey.key -pubout -outform PEM -out mykey.pub
Example Private Key
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAqBfiDg2wY5S4ZCx58s2t1f6YjV6bPETX7Ru81loI0rgdDLqS
kEd2JmnxSEQ/7lvPvlMbHGPK0WkhQlBjyiIf8fTAo/Jts+Zh2V1ACBcV72pGyLBc
JGopDO9RYDGK/VNvni4osVb+QXDV9yo/o2fE86KE/yK5K5bz00YW27/C5SjXeJFb
CAdZzjuO02SXYWEJt3poNcew5kavHnUmx8fYr1MdIlvEe+auNArsF0uMz/1StWIx
0u349IQJBoWmtCXrVYStGZNrBvaSFa/MzR+h2XnUbDRnRUfN5drDoIq/qYMXbRoP
wFzLquARuJsHJVhO8+2fNQLt4lgBXFKYC/HX3wIDAQABAoIBADdxKS5ZdYRi2S6x
PMfI7z1V7Bs0yR7n1hBuxaotqBtYfrxkDVNpPp8M8nhTioKj5bFw19BVWeAYPNAS
k9dnygGUKLXqkCR2KG/5QdVpR+LfutkW0k1wdnm9tal0rdNAYeBaeTGE7/fFr80G
MldDMsLpJ9S/LzQhZeqZg5CXf0D13ran7r9ZsaxLBctY0WRYjvMKBCKIQhWWsxXH
Wl4gsTQqra/Ai4cswL2JgJ0YVizVOd9m0uBHBdTvIE+P6+HFgg7cE+wE1HUUrUuO
Gp9eneZCNWSKPykRIKAxPwW324M+/2lg3n7CMKqpAX0dcIvUSuxu5H9zqFtBp3zN
ODT8AwECgYEA1VC+MFoLMXsrfxjlTQaM1hdegbImiB/IdxJHXTJK6iVTHioYw9eC
Sn4Als42lggiQIX6L9akXqO6w/SdJRZHK3bIWc9fEfdyXIHx84Lim/9fDZQsdaFB
18nLin2CC+IXCCdWcY9fmSziS3gK2KjzaLE246ssWxS/kK2dfbrosxcCgYEAybqZ
r/5q/yJnM6fxl1IvHhNm2m2Agy/vPcYiOhNeDY7JNi1W9GxlDcAmx0emQ3ZuCQju
hKYkY/rji/RYW+NlblaD0xlm75ZTGno3DHtlapo+1MlBULmfJLVViHNLxFKSfpfP
ReTOZnMTa/uaEA7P4YPIJ5EhtU2SWBEvpJ4bnnkCgYEAlGw56Sq93w/0k9qesZl9
JPndqCBs7wouUatGPHJh7clKrBJeaOXqoipJ/qQ9FudR7dNK4T5X4AHMUcxCCywV
GQjtHpBLdhTWXceMsgK/6gsl+CzBQpeRWLPwC8yIT/xgSiwU2a8ItWuliR1dbqMf
uhiUOJVBp54oLGKg0nrarsECgYA2toyehkOg5UTWZtOItjqfTqXT0mVLr4GU4JtB
4yTcSoDaV9vAuXGDFD2wSQeYPpPDkY+XnLQ8Bb0XpXMdoQROs9pXNAmOK9hoUwOB
OCqeii1Gazty2JWIUEJdmt/O5JJlEWmfTFqKwOVgoUH83veU87giuyNIWDy79BVW
8acOCQKBgEtJIu9x/4ubpumPO94R6tyTTZVjCxJpnW3Nlc1/Ly/i/TbhYJ2BNlkz
JA2HxQSun456xqAJa38yo0Ciyq65hkO0BmHygwvgY0f6IKnq0dCzmD80/mrWK6cx
HqS++Bajrma/RQc+KGuyLqm/Ub5khTiWgszYjJ+GeD2d96YBXQ7I
-----END RSA PRIVATE KEY-----
Example Public Key
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqBfiDg2wY5S4ZCx58s2t
1f6YjV6bPETX7Ru81loI0rgdDLqSkEd2JmnxSEQ/7lvPvlMbHGPK0WkhQlBjyiIf
8fTAo/Jts+Zh2V1ACBcV72pGyLBcJGopDO9RYDGK/VNvni4osVb+QXDV9yo/o2fE
86KE/yK5K5bz00YW27/C5SjXeJFbCAdZzjuO02SXYWEJt3poNcew5kavHnUmx8fY
r1MdIlvEe+auNArsF0uMz/1StWIx0u349IQJBoWmtCXrVYStGZNrBvaSFa/MzR+h
2XnUbDRnRUfN5drDoIq/qYMXbRoPwFzLquARuJsHJVhO8+2fNQLt4lgBXFKYC/HX
3wIDAQAB
-----END PUBLIC KEY-----

Related

How to hash256 and digitally sign (with a private key) a string in Powershell

Using openssl I generated a private key (let's say httpCert.key) and a self signed certificate. Now, I have a string which I want to hash256, digitally sign with my private key i.e. httpCert.key and do a base64 encoding.
I can do this all in bash using openssl as below:
signature=`printf "test" | openssl dgst -sha256 -sign httpCert.key | openssl base64 -A`
But struggling to find a way to do this in Powershell.
Based on a help from other post, I can do a simple hash and encode as below:
$hasher=[System.Security.Cryptography.HashAlgorithm]::Create('sha256')
$signSHA=$hasher.ComputeHash([System.Text.Encoding]::UTF8.GetBytes("test"))
$signature=[Convert]::ToBase64String($signSHA)
But not sure how to sign the hash256 with a private key. I tried using "System.Security.Cryptography.RSACryptoServiceProvider" but couldn't get it working.
$Certificate = [Security.Cryptography.X509Certificates.X509Certificate2]::new("g:\Drive\ff.pfx","")
$data=[System.Text.Encoding]::UTF8.GetBytes("test")
$sData=$Certificate.PrivateKey.SignData($Data,'SHA1')
[Convert]::ToBase64String($sData)

no data found in PEM block

Hashi Vault: Attempting to set a PEM-encoded certificate and private key bundle, using the pki/config/ca endpoint. The bundle.pem is a concatenation of the ca and private key. The following is the command and output
vault write pki2/config/ca pem_bundle=#bundle.pem
What is the proper format for the pem_bundle?
Resolution attempted
1. Removed all blank lines in the bundle.pem
2. Also tried to convert pem files to a string that can be passed in json
awk 'NF {sub(/\r/, ""); printf "%s\n",$0;}' cert-name.pem
3. Also tried the UI as well as the api interface.
4. Reviewed similar items on github regarding 'no data found in PEM block'; did not resolve issue.
vault write pki2/config/ca pem_bundle=#bundle.pem
I expect the output to be:
Success! Data written to: pki/config/ca
The actual results are
PUT http://127.0.0.1:8200/v1/pki2/config/ca
Code: 400. Errors: * no data found in PEM block
After further research, there is an issue with the private key formatting.
The private key needs to be changed from pkcs8 to pkcs1
openssl rsa -in pkcs8.key -out pkcs1.key -outform pem
Then recreate bundle using the pkcs1 formatted private key.
Then the following command is successful.
vault write pki2/config/ca pem_bundle=#bundle.pem

Unable to determine DKIM key length

I created a public and private key running ssh-keygen -t rsa -b 4096.
I then created a DNS entry dkim._domainkey of type TXT with this value:
v=dkim1; p=AAAAB3NzaC1yc2EAAAABIwAAAgEAvQ1GCaGx9CRKqW4wJUalTb6lGb6C1vm5iTUaus7b8EfurN8JWQouVa+n7V1YbbtAk14om7k+24i5ApbaULv8bhH5fGyano91ZQ4UpXTNxo9TrpgLntRCVQf0GlB1JNADiFMHetepf49xMDh5+NhPvgxzDBwGNqa2e4dR+SiruFKUNr5kBeLCzB9mcpzgI0jLj3PVfiB0c+SfeCcQUcGteWplurl3KLWdFAEAkTlMHPd61adt//mGRy9+XbKnVUVUNK6bn5k5pV+CSmx31pSbbFbUUjtmS4gUzPuqFDsJlVv0Sz5THNMgNiei4dSX3EqvJUmE13m+sKhImyqLoIFMTxD2Z2PxOVVqE2IqnEi9Hn+QluEiczi/g9/thWz8AnodDLlDv884LSQK7Dedie35ueyzUwgkeUsnebzSdqk1A0AqF/IcEBFiAyQyjepJ03Svv04job4cMjX90L4WoeznyCu2KTo9mTcoRRZJhLlDu0afcKavLOr6ydpJyaEsxgRzZURxFbPXUq8FGR3MbuOLszToHd6+CAOH5exRRll+Bs8O8I/dQsvJA6NqCQpynjXpNRwZ5e3RqshOR8RlZsNB4fuTk0SN2rNiozxAwQWoCl4dg+u/jfyki1GPD86qo1U1NWWXKIpXHZqYSx4FXI/CVkQ3KLI9LW1U1GxPwGVpqkU
Now when I test it using https://protodave.com/tools/dkim-key-checker/ it says:
Unable to properly parse the public key string and determine key length or the key is invalid. Tip: Make sure there aren't any special charaters or newlines pasted into your key in the TXT record.
I just copy pasted the complete key out of the file that was generated by ssh-keygen. Any tips on how I can figure out what went wrong?
I used openssl genrsa -out openssl.priv 1024 and openssl rsa -in openssl.priv -pubout >openssl.pub to generate the keys and now it works just fine.
You can and maybe should use keylength of 2048, it's in the DKIM spec.
That said, I heard of problems with mail servers hosted by AWS, insisting on 1024, but that was a few years back.
Create private key:
$openssl genrsa -out dkim_private.pem 2048
Pull out public key in der form, for encoding without LFs subsequently:
$openssl rsa -in dkim_private.pem -pubout -outform der -out dkim_public.key
Convert public key to base64 representation required:
$openssl <dkim_public.key base64 -A >p_equals
After this, the base64 encoded string in file p_equals is the string needed in your DNS TXT record (p=MI......AB ).

deleting x.509 v3 extensions from issued certificate

I need to make light weight PKC for that i want to delete x509 v3 extensions from the user certificate. May i use this openssl command to delete v3 extensions?
openssl x509 -in /usr/local/openca/var/openca/crypto/certs/E841B2655206FA6A3ADA.pem -noout -text -certopt no_extensions -out /usr/local/openca/var/openca/crypto/certs/ -out
E841B2655206FA6A3ADA_nov3ext.pem
or where should i make changes to generate x509 v1 certificate since it doesn't contain x509 extensions. could you please provide me a link for the reference.
thanks for your time.
Usually (well, virtually always really!) the signature does not just cover the distinguished name on the cert; but everything else as well (serial, expiry dates, etc).
So while it is not hard to cut down the certificate to size - it will instantly invalidate the signature by its issuer.
However - in some cases it is possible to do something else - and that is dispense/ignore the signature part of the cert completely; and just focus on the public key.
Use someting like
cat somecert.pem | openssl x509 -pubkey -nout
to get just the public key. So forego all of X509 and in essense no longer have a PKI. Just pairs of raw public keys and private keys.
Then in your application commit the fairly unforgivable gaffe of inventing your own crypto - and have the owner of that public key sign something like a NONCE with its private key; and validate the signature. E.g.
# the 'server' sends a nonce to the client
openssl rand -base64 128 > send-to-client
then on the client it is signed
cat msg-from-server | openssl pkeyutl -inkey privkey.pem -sign | base64 > send-to-server
and on the server we check this
cat msg-from-client | openssl pkeyutl -in pubkey-of-client.pem -verify
and take things form there. However unless you are a kick-ass cryptographer and protocol designer, schemes like this (and above certainly does!) are riddled with flaws and pitfalls.
But in theory it does let you use just a few 1000 bytes of RSA keys; or a few 100 bytes of Elliptic curve based keys.

Signing a certificate with my CA

On running:
openssl ca -in ${ALIAS}.csr -out user-cert.pem -keyfile cacert-private.pem -cert cacert.pem -passin pass:$PASSWD -config ${CONFIG}
I get:
The stateOrProvinceName field needed to be the same in the
CA certificate (Gloucestershire) and the request (Gloucestershire)
I've read the error a few times and I'm fairly sure the field is the same value in each case. I have found references to similar problems being caused by different encodings but I don't know how I should be specifying that and where.
This is the ${ALIAS}.csr:
-----BEGIN NEW CERTIFICATE REQUEST-----
MIICxzCCAa8CAQAwgYExCzAJBgNVBAYTAkdCMRgwFgYDVQQIEw9HbG91Y2VzdGVyc2hpcmUxEzAR
BgNVBAcTCkNoZWx0ZW5oYW0xHzAdBgNVBAoTFldhbnNkeWtlIEhvdXNlIExpbWl0ZWQxDjAMBgNV
BAsTBUZpemlvMRIwEAYDVQQDEwlsb2NhbGhvc3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQDWvivt1JHiuaNeadOQJtxynQ4sSAR/peWgKd8g9UQgNM+H9QW4NlRE81+g63BdRqZT5YMm
J4K3upovQNlDRklevslgEYoTdQM4yBKV676Q4XDbM7Vk+rt04sqL5IgdsAUXODfMJvu81t3tOjFc
OGO7S+B+LEJ1+8qshLbuK2gBigfgcZtlbNgW6fCGik8ZsrKWl8W+NFbw1seS01INAipwCBasxaaj
/lINwWQVbQIG09+vEdwuHmmq5VIKlJqFcYNUTFBVojoJLfzyStZR2PfFUxp7R+t2YmVj6a48B7NA
lODnIlQDkAprECNMpCZoSP1QjrZgW1BgaVbT5OaWlVsPAgMBAAGgADANBgkqhkiG9w0BAQUFAAOC
AQEAvalFyJOgzmd1jcFlS5YoqiNgX1bm9nZ0/cFgj6cGL7R0Gqc9wu5QPakWRxa9c2UcI0m7p1lp
cygDvQTY23LEBhVcruymIGQG5DhDpXHeaBCbV3OWO6xowAjh+riQjvTNeVSXtP3jUNs5DaId0z+A
GXeb7dR96jhyj+soNYENoQseQLqLdAW4p0jdK1BraMJTc0ber0FBx1nOUXOEoTIJL9kL9cUWaCp3
7uYkonIPtVCCfS8KcgXxUsNMC41q/SkKDVB23PeCjnWgcyXxnSpx8n+AK7fwMgh+4TcZ5usmVujR
MNqk84hZpw8h1FIcmqRaWtaPWyv3EX8JH5LTnDe3eQ==
-----END NEW CERTIFICATE REQUEST-----
And cacert.pem:
-----BEGIN CERTIFICATE-----
MIIDQDCCAqmgAwIBAgIJAPj9mvMDl1K/MA0GCSqGSIb3DQEBBQUAMIG4MQswCQYD
VQQGEwJHQjEYMBYGA1UECAwPR2xvdWNlc3RlcnNoaXJlMRMwEQYDVQQHDApDaGVs
dGVuaGFtMR8wHQYDVQQKDBZXYW5zZHlrZSBIb3VzZSBMaW1pdGVkMQ4wDAYDVQQL
DAVGaXppbzESMBAGA1UEAwwJbG9jYWxob3N0MTUwMwYJKoZIhvcNAQkBFiZyaWNo
YXJkLm1pZHdpbnRlckB3YW5zZHlrZS1ob3VzZS5jby51azAeFw0xMTA4MDcyMTU4
NDBaFw0yMTA4MDQyMTU4NDBaMIG4MQswCQYDVQQGEwJHQjEYMBYGA1UECAwPR2xv
dWNlc3RlcnNoaXJlMRMwEQYDVQQHDApDaGVsdGVuaGFtMR8wHQYDVQQKDBZXYW5z
ZHlrZSBIb3VzZSBMaW1pdGVkMQ4wDAYDVQQLDAVGaXppbzESMBAGA1UEAwwJbG9j
YWxob3N0MTUwMwYJKoZIhvcNAQkBFiZyaWNoYXJkLm1pZHdpbnRlckB3YW5zZHlr
ZS1ob3VzZS5jby51azCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA03Y4hYdd
at3e3AB98s+E5wlxrvRL8RhJtRac0Jt0gXQy12ZYziFm3gryx0IG02srXluM+V3/
BPRRCLsnEnltfoi/fE0wM9MT0V1Ao9EXQ5t1E2rOzdoXUUdvovd6qvwG2L/DHCdL
kKjhokVR9TkFW/AWctBdWkb9qfFFTpDY4i0CAwEAAaNQME4wHQYDVR0OBBYEFHbG
d3+Lzax90slk65y1BYDgZ897MB8GA1UdIwQYMBaAFHbGd3+Lzax90slk65y1BYDg
Z897MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEArZ2yfTGJK3R+jRwP
FjaonDy1NVOt9tgjHfyh9YNQfyFSC7R987wFPcyydEqh8xg/Lb3WGwseDuzCBusw
jmVIqiUYBClHzkF3jG1766ltdlVVTOavVQgQMRBGMvpHVxcMH2RUNUyWH0XW+DH2
/uuRRpu4vX5sfEW75uEfORB9Mrg=
-----END CERTIFICATE-----
Any ideas? Thanks in advance.
You can also set the attributes as optional:
# For the CA policy
[policy_match]
countryName= optional
stateOrProvinceName= optional
organizationName= optional
organizationalUnitName= optional
commonName= supplied
emailAddress= optional
I have also run into this problem. Thanks to the replies above (mainly Francois), I discovered the source of the problem.
openssl is encoding using UTF8STRING and keytool (Java 6) is encoding with PRINTABLESTRING.
Worked around it by changing the openssl configuration so it matches keytool. In /usr/ssl/openssl.cnf change the "string_mask" setting to "pkix".
The previous posters already answered the question, but to make it easier, here is an example how to specify the encoding. Use the string_mask:
[ req ]
default_bits = 2048
default_md = rsa
prompt = no
string_mask = utf8only # <--------------
distinguished_name = req_distinguished_name
[ req_distinguished_name ]
countryName = GB
stateOrProvinceName = Gloucestershire
localityName = Cheltenham
organizationName = Wansdyke House Limited
organizationalUnitName = Fizio
commonName = localhost
As shown by :
openssl asn1parse -in req.csr
the request DN strings are encoded as PRINTABLESTRING.
openssl asn1parse -in cacert.pem
shows the CA DN strings are encoded as UTF8STRING.
For a quick'n dirty hack, I suggest you change the encoding of strings in your request by replacing the encoding type for PRINTABLESTRING (0x13) by the type for UTF8STRING (0x0c), using your favorite hex editor.
You will have to convert your request in DER before poking it.
The offset of bytes to change can be found with :
openssl asn1parse -in csr |grep PRINTABLESTRING |awk -F":" '{print $1}'
Then try to sign again.
I just ran into this problem. The root cause is a mismatch between the values of string_mask in the client's and the CA's openssl.cnf. The easy fix is to modify the client's value to match what the CA expects, then regenerate the CSR. The hard fix is to edit the CA's value and start a fresh CA.
Promoting mbrownnyc's comment to an answer, as it was useful to me and deserves more attention.
I believe /usr/ssl/openssl.cnf contains a policy called policy_anything that contains the above setup. You can use it by utilizing the policy argument as follows:
openssl ca -policy policy_anything -days 365 -out /root/ca/certs/out.pem -in certreq.csr