just fixed another problem in the code. verify_signature() did not
check the digest length!
http://plan9front.googlecode.com/hg-history/8b005ad9d48998e30c4715383c8bc53fae0eccb1/sys/src/libsec/port/x509.c
http://code.google.com/p/plan9front/source/detail?r=8b005ad9d48998e30c4715383c8bc53fae0eccb1
If it's just as simple, this might be the right place/time to use sha256
for this sort of thing.
Again, I did not look into this in detail, but CSRs I generated
recently with openssl seem to use SHA1 with RSA encryption for the
signature:
Certificate Request:
Data:
Version: 0 (0x0)
UPDATE:
I now have reason to believe that they just removed MD5 from known signing
algorithms, and that a SHA1 will work. Anyone know anything about this?
Thanks,
bwc
On May 25, 2015, at 3:06 PM, Brantley Coile brantleyco...@me.com wrote:
Turns out the CSR wasn’t acceptable because of the
I now have reason to believe that they just removed MD5 from known
signing algorithms, and that a SHA1 will work. Anyone know anything
about this?
There's an exploit for the MD5 version. It looks pretty serious and
deserves to be fixed by disabling the MD5 signing algorithm.
I just changed “md5(…)” to “shall(…)” and added an object id to the table.
Once I figured out I didn’t have to us RSA to *sign* the CSR, but had to have
something other than md5, it was easy.
On May 26, 2015, at 2:00 PM, lu...@proxima.alt.za wrote:
I now have reason to believe that they
If it's just as simple, this might be the right place/time to use sha256
for this sort of thing.
On Tue, May 26, 2015 at 12:35 PM, Brantley Coile brantleyco...@me.com
wrote:
I just changed “md5(…)” to “shall(…)” and added an object id to the
table. Once I figured out I didn’t have to us RSA
(Ducking smelling connection!) Use sha1.
On May 26, 2015, at 10:44 AM, Brantley Coile brantleyco...@me.com wrote:
Fixed. Use shall instead of md5 and everyone is happy.
On May 26, 2015, at 9:27 AM, Brantley Coile brantleyco...@me.com wrote:
UPDATE:
I now have reason to believe that
Turns out the CSR wasn’t acceptable because of the MD5 signature. It seems the
that they should be signed as RSA and not MD5. MD5 is not deemed secure
enough. The plan 9 code is signing everything with MD5. Who owns this code?
Has anyone fixed this yet?
On May 24, 2015, at 11:10 AM, Skip
Thanks all. It goes through sslshopper fine, but the CA still doesn’t like it.
I’ll call them tomorrow. Thanks for all the help.
bwc
On May 23, 2015, at 1:08 PM, lu...@proxima.alt.za wrote:
I then pasted the contents of ‘csr’ into the page and get “This CSR
has an invalid signature!”
Thanks all. It goes through sslshopper fine, but the CA still doesn’t
like it. I’ll call them tomorrow. Thanks for all the help.
You may have neglected some of the options, for example, you may be
required to specify what the certificate is good for: web server, mail
server, etc.
I know how
going by my notes from the last time i used plan9 tools to generate a
CSR, the only differences i see are quoting the O attribute to handle
spaces in organization name and dropping the word SIGNING from
PEM header/footer.
Thanks all. It goes through sslshopper fine, but the CA still doesn’t
Personnaly, I don't have auth/rsa2csr, but I generate the certificate
request from Linux using OpenSSL:
$ openssl req -newkey rsa:2048 -days 730 -keyout key.pem -out csr.pem
-subj /C=FR/ST=Paris/L=Paris/CN=9grid.fr -nodes
Then, I convert the key from PEM to DER format:
$ openssl rsa -in key.pem
I then pasted the contents of ‘csr’ into the page and get “This CSR
has an invalid signature!”
It's worth playing with openssl to check the output from auth/rsa2csr.
The diagnostics are bound to be a bit less vague. Trying your
instructions, the PEM encoded csr includes the seemingly unwanted
as lucio says, just removing the word SIGNING makes it good.
you can test it here: https://www.sslshopper.com/csr-decoder.html
On Sat, May 23, 2015 at 10:31 AM, Brantley Coile brantleyco...@me.com wrote:
I’m trying to buy a certificate. Actually, I’m trying to *get* a
certificate. They seem
14 matches
Mail list logo
