Re: Why does OpenSSL report google's certificate is "self-signed"?

[Walter H.]

On 31.03.2021 19:48, Viktor Dukhovni wrote:

On Mar 31, 2021, at 1:43 PM, Michael Wojcik  
wrote:

As far as I can see, neither PKIX (RFC 5280) nor the CA/BF Baseline Requirements say 
anything about the practice, though I may have missed something. I had a vague memory 
that some standard or "best practice" guideline somewhere said the server 
should send the chain up to but not including the root, but I don't know what that might 
have been.

Inclusion of the self-signed root is harmless.


do some admins this really?

I have more often the problem, that just the end SSL certificate is sent,
and without the intermediate certificate any validation is impossible;
in such case I download the intermediate just to complete the chain;


The only case that
I know of where this is actually necessary is with DANE-TA(2) when
the TLSA RRset has a hash of the trusted root cert or public key.

this case is history, there doesn't exist any user agent, which has 
implemented this;






smime.p7s
Description: S/MIME Cryptographic Signature

Re: CSR with only public key

[Walter H.]

Hey,

Try calculating the private Key from the public key ;-)
but this can last a little time you don't have;

Walter

On Thu, September 12, 2019 09:50, Bharathi Prasad wrote:
> Hi,
> I have the public key of the client but not the private key.
> ...
>
> Regards,
> Bharathi

Re: [openssl-users] Subject CN and SANs

[Walter H.]

and which CA does this as the forum guidelines say?

On 23.12.2018 22:50, Felipe Gasper wrote:

Actually, per the latest CA/Browser forum guidelines, subject.CN is not only 
optional but “discouraged”.

-FG






smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Subject CN and SANs

[Walter H.]

I guess its a matter of which Linux you use,

CentOS 7 doesn't give this warning;
CentOS 6 warns about this;

a Debian (don't really know which release)
uname -a
Linux a2f78 3.16.0-7-amd64 #1 SMP Debian 3.16.59-1 (2018-10-03) x86_64 
GNU/Linux

does warn ...

Walter

On 23.12.2018 13:21, Felipe Gasper wrote:

Wow that’s pretty bad .. is that the current version of httpd??

That’d be worth a big report if so, IMO, though I’d imagine it’s an issue 
they’re aware of.

-FG


On Dec 23, 2018, at 6:53 AM, Walter H.  wrote:


I tried the following

the certificate had a CN oftest.example.com   and in subjectAltNames dNS 
were
test.example.com  and test.example.net

when the Apache ServerName is   test.example.net  I get this warning

[Sun Dec 23 12:45:03 2018] [warn] RSA server certificate CommonName (CN) 
`test.example.com' does NOT match server name!?

so the CN matters ...

so the server behavior is something different to the behavior of the client ...

Walter


On 23.12.2018 10:44, Kyle Hamilton wrote:
Does Apache only examine CN=, or does it also check subjectAltNames dNS entries?

-Kyle H


On Sun, Dec 23, 2018 at 3:25 AM Walter H.   wrote:

On 23.12.2018 03:47, Salz, Rich via openssl-users wrote:
 >>. New certificates should only use the subjectAltName extension.


 Are any CAs actually doing that? I thought they all still included 
subject.CN.

Yes, I think commercial CA's still do it.  But that doesn't make my statement 
wrong :)


Apache raises a warning at the following condition

e.g. a virtual Host defines this:

ServerName  www.example.com:443

and the SSL certificate has a CN which does not correspond to
CN=www.example.com, e.g.  CN=example.com

then the warning looks like this

[Fri Dec 07 07:08:19.393876 2018] [ssl:warn] [pid 29746] AH01909:
www.example.com:443:0 server certificate does NOT include an ID which
matches the server name

and fills up the logs

Walter







smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Subject CN and SANs

[Walter H.]

I tried the following

the certificate had a CN oftest.example.com   and in subjectAltNames 
dNS were

test.example.com  and test.example.net

when the Apache ServerName is   test.example.net  I get this warning

[Sun Dec 23 12:45:03 2018] [warn] RSA server certificate CommonName (CN) 
`test.example.com' does NOT match server name!?


so the CN matters ...

so the server behavior is something different to the behavior of the 
client ...


Walter

On 23.12.2018 10:44, Kyle Hamilton wrote:

Does Apache only examine CN=, or does it also check subjectAltNames dNS entries?

-Kyle H

On Sun, Dec 23, 2018 at 3:25 AM Walter H.  wrote:

On 23.12.2018 03:47, Salz, Rich via openssl-users wrote:

 >   >. New certificates should only use the subjectAltName extension.


 Are any CAs actually doing that? I thought they all still included 
subject.CN.

Yes, I think commercial CA's still do it.  But that doesn't make my statement 
wrong :)


Apache raises a warning at the following condition

e.g. a virtual Host defines this:

ServerName  www.example.com:443

and the SSL certificate has a CN which does not correspond to
CN=www.example.com, e.g.  CN=example.com

then the warning looks like this

[Fri Dec 07 07:08:19.393876 2018] [ssl:warn] [pid 29746] AH01909:
www.example.com:443:0 server certificate does NOT include an ID which
matches the server name

and fills up the logs

Walter




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Subject CN and SANs

[Walter H.]

On 23.12.2018 03:47, Salz, Rich via openssl-users wrote:

>  >. New certificates should only use the subjectAltName extension.


Are any CAs actually doing that? I thought they all still included 
subject.CN.


Yes, I think commercial CA's still do it.  But that doesn't make my statement 
wrong :)


Apache raises a warning at the following condition

e.g. a virtual Host defines this:

ServerName  www.example.com:443

and the SSL certificate has a CN which does not correspond to
CN=www.example.com, e.g.  CN=example.com

then the warning looks like this

[Fri Dec 07 07:08:19.393876 2018] [ssl:warn] [pid 29746] AH01909: 
www.example.com:443:0 server certificate does NOT include an ID which 
matches the server name


and fills up the logs

Walter



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Subject CN and SANs

[Walter H.]

Hello,

I found several different certificates on the net

some are like this:

CN=example.com
SANs areDNS:example.com, DNS:www.example.com

and some are like this:

CN=www.example.com
SANs areDNS:example.com, DNS:www.example.com

does this matter or is one them the preferred one?

Thanks,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] a problem connecting to a specific Site ...

[Walter H.]

Hello,

it is a little bitte weird/strange/complicated;

On 02.11.2018 23:05, Matt Caswell wrote:


On 02/11/2018 21:51, Walter H. wrote:

Hello,

when I try to connect to https://www.3bg.at/
I get the following error

Handshake with SSL server failed: error:1408E0F4:SSL
routines:SSL3_GET_MESSAGE:unexpected message

but
https://www.ssllabs.com/ssltest/analyze.html?d=www.3bg.at
says its ok ...

is the problem on my side or on their side?

You'll need to give us more information. I can connect to that server
using OpenSSL 1.0.2 s_client.

What version of OpenSSL are you using? Is this with your own application
or from s_client? What ciphersuites have you configured? Any other
relevant configuration that we should know about?



the mentioned error comes with squid - ssl-bump on;
in case I switch it off and have it as normal proxy, then is really 
suspisious:

- an old Firefox (17.0.11esr) has no problems, the Sites is shown and works

- an older Google Chrome (the last one f. WinXP, v46) gives:
  SSL connection error
  ERR_SSL_PROTOCOL_ERROR

- a fork of the latest Pale Moon (Mypal) and an old Palemoon itself (the 
last one f. WinXP) gives:

An error occurred during a connection to www.3bg.at.
Peer's certificate has an invalid signature.
(Error code: SEC_ERROR_BAD_SIGNATURE)

what is this strange?

but what does this mean at the mentioned SSLlabs result:

Certificate Transparency No

when I compare to any other site (e.g. my own with Let's encrypt 
certificate),

I get

Certificate Transparency *Yes (certificate)*

is this caused on my side or on the other side?

Thanks,
Walter


smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] a problem connecting to a specific Site ...

[Walter H.]

Hello,

when I try to connect to https://www.3bg.at/
I get the following error

Handshake with SSL server failed: error:1408E0F4:SSL 
routines:SSL3_GET_MESSAGE:unexpected message

but
https://www.ssllabs.com/ssltest/analyze.html?d=www.3bg.at
says its ok ...

is the problem on my side or on their side?

Thanks,
Walter



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Wildcard: how are they correct?

[Walter H.]

Hello,

which of these possibilities is the correct one?

(a)  CN=*.example.com
 and subjectAltName = DNS:*.example.com, DNS:example.com

(b)  CN=example.com
 and subjectAltName = DNS:example.com, DNS:*.example.com

(c)  CN=example.com
 and subjectAltName = DNS:*.example.com, DNS:example.com

(d)  CN=hello world
 and subjectAltName = DNS:example.com, DNS:*.example.com

Thanks,
Walter

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Test SSL connection

[Walter H.]

On 30.05.2018 08:45, Mark Shnaider via openssl-users wrote:


Hello,

I use  OpenSSL version is openssl-1.1.0h(Windows) and

I run following command from apps directory

|openssl s_server -accept 443 -www|

The server in this case use certificate "server.pem"

On client computer I run command

openssl s_client -connect 10.65.48.108:443

On client computer I  get error :

Verify return code: 21 (unable to verify the first certificate)

What is wrong?

Thanks for any help

Mark

very probable, that the client doesn't have the root ca certificate of 
the ca certificate that signed server.pem


you should have at least the following

ca.pem  - the root ca
server.pem - the server ssl/tls certificate

Walter


smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Trusting certificates with the same subject name and overlapping validity periods

[Walter H. via openssl-users]

On 20.09.2017 18:33, Jordan Brown wrote:


Q:  Does OpenSSL's trust-list verification support trusting multiple 
certificates with the same subject name and overlapping validity periods?


do these replacement certificates have the same serial number and the 
same private key?




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Question RE certificate chain verification

[Walter H. via openssl-users]

On Tue, February 21, 2017 12:16, Jakob Curdes wrote:
> Hi, I am new to the list and have a question where it seems I cannot find
> the answer in archives here or in other sources.
>
> We want to verify the certificate chain of an "official" certificate, but
> including the revocation status of the intermediate certs, via CRL or
> OCSP.
> (The chain verification itself is easy and solved, our problems lie just
> with getting the revocation status of an arbitrary certificate).
>
> It seems to turn out that a) this is seldom done completely (otherwise I
> think there would be more "working recipes") and it is not easy to do it
> in a generic way as we keep getting various errors at different steps.
>
> Wtihout making it too long, we want to do the following:
> a) retrieve and save certificate from server via URL
> b)retrieve and save certificate chain from server
> c) determine OCSP URL or CRL list URL
> d1) verify cert against OCSP source OR
> d2) download CRL; then verify cert against CRL
>
> Up to c), everything is straightforward. We use openssl 1.0.1e-60.el7 from
> current CentOS 7.

try this:

CAFILE=/etc/pki/certs/ca-bundle.trust.crt

CERT=/tmp/cert.crt  <-- cert to validate
ISSUER=/tmp/issuer.crt   <-- issuing ca cert

OCSPURL=$(openssl x509 -in $CERT -noout -ocsp_uri)
OCSPHOST=$(echo "$OCSPURL" |gawk --field-separator=\/ '{ print $3 }' -)

OCSPRESULT=$(openssl ocsp -CAfile $CAFILE -no_nonce -noverify -issuer
$ISSUER -cert $CERT -url "$OCSPURL" -header Host $OCSPHOST |grep "$CERT")



-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] openssl s_client

[Walter H. via openssl-users]

Hello,

openssl s_client -connect mailhost:25 -starttls smtp

displays this:

CONNECTED(0003)
depth=0 OU = Domain Control Validated, CN = ...
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 OU = Domain Control Validated, CN = ...
verify error:num=27:certificate not trusted
verify return:1
depth=0 OU = Domain Control Validated, CN = ...
verify error:num=21:unable to verify the first certificate
verify return:1

the question: is this caused by a config problem on the serverside or on 
the client side (host running openssl)?


Thanks,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] big endian vs little endian

[Walter H. via openssl-users]

On 18.12.2016 17:21, sahorwitz wrote:

I am obviosly a newbie and missing something. How then do I encrypt the file
on one machine (little endian), transmit it to another machine (big endian)
and decrypt it there?




similar to this:

encrypt
openssl enc -e -in file -out encryptfile -aes-256-gcm

decrypt
openssl enc -d -in encryptfile -out file -aes-256-gcm

can someone explain why I get the following output

enter aes-256-gcm decryption password:
bad decrypt

but the file is correctly decrypted

I'm using latest openssl rpm package from CentOS 6





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Syntax question for subjectAltName certificate extension?

[Walter H.]

Hello,

what is correct:

this:
subjectAltName = DNS:www.example.com, IP:127.0.0.1, IP:[2001:db8:123::1]

or this:
subjectAltName = DNS:www.example.com, IP:127.0.0.1, IP:2001:db8:123::1

or the question in other words: do I have to put an IPv6 address of the 
subjectAltName in []-brackets?


Thanks,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] regarding ssl_server test

[Walter H.]

On 26.05.2016 18:33, R-D intern wrote:

Hello,
  I have implemented ssl for my internal server that listens over a
private ip. Can anyone suggest how can I test my ssl_server? For eg. Qualys
test shows the amount of ssl implementation of a server listening over
public ip  and even checks for vulnerabilities in ssl implementation. How
can such a thing be tested for a server listening over private ip?


you can't because, your site listens
for e.g.
https://host.domain.local/...
and domain.local is the CN of your SSL-certificate, but not a real 
public domain name;

so a port forwarding in a NAT router won't help you ...

you only can do - in case you have a public webserver - implement it 
there and test with

Qualys ...
and then take the same configuration parameters to your internal server

Walter



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Certificate validating (openssl -verify ...) and interpreting messages

[Walter H.]

On 18.05.2016 21:10, Viktor Dukhovni wrote:

On May 18, 2016, at 1:26 PM, Walter H.<walte...@mathemainzel.info>  wrote:

openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.trust.crt -trusted_first 
-untrusted /tmp/chain.pem /tmp/cert.pem

/tmp/chain.pem contains a root certificate
/tmp/cert.pem contains a certificate that was signed by this root certificate;

I get the following output

/tmp/cert.pem: CN = ..., O = ..., ST = ..., C = ...
error 19 at 1 depth lookup:self signed certificate in certificate chain

of couse the number 19 means 'self signed certificate in certificate chain'
as shown here: https://www.openssl.org/docs/manmaster/apps/verify.html

but what does the number 1 (at ... depth) say?

It means that while constructing a chain, the immediate issue of the
leaf certificate was an untrusted self-signed certificate.  The leaf
certificate has depth 1, its issuer has depth 0.


Ah, ok; in case there had been a chain with 3 certificates
2 means the leaf certificate, 1 means the issuing intermediate and 0 
means the self signed root?


Thanks,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Certificate validating (openssl -verify ...) and interpreting messages

[Walter H.]

Hello,

when
running this:

openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.trust.crt 
-trusted_first -untrusted /tmp/chain.pem /tmp/cert.pem


/tmp/chain.pem contains a root certificate
/tmp/cert.pem contains a certificate that was signed by this root 
certificate;


I get the following output

/tmp/cert.pem: CN = ..., O = ..., ST = ..., C = ...
error 19 at 1 depth lookup:self signed certificate in certificate chain

of couse the number 19 means 'self signed certificate in certificate chain'
as shown here: https://www.openssl.org/docs/manmaster/apps/verify.html

but what does the number 1 (at ... depth) say?

does this reference a certificate of the whole chain, if so, which one 
the root or the other one?


Thanks for help;

Greetings from Austria,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How can I set up a bundle of commercial root CA certificates? (FAQ 16)

[Walter H.]

On 13.12.2015 11:34, Ben Humpert wrote:

2015-12-13 3:53 GMT+01:00 Viktor Dukhovni:

In other words, you can concatenate all the trusted root CA
certs into the "cert.pem" file in that directory, but this
has a performance cost, as all the certificates are loaded
into memory and parse even though most go unused.  Alternatively,

The problem with concatenating certs into one file is that at least
Windows does not understand that format and just reads the first
certificate but ignores all following.


then create a pkcs7 container

openssl crl2pkcs7 -nocrl -certfile cert1.pem -certfile cert2.pem 
-certfile cert3.pem -out bundle.p7b






smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OCSP service dependant on time valid CRLs

[Walter H.]

Hi Dan,

On 10.12.2015 16:27, daniel bryan wrote:

*TEST #2: *Next test was using OCSP:

[dan@canttouchthis PKI]$ openssl ocsp -CAfile CAS/cabundle.pem -VAfile 
VAS/def_ocsp.pem -issuer CAS/IC\ ABC\ CA3\ DEV.cer -cert 
CERTS/0x500c8bd-revoked.pem -url http://ocspresponder:8080


/Response verify OK
CERTS/0x500c8bd-revoked.pem: *unknown*
This Update: Dec 9 20:48:26 2015 GMT/

as you can see the client *was NOT *informed the certificate was revoked.
and also that it is not good -> unknown, revoked and good are the 3 
values ...


We are using a 3rd party vendors OCSP service, and I am of the opinion 
that an OCSP service should provide a revoked response regardless of 
the time validity of the CRL.
does the OCSP responder cert be the signing cert itself or was it signed 
by the same signing cert that signed the cert you want to validate?


or specific to your sample: did CAS/IC\ ABC\ CA3\ DEV.cer sign both 
CERTS/0x500c8bd-revoked.pem and the OCSP responder cert (VAS/def_ocsp.pem)?



Walter


smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] CA design question?

[Walter H.]

Hello,

my website has an official SSL certificate, which I renewed this year to 
have a SHA-256 certificate;

when I test my site with SSLLabs.com, I'm shows two certificate paths:

the first one:
my SSL cert (SHA-256) sent by server (SHA1 Fingerprint: 
0fae9fd23852fb834fe4f32d7d3c73714daa6aa9)
the intermediate (SHA-256) sent by server (SHA1 Fingerprint: 
064969b7f4d6a74fd098be59d379fae429a906fb)
the self-signed (SHA-256) in trust store (SHA1 Fingerprint: 
a3f1333fe242bfcfc5d14e8f394298406810d1a0)


the second one:
my SSL cert (SHA-256) sent by server (SHA1 Fingerprint: 
0fae9fd23852fb834fe4f32d7d3c73714daa6aa9)
the intermediate (SHA-256) sent by server (SHA1 Fingerprint: 
064969b7f4d6a74fd098be59d379fae429a906fb)
the self-signed (SHA-1) in trust store (SHA1 Fingerprint: 
3e2bf7f2031b96f38ce6c4d8a85d3e2d58476a0f)


before I renewed the SSL certificate, my server sent a intermediate with 
SHA-1, I just exchanged this intermediate certificate with a SHA-256 cert.
exchange the intermediate cert to one with SHA-256, with this I had this 
situation:


before exchange intermediate, path one:
my SSL cert (SHA-1) sent by server (SHA1 Fingerprint: ...)
the intermediate (SHA-1) sent by server (SHA1 Fingerprint: ...)
the self-signed (SHA-256) in trust store (SHA1 Fingerprint: 
a3f1333fe242bfcfc5d14e8f394298406810d1a0)


before exchange intermediate, path two:
my SSL cert (SHA-1) sent by server (SHA1 Fingerprint: ...)
the intermediate (SHA-1) sent by server (SHA1 Fingerprint: ...)
the self-signed (SHA-1) in trust store (SHA1 Fingerprint: 
3e2bf7f2031b96f38ce6c4d8a85d3e2d58476a0f)


after exchange intermediate, path one:
my SSL cert (SHA-1) sent by server (SHA1 Fingerprint: ...)
the intermediate (SHA-256) sent by server (SHA1 Fingerprint: 
064969b7f4d6a74fd098be59d379fae429a906fb)
the self-signed (SHA-256) in trust store (SHA1 Fingerprint: 
a3f1333fe242bfcfc5d14e8f394298406810d1a0)


after exchange intermediate, path two:
my SSL cert (SHA-1) sent by server (SHA1 Fingerprint: ...)
the intermediate (SHA-256) sent by server (SHA1 Fingerprint: 
064969b7f4d6a74fd098be59d379fae429a906fb)
the self-signed (SHA-1) in trust store (SHA1 Fingerprint: 
3e2bf7f2031b96f38ce6c4d8a85d3e2d58476a0f)


now my question how would it be possible to generate a SSL certificate 
that can be used with two different certificate paths?


Thanks,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] CA design question?

[Walter H.]

On 05.12.2015 20:20, Viktor Dukhovni wrote:

On Sat, Dec 05, 2015 at 07:55:50PM +0100, Walter H. wrote:


my website has an official SSL certificate, which I renewed this year to
have a SHA-256 certificate;
when I test my site with SSLLabs.com, I'm shows two certificate paths:

the first one:
my SSL cert (SHA-256) sent by server
the intermediate (SHA-256) sent by server (SHA1 Fingerprint:
064969b7f4d6a74fd098be59d379fae429a906fb)
the self-signed (SHA-256) in trust store (SHA1 Fingerprint:
a3f1333fe242bfcfc5d14e8f394298406810d1a0)

All this obfuscation is rather pointless (and annoying), please
just post the certificates.

take these examples
https://www.ssllabs.com/ssltest/analyze.html?d=fibot.creditplus.de
https://www.ssllabs.com/ssltest/analyze.html?d=sixxs.net
they both have two certificate paths, especially the of sixxs.net would 
be interesting if someone can explain,

one path has 3 certs and the other path 4 certs ...


now my question how would it be possible to generate a SSL certificate that
can be used with two different certificate paths?

There are two versions of one of the issuer certificates.

the certificate that issued the SSL cert. is the same in both samples above;
only the root CA cert is different, how would I generate such a situation?




smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How do I configure my Certification Authority to pay attention to Subject Alternate Names

[Walter H.]

On 04.11.2015 16:13, Ben Humpert wrote:

Oh crappy Gmail stop creating broken links ...

openssl.cnf is at
https://drive.google.com/file/d/0B8gf20AKtya0VEhGYm82YUhraDQ/view?usp=sharing


reqs/client_sample.cnf is at
https://drive.google.com/file/d/0B8gf20AKtya0QWNIbjY0WUtLVEk/view?usp=sharing


reqs/server_sample.cnf is at
https://drive.google.com/file/d/0B8gf20AKtya0Y2tLOU1FaGFnUE0/view?usp=sharing

2015-11-04 16:06 GMT+01:00 Ben Humpert:

you should have attached the files instead of giving links - not 
everybody has a google account ;-)




smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How do I configure my Certification Authority to pay attention to Subject Alternate Names

[Walter H.]

On 03.11.2015 14:46, John Lewis wrote:

I created a local certification authority  using this tutorial
https://www.debian-administration.org/article/284/Creating_and_Using_a_self_signed__SSL_Certificates_in_debian
and made a certification request using this tutorial and I use this
tutorial to learn how to make a request with a Subject Alternate Name.

I actually did manage to get lucky just now and I hypothesize that
running a command like this 'openssl ca -in ldap01.req -out
certs/new/ldap04.pem -extensions v3_req -config ./openssl.cnf' as
opposed to running a command like this 'openssl ca -in ldap01.req -out
certs/new/ldap04.pem  -config ./openssl.cnf' got my CA to create a cert
with subject alternate names. How do I add '-extensions v3_req' to my ca
configuration and have it be not be ignored?



add the following parameter(s):

-extensions sslcertext -extfile file
this file is similar to the following

[ sslcertext ]
basicConstraints = CA:false
keyUsage = critical, digitalSignature, keyEncipherment
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always, issuer:always
authorityInfoAccess = OCSP;URI:#OCSP-URL#/, caIssuers;URI:#DER-CACERT-URL#

issuerAltName = issuer:copy
subjectAltName = #SUBJECTALTNAME#

extendedKeyUsage = serverAuth, msSGC, nsSGC

certificatePolicies = ia5org, @policy_section
crlDistributionPoints = URI:#CRL-URL#

[ policy_section ]
policyIdentifier = #POLICYID#
CPS.1 = #CPS-URL#





smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How do I configure my Certification Authority to pay attention to Subject Alternate Names

[Walter H.]

On 03.11.2015 18:45, John Lewis wrote:

On 11/03/2015 12:04 PM, Walter H. wrote:

On 03.11.2015 14:46, John Lewis wrote:

I created a local certification authority  using this tutorial
https://www.debian-administration.org/article/284/Creating_and_Using_a_self_signed__SSL_Certificates_in_debian 


and made a certification request using this tutorial and I use this
tutorial to learn how to make a request with a Subject Alternate Name.

I actually did manage to get lucky just now and I hypothesize that
running a command like this 'openssl ca -in ldap01.req -out
certs/new/ldap04.pem -extensions v3_req -config ./openssl.cnf' as
opposed to running a command like this 'openssl ca -in ldap01.req -out
certs/new/ldap04.pem  -config ./openssl.cnf' got my CA to create a cert
with subject alternate names. How do I add '-extensions v3_req' to 
my ca

configuration and have it be not be ignored?



add the following parameter(s):

-extensions sslcertext -extfile file
this file is similar to the following

[ sslcertext ]
basicConstraints = CA:false
keyUsage = critical, digitalSignature, keyEncipherment
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always, issuer:always
authorityInfoAccess = OCSP;URI:#OCSP-URL#/, 
caIssuers;URI:#DER-CACERT-URL#


issuerAltName = issuer:copy
subjectAltName = #SUBJECTALTNAME#

extendedKeyUsage = serverAuth, msSGC, nsSGC

certificatePolicies = ia5org, @policy_section
crlDistributionPoints = URI:#CRL-URL#

[ policy_section ]
policyIdentifier = #POLICYID#
CPS.1 = #CPS-URL#



Do I replace my current [v3_req] section with the contents of 
[sslcertext]


No, you add this part, because v3_req is used for the certificate 
request ...


and I have forgotten to mention, that #...# must be replaced with the 
right values;


smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Thoughts about security, privacy, ...

[Walter H.]

On 31.10.2015 23:23, Michael Ströder wrote:

Walter H. wrote:

give me a hint for finding S/MIME certificates, finding my own would be nice;

You claim that clear-text OCSP requests are not a privacy issue.
yes ..., a security problem I mentioned in connection with stupid CAs 
some posts before is the bigger problem ...

So you should
explain how you keep your *public*-key cert from being intercepted somewhere.
depends on the CA; a CA that has a directory public browseable in ithe 
internet this is impossible,

in other words, the CA itself is the problem in this case;

You can't.

really? try to find my S/MIME public key certificate ...
your "update" shows only SSL certificates; and as a said, SSL 
certificates are not a problem ...


Greetings,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Thoughts about security, privacy, ...

[Walter H.]

On 01.11.2015 10:25, Matt Caswell wrote:

CT is the answer to a big problem. I fail to see that CAs deploying CT
is a problem. I also don't see why only a CA can do this. There might be
some adversaries that are perfectly capable of building large databases
of certificates that they have "collected" from the internet.

a computer tomograph as answer for a not really existing problem?
and collecting SSL certificates is not a big thing;

as long as the security problems aren't really solved, the privacy 
concerns don't exist;

You can't.

really? try to find my S/MIME public key certificate ...
your "update" shows only SSL certificates; and as a said, SSL
certificates are not a problem ...

Sorry, I must have missed that point? Why do you believe SSL
certificates are not a problem?
because this the request contains only contain the certificate serial 
number and not the certificate at all;
what would you know, when sniffing a request of validating a certificate 
with serial 575775757

from CA x?
in case you have a database, where you could lookup the serial in 
connection with the CA x,
then you have some information that raise some little privacy concerns, 
but without ...


having tracking pixels, strange scripts raise bigger problems: in 
security and privacy ...



But if so, I fail to see why the
existence of some certificates where the amount of information an
attacker could gain is smaller (but not nil) means that we should not
deploy OCSP over https for *all* certificates?
of course, when deploying OCSP over TLS, this must be done for ALL 
certificates; but relaying

on OCSP Stapling which itself is a security hole, is the wrong way;
(I mentioned this problem earlier)
when validating if it is save to connect to a host,
the information must come from third party and not from the host itself 
(as OCSP Stapling is done)

I also very much hope that CAs will deploy CT for S/MIME too.

only in hospitals ;-)

always think of this:
not the defect head light caused the accident, where the car slipped of 
the road ;-)


in other words, always think of the real cause before;
OCSP and CRL downloads are not the cause for privacy concerns, so there 
is no need of changing this;


Greetings,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Thoughts about security, privacy, ...

[Walter H.]

On 30.10.2015 21:42, Michael Ströder wrote:

Walter H. wrote:

On Thu, October 29, 2015 11:07, Jakob Bohm wrote:

She (Eve) would know that the requesting party Alice
was talking to Bob at the very moment she sent Trent
the OCSP *request* for Bob's certificate.

[...] equivalent of having (almost complete) real time
copies of everybody's phone bill/call records.
Who was calling who at what time.

this is not a problem as long as the public keys (the certificates) are
not really public;
because in your example Eve doesn't have the knowledge which certificate
the specific serial number has ...

if the public keys (the certificates) are searchable by public - the worst
case direct by a search engine like google - then you would get an
absolute security whole:

Update for you: https://crt.sh/


you know the difference between SSL and S/MIME?




smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Thoughts about security, privacy, ... (was: OCSP_sendreq_bio())

[Walter H.]

Hello Jabob,

On Thu, October 29, 2015 11:07, Jakob Bohm wrote:
> On 28/10/2015 21:58, Walter H. wrote:
>> On 28.10.2015 18:34, Jakob Bohm wrote:
>>> On 28/10/2015 17:36, Walter H. wrote:

>>>>>> OCSP must not be https ...
>>>>>> the same with CRL download ...
>>>>> Really, I thought that was only a recent cop out rule to
>>>>> cater to clients with inferior SSL libraries that can't
>>>>> handle the recursion.
>>>> both OCSP and CRLs are signed, and this is enough for validation,
>>>> there is no need of SSL;
>>> How about privacy.  Especially OCSP queries are very
>>> revealing, as they indicate the party sending the query
>>> is using that particular 3rd party certificate at that
>>> very moment.
>>>
>> what would someone really know, if he would catch the OCSP request of
>> the attached certificate?
>> privacy is not really the problem ...
>>
> She (Eve) would know that the requesting party Alice
> was talking to Bob at the very moment she sent Trent
> the OCSP *request* for Bob's certificate.
>
> [...] equivalent of having (almost complete) real time
> copies of everybody's phone bill/call records.
> Who was calling who at what time.

this is not a problem as long as the public keys (the certificates) are
not really public;
because in your example Eve doesn't have the knowledge which certificate
the specific serial number has ...

if the public keys (the certificates) are searchable by public - the worst
case direct by a search engine like google - then you would get an
absolute security whole:
think of some bad boys, they could get such certificates and get two
things with these: a valid e-mail address and everything they need to send
encrypted data to this e-mail address, and with this: they can send
anything: malware, spyware, whatever; no antivirus, spamfilter, or
whatever on any mailserver would stop such emails; everything hangs on the
client ...

the scenario you gave above is the less problem ...

>> there is one thing that is problematic - especially if the CA is
>> somewhat stupid:
>> using one responder certificate for all OCSP responses for any end
>> entity certificate ...
>> (the specific RFC says, that it is discouraged to do so)
> This is not about the OCSP-response signing certificate
> (or the CRL signing certificate).
No it is about them ...
https://www.rfc-editor.org/rfc/pdfrfc/rfc6960.txt.pdf (stupid CAs
- I know at least one - ignore the section on top of page 17)
with such CAs it is easy to pretend something different ...

>> faking the OCSP response by 3rd party to pretend a good certificate
>> even it is bad,
>> is quite a little bit difficult, but easy if the CA is stupid ...
>>
>>> However with careful choice/generation of certificates
>>> for the OCSP/CRL server, this can be easily avoided.
>>>
>> easily - are you sure?
>>
>> example:
>>
>> (a) you want to check cert 1 that was signed by the CAs cert A
>> (b) the server uses certificate 2 that was signed by the CAs cert B
>>
>> with https this would be the following:
>> to access the CRL or OCSP of cert 1, you need to validate cert 2,
>> that itself is needed to access the CRL or OCSP of cert 2, too?
>>
> As I said it involves recursion and the trick is to
> terminate that recursion before it gets infinitely
> deep.

it is more a deadlock than a recursion ...

> Another obvious way would be for that final https
> server to do OCSP-stapling,

this would be a solution but as soon as using SSL/TLS layer communication
for CRL download or OCSP, for whatever reason, accepting OCSP-stapling is
strongly discouraged, this is nearly like self-signed ...

I'd say security is more important privacy;

Greetings,
Walter


___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OCSP_sendreq_bio()

[Walter H.]

On 28.10.2015 17:27, Steve Marquess wrote:

There are environments where https must be used for OCSP, due to policy
fiat and/or firewall restrictions.

-Steve M.
OCSP works through proxies; there is no reason for having such strange 
setups ...


Walter



smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OCSP_sendreq_bio()

[Walter H.]

On 28.10.2015 16:44, Jakob Bohm wrote:

On 27/10/2015 21:21, Walter H. wrote:

On 26.10.2015 21:42, rosect...@yahoo.com wrote:

Hi, I need some help on this call.

I am building an OCSP client following guide in openssl and compile 
the code in Cygwin environment. My openssl version is 1.0.1h.


With HTTP based OCSP, the code works fine. But, with HTTPs, the code 
gets stuck at the call to OCSP_sendreq_bio(). Further debugging 
shows that OCSP_sendreq_nbio() does not return.


Did I need to something extra to deal with HTTPs based connection?


OCSP must not be https ...
the same with CRL download ...

Really, I thought that was only a recent cop out rule to
cater to clients with inferior SSL libraries that can't
handle the recursion.

both OCSP and CRLs are signed, and this is enough for validation,
there is no need of SSL;
and an infinite recursion would be implied because of
the need of validating these SSL-certificates the same way
as the origin SSL-certificate ...

but be aware the CRLs can be in an LDAP - done by bad CAs;
OCSP must be HTTP

Walter



smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OCSP_sendreq_bio()

[Walter H.]

On 26.10.2015 21:42, rosect...@yahoo.com wrote:

Hi, I need some help on this call.

I am building an OCSP client following guide in openssl and compile 
the code in Cygwin environment. My openssl version is 1.0.1h.


With HTTP based OCSP, the code works fine. But, with HTTPs, the code 
gets stuck at the call to OCSP_sendreq_bio(). Further debugging shows 
that OCSP_sendreq_nbio() does not return.


Did I need to something extra to deal with HTTPs based connection?


OCSP must not be https ...
the same with CRL download ...


smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Problems with openssl verify -crl_check ...

[Walter H.]

Hello,

openssl verify -CAfile root.pem -untrusted issuer.pem srvr.pem
gives this output
srvr.pem: OK

but
openssl verify -CAfile root.pem -crl_check -untrusted issuer.pem srvr.pem
gives this:
srvr.pem: C = US, OU = Domain Control Validated, CN = revoked.grc.com
error 3 at 0 depth lookup:unable to get certificate CRL

and doing this:
openssl verify -CAfile root.pem -crl_check issuer.pem
gives a similar result
issuer.pem: C = BE, O = GlobalSign nv-sa, CN = GlobalSign Domain 
Validation CA - G2

error 3 at 0 depth lookup:unable to get certificate CRL

the used certificate for these command-line samples are attached ...
(the SSL/TLS certificate and the whole chain of revoked.grc.com)

please, can someone tell me how to check the CRL of certificate using 
openssl command-line?


Thanks,
Walter

-BEGIN CERTIFICATE-
MIIDdTCCAl2gAwIBAgILBAABFUtaw5QwDQYJKoZIhvcNAQEFBQAwVzELMAkG
A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jv
b3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05ODA5MDExMjAw
MDBaFw0yODAxMjgxMjAwMDBaMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i
YWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT
aWduIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaDuaZ
jc6j40+Kfvvxi4Mla+pIH/EqsLmVEQS98GPR4mdmzxzdzxtIK+6NiY6arymAZavp
xy0Sy6scTHAHoT0KMM0VjU/43dSMUBUc71DuxC73/OlS8pF94G3VNTCOXkNz8kHp
1Wrjsok6Vjk4bwY8iGlbKk3Fp1S4bInMm/k8yuX9ifUSPJJ4ltbcdG6TRGHRjcdG
snUOhugZitVtbNV4FpWi6cgKOOvyJBNPc1STE4U6G7weNLWLBYy5d4ux2x8gkasJ
U26Qzns3dLlwR5EiUWMWea6xrkEmCMgZK9FGqkjWZCrXgzT/LCrBbBlDSgeF59N8
9iFo7+ryUp9/k5DPAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E
BTADAQH/MB0GA1UdDgQWBBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0B
AQUFAAOCAQEA1nPnfE920I2/7LqivjTFKDK1fPxsnCwrvQmeU79rXqoRSLblCKOz
yj1hTdNGCbM+w6DjY1Ub8rrvrTnhQ7k4o+YviiY776BQVvnGCv04zcQLcFGUl5gE
38NflNUVyRRBnMRddWQVDf9VMOyGj/8N7yy5Y0b2qvzfvGn9LhJIZJrglfCm7ymP
AbEVtQwdpf5pLGkkeB6zpxxxYu7KyJesF12KwvhHhm4qxFYxldBniYUr+WymXUad
DKqC5JlR3XC321Y9YeRq4VzW9v493kHMB65jUr9TU/Qr6cf9tveCX4XSQRjbgbME
HMUfpIBvFSDJ3gyICh3WZlXi/EjJKSZp4A==
-END CERTIFICATE--BEGIN CERTIFICATE-
MIIEWjCCA0KgAwIBAgILBAABL07hQUMwDQYJKoZIhvcNAQEFBQAwVzELMAkG
A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jv
b3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw0xMTA0MTMxMDAw
MDBaFw0yMjA0MTMxMDAwMDBaMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i
YWxTaWduIG52LXNhMS0wKwYDVQQDEyRHbG9iYWxTaWduIERvbWFpbiBWYWxpZGF0
aW9uIENBIC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCxo83A
3zNAJuveWteUZtQBY8wzRIng4rjCRw2PrWmGHKhzQgvxcvstrLURcoMi9lbnLsVn
cZ0AHDK84+0uCEWp5vrdyIyDBcFvS9AmSgv2G0XATX6TvA0nhO0wo+nGJibdLR/Y
i8POGdBb/Aif5NjiNeSgaKb2DaN0YEKyl4IkjkGk8i5eto6nbtlsfw07JDVq0Ktb
aveXAgA/UaanbnPKdw12fJu2MBoanPcfKHsOi0cf538FjMbJyLvP6dx6QS6hhtrU
ObLiE0CmqDr6D1MeT+xumAkbypp3s1WFhekuFrWdXlTxSnpsObpuFwY0s7JC4ffz
nJoLEUTeaniOsRNPAgMBAAGjggElMIIBITAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0T
AQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUlq36sFu5g2QqdsIcimnaQtz+/SgwRwYD
VR0gBEAwPjA8BgRVHSAAMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2Jh
bHNpZ24uY29tL3JlcG9zaXRvcnkvMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j
cmwuZ2xvYmFsc2lnbi5uZXQvcm9vdC5jcmwwPQYIKwYBBQUHAQEEMTAvMC0GCCsG
AQUFBzABhiFodHRwOi8vb2NzcC5nbG9iYWxzaWduLmNvbS9yb290cjEwHwYDVR0j
BBgwFoAUYHtmGkUNl8qJUC99BM00qP/8/UswDQYJKoZIhvcNAQEFBQADggEBADrn
/K6vBUOAJ3VBX6jwKI8fj4N+sri6rnUxJ4il5blOBEPSregTAKPbGQEwnmw8Un9c
3qtnw4QEVFGZnmMvvdW3wNXaAw5J0+Gzkk/fkk59riJqzti8/Hyua7aK6kVikBHT
C3GnXgYi/0046rk6bs1nGgJ/S/O/DnlvvtUpMllZHZYIm3CP9x5cRntO0J20U8gS
AhsNuzLrWVO5PhtWjRXI8UI/d/4f5W2eZh+r2rKDV7QMItKGvNoy18DtcIV8k6rw
l9w5EdLYieuNkKO2UCXLbNmmw2/7iFS45JJwh855O/DeNr8DBAA9+e+eqWek9IY+
I5e4KnHi7f5piGe/Jlw=
-END CERTIFICATE--BEGIN CERTIFICATE-
MIIE7jCCA9agAwIBAgISESFVaI04B3XaNMXfl0M+0/anMA0GCSqGSIb3DQEBBQUA
MFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMS0wKwYD
VQQDEyRHbG9iYWxTaWduIERvbWFpbiBWYWxpZGF0aW9uIENBIC0gRzIwHhcNMTQw
NDIzMTUzNzUyWhcNMTcwNDIzMTUzNzUyWjBKMQswCQYDVQQGEwJVUzEhMB8GA1UE
CxMYRG9tYWluIENvbnRyb2wgVmFsaWRhdGVkMRgwFgYDVQQDEw9yZXZva2VkLmdy
Yy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDemi+5M5XRD7PR
/4177a6x7upbXMm2b79x/PwBELElAsUq+qtmoBs0FXiMmOfxp1BUW3KO4fJGjMuE
G0UxJNo4YOYuNTW4PQnWpLqsGh8epcLi7DDQax+yKU4VaTOnHqJDjyQjiVvqojkJ
nzaSMSrUgbr7gfQwrmUVlSYhMb1j4HMQUPEyvRtkeevwBU5PHsUEIZBheTo0P8RC
1BvxXl6cSAdKiOgiloDGEAKwAa1u8ZJWtuPQbp2fbOIyMygwjo8F1JC7ybw4lT6c
UluSPZew2LPLRIJea8nYjGl1jEbCm3I8gnWAcOywjgSCv3egvxDA1NrgGjKBszXd
pZdnZLmDAgMBAAGjggG/MIIBuzAOBgNVHQ8BAf8EBAMCBaAwSQYDVR0gBEIwQDA+
BgZngQwBAgEwNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5j
b20vcmVwb3NpdG9yeS8wKAYDVR0RBCEwH4IPcmV2b2tlZC5ncmMuY29tggxtYWls
LmdyYy5jb20wCQYDVR0TBAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUH
AwIwPwYDVR0fBDgwNjA0oDKgMIYuaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9n
cy9nc2RvbWFpbnZhbGcyLmNybDCBiAYIKwYBBQUHAQEEfDB6MEEGCCsGAQUFBzAC
hjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2RvbWFpbnZh
bGcyLmNydDA1BggrBgEFBQcwAYYpaHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29t
L2dzZG9tYWludmFsZzIwHQYDVR0OBBYEFHI8mO4OWDHnVO+3VJ6CsEaSE1JfMB8G

Re: [openssl-users] Problem checking certificate with OCSP

[Walter H.]

On 5.10.2015 17:11, Dr. Stephen Henson wrote:

On Mon, Oct 05, 2015, Walter H. wrote:


Hello,

attached is the certificate and its chain of  https://revoked.grc.com/

doing this:

openssl ocsp -no_nonce -issuer chain.pem -cert cert.pem -text -url
http://ocsp2.globalsign.com/gsdomainvalg2

goves the following:

OCSP Request Data:
 Version: 1 (0x0)
 Requestor List:
 Certificate ID:
   Hash Algorithm: sha1
   Issuer Name Hash: 45658DA20174402FF48B3A6AC0BC69208095C7CA
   Issuer Key Hash: 96ADFAB05BB983642A76C21C8A69DA42DCFEFD28
   Serial Number: 112155688D380775DA34C5DF97433ED3F6A7
Error querying OCSP responsder
139928584042312:error:27076072:OCSP routines:PARSE_HTTP_LINE1:server response
error:ocsp_ht.c:250:Code=403,Reason=Forbidden

where is the problem for this strange error?


Some OCSP responders need the host header, try adding:

 -header Host ocsp2.globalsign.com

Thanks for this hint;

When doing this

openssl ocsp -CAfile /etc/pki/tls/certs/ca-bundle.trust.crt -no_nonce -issuer 
issuer.pem -cert cert.pem -text -url http://ocsp2.globalsign.com/gsdomainvalg2 
-header Host ocsp2.globalsign.com

ca-bundle.trust.crt is the certstore of my centos
issuer.pem is the intermediate certificate, used signing cert.pem
cert.pem is the certificate that should be checked

then I get this error:

Response Verify Failure
139966083565384:error:27069065:OCSP 
routines:OCSP_basic_verify:certificate verify 
error:ocsp_vfy.c:126:Verify error:unable to get local issuer certificate

srvr.pem: revoked
This Update: Oct 13 07:20:48 2015 GMT
Next Update: Oct 16 07:20:48 2015 GMT
Reason: unspecified
Revocation Time: Apr 23 15:44:10 2014 GMT

when I use use chain.pem (contains both the intermediate and the root 
certificate) as -CAfile

then it works;

I want to do the following:

I get the server certificate and the chain except of the root;
and then I want to verify with this, if the certificate is valid, 
revoked or has expired


so I have 3 files

cert.pem   the certificate itself
issuer.pem  the intermediate that was used signing the certificate
chain.pem any certificate of the chain except the certificate itself and 
the root

the following script should do the job ...

#!/bin/sh
CAFILE=/etc/pki/tls/certs/ca-bundle.trust.crt
CERT=srvr.pem
ISSUER=issuer.pem

OCSPURL=$(openssl x509 -in $CERT -noout -ocsp_uri)
OCSPHOST=$(echo "$OCSPURL" |gawk -F\/ '{ print $3 }' -)

openssl ocsp -CAfile $CAFILE -no_nonce -issuer $ISSUER -cert $CERT -url 
"$OCSPURL" -header Host $OCSPHOST


but failes with

139966083565384:error:27069065:OCSP 
routines:OCSP_basic_verify:certificate verify 
error:ocsp_vfy.c:126:Verify error:unable to get local issuer certificate


why?

it can't be the solution to generate a new "cert store" (the concat of 
chain.pem and the real cert store) for each certificate I want to verify ...


Thanks,
Walter



smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Problem checking certificate with OCSP

[Walter H.]

Hello,

attached is the certificate and its chain of  https://revoked.grc.com/

doing this:

openssl ocsp -no_nonce -issuer chain.pem -cert cert.pem -text -url
http://ocsp2.globalsign.com/gsdomainvalg2

goves the following:

OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
  Hash Algorithm: sha1
  Issuer Name Hash: 45658DA20174402FF48B3A6AC0BC69208095C7CA
  Issuer Key Hash: 96ADFAB05BB983642A76C21C8A69DA42DCFEFD28
  Serial Number: 112155688D380775DA34C5DF97433ED3F6A7
Error querying OCSP responsder
139928584042312:error:27076072:OCSP routines:PARSE_HTTP_LINE1:server response
error:ocsp_ht.c:250:Code=403,Reason=Forbidden

where is the problem for this strange error?

I'm running CentOS 6.7 64-bit, and OpenSSL is the latest provided update
from repository;

Thanks;

Greetings,
Walter


cert.pem
Description: Binary data


chain.pem
Description: Binary data
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Certificate serialnumber?

[Walter H.]

On 05.07.2015 14:19, David Thompson wrote:

Quoting the man page for req(1) -- although depending on the packaging
which I don't know for CentOS it may be a different section like 1s or 1ssl --
and also on the web https://www.openssl.org/docs/apps/req.html

-x509
 this option outputs a self signed certificate instead of a certificate 
request.
This is typically used to generate a test certificate or a self signed root CA.
The extensions added to the certificate (if any) are specified in the
configuration file. Unless specified using the set_serial option,
a large random number will be used for the serial number.


would this be also an option when using openssl like this:

openssl ca -batch -config any.cnf -name any_ca -md sha256 -startdate
...  -enddate ... 


'ca' always uses the value currently in a 'serial' file configured in the
configuration file, and increments it, thus using sequential numbers
when you issue more than one cert.

as you above, Unless specified using the set_serial option, ...
is it the same with 'serial' file when using openssl ca ...?
I mean, would the serial be random,
when there is no 'serial' file specified, neither in the openssl.cnf nor 
at the command parameters ...


Thanks,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Certificate serialnumber?

[Walter H.]

Hello,

I'm using openssl command-line in a Linux-Box (CentOS 6.x with squid) 
like this:


I havn't defined anything - everything is set default from the linux 
distribution
openssl req -new -newkey rsa:2048 -subj '/CN=Squid SSL-Bump 
CA/C=/O=/OU=/' -sha256 -days 365 -nodes -x509 -keyout ./squidCA.pem -out 
./squidCA.pem


the question: where does the serial number for this certificate come from?
is it random by default when nothing is said about it?

would this be also an option when using openssl like this:

openssl ca -batch -config any.cnf -name any_ca -md sha256 -startdate 
...  -enddate ... 


Thanks.

--
Best regards,
Ing. Walter Höhlhubmer




smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] S/MIME Mails signed with SHA256 certificate and/or SHA256 Hash

[Walter H.]

On 29.06.2015 10:48, Jakob Bohm wrote:

On 26/06/2015 21:41, Walter H. wrote:

Hello,

has anybody got a reliable source or knowledge about which
mail clients - especially which Thunderbird release - should be 
capable of verifying such mails correctly?



I believe GlobalSign has a knowledge base article
listing this as far as they know.

It is at

 
https://support.globalsign.com/customer/portal/articles/1499561-sha-256-compatibility




Enjoy



Thanks,

the reason why I was asking; there it shows, that Mozilla Thunderbird 
above 10.x are capable of verifying such e-mails;
I recently got such an e-mail and it could not be verified; Thunderbird 
has shown an error; the certificate used for signing that e-mail

also used an sha256-hash, too;
at work I had a client capable of sending sha-256 hash signed e-mails, 
but only a sha1 cert; and that mail could be verfied without problems;


could someone please send me an email, where both the mail signature and 
also the certificate have a sha256 hash;


Greetings,
Walter



smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] S/MIME Mails signed with SHA256 certificate and/or SHA256 Hash

[Walter H.]

Hello,

has anybody got a reliable source or knowledge about which
mail clients - especially which Thunderbird release - should be capable 
of verifying such mails correctly?


this
openssl smime -verify -CAfile trusted.crt -in mail.eml
successfully verifies such an e-Mail;

Thanks,
Walter

--
Best regards,
Ing. Walter Höhlhubmer




smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] DH parameters [was: Vulnerability logjam downgrades TLS connections to 512 Bit]

[Walter H.]

Hello

On 22.05.2015 08:30, Jeffrey Walton wrote:

Or are you talking about server certificates with fixed DH parameters?

can you please tell me more about this?

how do I have to create the certificate request?
(using debian 7 latest updates installed:   'apt-get update  apt-get 
upgrade' has nothing to do)


Thanks,
Walter



smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] base64 decode in C

[Walter H.]

Hi,

before calling this function,
remove any whitespace;

Walter




smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] base64 decode in C

[Walter H.]

On 18.03.2015 16:08, Prashant Bapat wrote:

printf(Base64 decoded string is : %s\n, b64_decode(str, strlen(str))); // 
This should print binary for a ssh key.
not really, because the return of b64_decode is not a C string; and the 
format specfier %s expects a C string;




smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Strange behaviour with Chrome (client OS = WinXP x64) ...

[Walter H.]

Hello,

can someone please try the following website with Google Chrome - I use 
the latest release: Version 39.0.2171.99 m -


https://banking.ing-diba.at/   (an electronic Banking site)

with the following policy enabled:

RequireOnlineRevocationChecksForLocalAnchors = 1

with this banking site I get the following error from Google Chrome

Your connection is not private

Attackers might be trying to steal your information from 
banking.ing-diba.at (for example, passwords, messages, or credit cards).


with the following banking sites of other banks I have no troubles:

https://ebanking.easybank.at/ or
https://banking.raiffeisen.at/

without enabling the policy above or not setting at all, this banking 
site works, but
the symbol it shows differs; it is the same as if a man-in-the-middle 
like SSL-Bump would be between;


Google chrome uses the same cert store as IE, and with IE there is no 
connection problem,
only another thing the banking site is telling: the browser is out 
dated, of course IE 7

the IE even shows a green bar when connecting to this banking site ...

can someone please tell me what is there special with this banking 
site:   https://banking.ing-diba.at/ ?


I'm using SSL bump with the exception of banking sites, the specific 
part of the squid.conf

looks like this:

acl ssl_bump_domains_bankingsites dstdomain banking.raiffeisen.at 
banking.ing-diba.at ebanking.easybank.at services.kepler.at 
www.kepler.at www.rcb.at

acl ssl_bump_domains_msftupdates dstdomain .update.microsoft.com
ssl_bump none ssl_bump_domains_bankingsites
ssl_bump none ssl_bump_domains_msftupdates
ssl_bump server-first all

sslproxy_cert_error allow all
sslproxy_cipher HIGH:MEDIUM:!AECDH:!ADH:!DSS:!SSLv2:+SSLv3:+3DES:!MD5
sslproxy_flags DONT_VERIFY_PEER,NO_DEFAULT_CA
sslproxy_options NO_SSLv2 NO_SSLv3

sslcrtd_program /usr/lib64/squid/ssl_crtd -s /var/local/squid/ssl_db -M 16MB
sslcrtd_children 8

http_port 3128 ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=16MB cert=/etc/squid/cert/squid.pem 
options=NO_SSLv2,SINGLE_DH_USE dhparams=/etc/squid/cert/dhparam.pem


# squid.pem contains both cert+key

I'm using my own CA, this means this SSL-bump CA cert is signed by my 
root CA certificate;


what is missing, wrong, ... so that this one banking site will work ...?

the SSL-bump CA certificate contain this:

Authority Information Access:
OCSP - URI:#url-to-ocsp#
CA Issuers - URI:#url-to-root-cert#

and

 X509v3 CRL Distribution Points:
Full Name:
  URI:#url-to-crl#

everything is working, the OCSP, the root-cert, and the CRL ...

what causes Google Chrome producing the mentioned error above, when 
activating this mentioned policy?


the question to squid specialists: was it a good idea signing the 
SSL-bump CA certificate with the root certificate of my CA?


Thanks

--
Best regards,
Walter H.





smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Problems verifying OCSP signatures

[Walter H.]

On 03.01.2015 18:16, Richard Moore wrote:
I've now got this working, though to do so I seem to have to take the 
certificates supplied in the OCSP response directly out of the certs 
field of the OCSP_BASICRESP and add these as intermediates for the 
verification too. It feels bad to directly access the internals of 
this struct but there doesn't seem to be another way (unless someone 
can enlighten me).


Cheers

Rich.
the certificate you want to test its validity with OCSP has the same 
intermediate CA cert. as the OCSP responder certificate you use in OCSP 
response


Walter


smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
openssl-users@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users

Re: [openssl-users] Freeze to mailing list memberships

[Walter H.]

On 05.12.2014 23:08, Kurt Roeckx wrote:

On Fri, Dec 05, 2014 at 02:50:00PM -0700, Philip Prindeville wrote:

On Dec 5, 2014, at 1:57 PM, Walter H.walte...@mathemainzel.info  wrote:


On 05.12.2014 21:46, Kurt Roeckx wrote:

On Fri, Dec 05, 2014 at 07:34:13PM +, TJ wrote:

On 26/11/14 02:05, Salz, Rich wrote:   We will soon be freezing the mailing 
list memberships for a couple of days.

We are moving to a new server and upgrading the mail infrastructure

Are you aware that the headers for the mailman configuration are inconsistent; 
some specify the previous
openssl.org email addresses whilst others use the mta.opensslfoundation.net 
address.

They should all have been changed from mta.opensslfoundation.net
to openssl.org.


now, what is the email adress in the To for List
which I can use to sort in at my IMAP server?


I would use the List-Id: value, actually.

openssl-users.openssl.org
openssl-users.mta.opensslfoundation.net

Sometimes multiple lists are copied, sometimes the list is Bcc'd.

The 2nd one was temporary, use the first one.


Kurt

then have a try;

by the way: some mails that were sent/received by some through this 
list, don't contain the List-Id ...


Walter




smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
openssl-users@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users

Re: [openssl-users] Freeze to mailing list memberships

[Walter H.]

On 05.12.2014 21:46, Kurt Roeckx wrote:

On Fri, Dec 05, 2014 at 07:34:13PM +, TJ wrote:

On 26/11/14 02:05, Salz, Rich wrote:  We will soon be freezing the mailing 
list memberships for a couple of days.

We are moving to a new server and upgrading the mail infrastructure

Are you aware that the headers for the mailman configuration are inconsistent; 
some specify the previous
openssl.org email addresses whilst others use the mta.opensslfoundation.net 
address.

They should all have been changed from mta.opensslfoundation.net
to openssl.org.


now, what is the email adress in the To for List
which I can use to sort in at my IMAP server?




smime.p7s
Description: S/MIME Cryptographic Signature
___
openssl-users mailing list
openssl-users@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users

Re: 1.0.1j on Windows32 shows error C2027: use of undefined type 'in6_addr'

[Walter H.]

On 05.11.2014 18:47, neil carter wrote:
I'm trying to install the 1.0.1j version on a Windows 2003 server 
(32-bit), with MS Visual Studio 6.0, nasm 2.11.05, and ActiveState 
perl v5.16.3.


Steps involved include running the VCVARS21.BAT script, ' perl 
Configure VC-WIN32 --prefix=c:\openssl-1.0.1j', 'ms\do_nasm.bat', and 
finally 'nmake -f ms\ntdll.mak'.  Everything looks normal/good until 
the last step, which ends in the following:



VCVARS21.BAT = Visual C++ 2.1?
if yes, you should throw away the old ancient compiler of the early 
beginning of WinNT ... as of 1994;

and get the new actual Platform SDK from Microsoft ...

 .\apps\s_cb.c(803) : error C2027: use of undefined type 'in6_addr'
 .\apps\s_cb.c(803) : see declaration of 'in6_addr'
 .\apps\s_cb.c(836) : error C2027: use of undefined type 'in6_addr'
 .\apps\s_cb.c(836) : see declaration of 'in6_addr'
 .\apps\s_cb.c(884) : error C2027: use of undefined type 'in6_addr'
 .\apps\s_cb.c(884) : see declaration of 'in6_addr'
 .\apps\s_cb.c(917) : error C2027: use of undefined type 'in6_addr'
 .\apps\s_cb.c(917) : see declaration of 'in6_addr'
 NMAKE : fatal error U1077: 'cl' : return code '0x2'
 Stop.

this seems that you include ancient SDK headers not capable of IPv6 at 
all ...




smime.p7s
Description: S/MIME Cryptographic Signature

Re: 1.0.1j on Windows32 shows error C2027: use of undefined type 'in6_addr'

[Walter H.]

On 05.11.2014 19:27, neil carter wrote:

Sorry, typo - s/b 'VCVARS32.bat'

So are you implying that MS Visual Studio 6.0 might be the issue in 
that it might not have built-in code with IPv6 headers?

yes, definitly

WINSOCK2.H contains this:

/*
 * Constants and structures defined by the internet system,
 * Per RFC 790, September 1981, taken from the BSD file netinet/in.h.
 */

by the way: Visual C++ is from 1998, also an old ancient compiler
we have 2014 ;-)



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Case-sensitive cipher names are a bad idea

[Walter H.]

Hello

On 15.08.2014 17:43, Salz, Rich wrote:


Does ANYONE think that case-sensitive cipher names are good idea?

this is a bad idea; or can you explain the difference between   
tlsv1:rc4-md5 and TLSV1:RC4-MD5?


Someone who types TLSV1:RC4-MD5 will find things working, but is 
likely to be surprised by how weakly-protected they are.




the case of names doesn't make the cipher stronger ;-)

Walter


smime.p7s
Description: S/MIME Cryptographic Signature

ECDSA Certificate

[Walter H.]

On 08.08.2014 02:11, Dr. Stephen Henson wrote:


Well maybe, maybe not. Just because a ciphersuite is included in the
cipherlist doesn't mean it is included or could be selected. For example if
you set a ciphersuite which uses ECDSA authentication it wont be selected if
the server doesn't include an ECDSA certificate.

can you please give an example of an ECDSA certificate, Thanks

I'm asking this, because
one Web-Server connects with
|SSL_CIPHER=ECDHE-RSA-AES256-GCM-SHA384
and one with
||SSL_CIPHER=DHE-RSA-AES256-GCM-SHA384|
both with the same client;

and both Web-Server (Apache) have this
SSLCipherSuite RC4-SHA:RC4-MD5:HIGH:MEDIUM:!ADH:!DSS:!SSLv2:+3DES

--
Greetings,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature

Re: ECDSA Certificate

[Walter H.]

and how do I generate an ECDSA certificate?

On 10.08.2014 14:12, Dave Thompson wrote:


Both of those are using an RSA certificate; DHE or ECDHE is 
key-exchange only


not authentication. However the servers must configure **parameters** for

temp DH and temp ECDH respectively; do they?


I haven't configured none of those ...


Is the second server on not-very-recent RedHat or CentOS?


Yes, it is a CentOS 6.5


*From:*owner-openssl-us...@openssl.org 
[mailto:owner-openssl-us...@openssl.org] *On Behalf Of *Walter H.

*Sent:* Sunday, August 10, 2014 02:39
*To:* openssl-users@openssl.org
*Cc:* Dr. Stephen Henson
*Subject:* ECDSA Certificate

On 08.08.2014 02:11, Dr. Stephen Henson wrote:

Well maybe, maybe not. Just because a ciphersuite is included in the
cipherlist doesn't mean it is included or could be selected. For example if
you set a ciphersuite which uses ECDSA authentication it wont be selected if
the server doesn't include an ECDSA certificate.

can you please give an example of an ECDSA certificate, Thanks

I'm asking this, because
one Web-Server connects with
SSL_CIPHER=ECDHE-RSA-AES256-GCM-SHA384
|and one with|
|SSL_CIPHER=DHE-RSA-AES256-GCM-SHA384|
both with the same client;

and both Web-Server (Apache) have this
SSLCipherSuite RC4-SHA:RC4-MD5:HIGH:MEDIUM:!ADH:!DSS:!SSLv2:+3DES

--
Greetings,
Walter
 



--
Mit freundlichen Grüßen,
Best regards,
Mes salutations distinguées,

Ing. Walter Höhlhubmer   _/  _/  _/_/
_/  _/  _/_/
Lederergasse 47a/7 _/  _/  _/_/
A-4020 Linz a. d. Donau   _/  _/  _/  _/_/_/_/
Austria / EUROPE _/_/_/_/_/  _/_/
_/_/  _/_/  _/_/
[+43 664 951 83 72]_/  _/  _/_/



smime.p7s
Description: S/MIME Cryptographic Signature

x509v3 Extension: X509v3 Name Constraints?

[Walter H.]

Hello,

does anybody know what to write in the extension config to get this
X509v3 Name Constraints as the attached certificate (intel-ca.pem, 
intel-ca.text)?


Thanks.

--
Greetings,
Walter



-BEGIN CERTIFICATE-
MIIJWTCCCEGgAwIBAgIQeRdKqRQXNv4Vp8qfLP9FiDANBgkqhkiG9w0BAQUFADBv
MQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFk
ZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBF
eHRlcm5hbCBDQSBSb290MB4XDTEzMDIwMTAwMDAwMFoXDTIwMDUzMDEwNDgzOFow
UjELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMScwJQYD
VQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kgQ0EwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDCuISVQi3csKqYk5uz7IOhY8MXkiqBaTqagiht
iM997G1mJhTojcR+8DCg3E8OQ3ZajByhxRkwlsR4Srl5sGSwWfF/XaAHGUhWIhjB
kDO7toW+EMzI8pAjcLwIbRlIL0AFnUTe6Z0DcIS5406Y/9MKE2oKXbf4EbVBv88m
SkA74Z+lZJWFNxXncx/9wq8UdyMY2vHN1Kir1/JbtrqB9wYRBjQtWSbAVZR8nTBP
yRp4uvQTS2jOQh+jTUo1Y3O/o1xg/zRA4FEOUCla704OYRUkc8NuXHiPNNDcktr7
gO8E06NVQ6n6aBGaOJbSst2vHA7Eiog7A2PB4wKn+GDFf+FNAgMBAAGjggYMMIIG
CDAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNVHQ4EFgQUVjpv
F6skDOW3MWSwEe3b6iO+XrwwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYB
Af8CAQEwXgYDVR0lBFcwVQYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYI
KwYBBQUHAwQGCCsGAQUFBwMIBgorBgEEAYI3CgMEBgorBgEEAYI3CgMMBgkrBgEE
AYI3FQUwFwYDVR0gBBAwDjAMBgoqhkiG+E0BBQFpMEkGA1UdHwRCMEAwPqA8oDqG
OGh0dHA6Ly9jcmwudHJ1c3QtcHJvdmlkZXIuY29tL0FkZFRydXN0RXh0ZXJuYWxD
QVJvb3QuY3JsMIHCBggrBgEFBQcBAQSBtTCBsjBEBggrBgEFBQcwAoY4aHR0cDov
L2NydC50cnVzdC1wcm92aWRlci5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5w
N2MwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jcnQudHJ1c3QtcHJvdmlkZXIuY29tL0Fk
ZFRydXN0VVROU0dDQ0EuY3J0MCoGCCsGAQUFBzABhh5odHRwOi8vb2NzcC50cnVz
dC1wcm92aWRlci5jb20wggQXBgNVHR4EggQOMIIECqCCA9QwC4EJaW50ZWwuY29t
MAuCCWFwcHVwLmNvbTAOggxjbG91ZG5wby5vcmcwE4IRZWRhY2FkdG9vbGtpdC5v
cmcwC4IJZnRsMTAuY29tMAuCCWloY21zLm5ldDAOggxpbmMtbmVzdC5uZXQwFoIU
aW5kaWFlZHVzZXJ2aWNlcy5jb20wDYILaW50ZWwuY28uanAwDYILaW50ZWwuY28u
a3IwDYILaW50ZWwuY28udWswC4IJaW50ZWwuY29tMAqCCGludGVsLmZyMAuCCWlu
dGVsLm5ldDATghFpbnRlbGFsbGlhbmNlLmNvbTAUghJpbnRlbGFwYWNzdG9yZS5j
b20wFoIUaW50ZWxhc3NldGZpbmRlci5jb20wGYIXaW50ZWxiZXR0ZXJ0b2dldGhl
ci5jb20wFIISaW50ZWxjaGFsbGVuZ2UuY29tMBOCEWludGVsY2xvdWRzc28uY29t
MB6CHGludGVsY29uc3VtZXJlbGVjdHJvbmljcy5jb20wEoIQaW50ZWxjb3JlMjAx
MC5ydTAWghRpbnRlbGZlbGxvd3NoaXBzLmNvbTAWghRpbnRlbGh5YnJpZGNsb3Vk
LmNvbTAUghJpbnRlbHBvcnRmb2xpby5jb20wDoIMaW50ZWwtcmEuY29tMBSCEmlu
dGVsLXJlc2VhcmNoLm5ldDAUghJpbnRlbHJtYXN1cnZleS5jb20wGIIWaW50ZWxz
bWFsbGJ1c2luZXNzLmNvbTARgg9teWludGVsZWRnZS5jb20wEYIPbXktbGFwdG9w
LmNvLnVrMBKCEG9yaWdpbi1hcHB1cC5jb20wHoIcb3JpZ2luLWludGVncmF0aW9u
LWFwcHVwLmNvbTAIggZwYy5jb20wFIIScGN0aGVmdGRlZmVuY2UuY29tMBSCEnBj
dGhlZnRkZWZlbnNlLmNvbTAOggxwdmF0cmlhbC5uZXQwGYIXcmVkZWZpbmV5b3Vy
bmV0d29yay5jb20wD4INcmV0YWlsLWlhLmNvbTAUghJzZXJ2ZXItaW5zaWdodC5j
b20wE4IRdGhlaW50ZWxzdG9yZS5jb20wHYIbdGhyZWFkaW5nYnVpbGRpbmdibG9j
a3Mub3JnMBuCGXRodW5kZXJib2x0dGVjaG5vbG9neS5uZXQwIIIedWx0cmFib29r
LXNvZnR3YXJlLWNvbnRlc3QuY29tMFCkTjBMMQswCQYDVQQGEwJVUzELMAkGA1UE
CBMCQ0ExFDASBgNVBAcTC1NhbnRhIENsYXJhMRowGAYDVQQKExFJbnRlbCBDb3Jw
b3JhdGlvbqEwMAqHCAAAMCKHIAAA
MA0GCSqGSIb3DQEBBQUAA4IBAQBYb7/NQwdCE/y40K2BIfKKb++H
vCaKfAC9aAwrGWQsEWezqdl5Cqw5XWUAFjtTRm6iprVnmdvov6IlrgSVEQk6L96s
tz24vAF0MIBHSFRMoPtrqLiihLf0NOV7ztxSePQxbUJRroe/lKy+lhb7VeV5gmT9
rFA45NzLgSznd2+dmyNcfQQD9AeeftRX4maUTeu1XFxinowtg+ZGFOKhE4D92uCG
JxGSK72HF0/LGRhLXozmDdmPfSN2b6T/oLo942031iY46BqcI5LIVh8aGo4A1jOm
a5X6gh50Cw+kht8jM3yeNhSzXOKj7Uigjijx10z2wJu09Tyj5ahjoiwIpdX+
-END CERTIFICATE-Certificate:
Data:
Version: 3 (0x2)
Serial Number:
79:17:4a:a9:14:17:36:fe:15:a7:ca:9f:2c:ff:45:88
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, 
CN=AddTrust External CA Root
Validity
Not Before: Feb  1 00:00:00 2013 GMT
Not After : May 30 10:48:38 2020 GMT
Subject: C=US, O=Intel Corporation, CN=Intel External Basic Policy CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c2:b8:84:95:42:2d:dc:b0:aa:98:93:9b:b3:ec:
83:a1:63:c3:17:92:2a:81:69:3a:9a:82:28:6d:88:
cf:7d:ec:6d:66:26:14:e8:8d:c4:7e:f0:30:a0:dc:
4f:0e:43:76:5a:8c:1c:a1:c5:19:30:96:c4:78:4a:
b9:79:b0:64:b0:59:f1:7f:5d:a0:07:19:48:56:22:
18:c1:90:33:bb:b6:85:be:10:cc:c8:f2:90:23:70:
bc:08:6d:19:48:2f:40:05:9d:44:de:e9:9d:03:70:
84:b9:e3:4e:98:ff:d3:0a:13:6a:0a:5d:b7:f8:11:
b5:41:bf:cf:26:4a:40:3b:e1:9f:a5:64:95:85:37:
15:e7:73:1f:fd:c2:af:14:77:23:18:da:f1:cd:d4:
a8:ab:d7:f2:5b:b6:ba:81:f7:06:11:06:34:2d:59:
26:c0:55:94:7c:9d:30:4f:c9:1a:78:ba:f4:13:4b:
68:ce:42:1f:a3:4d:4a:35:63:73:bf:a3:5c:60:ff:

Re: Verification of a certificate chain

[Walter H.]

Hello,

On Tue, May 27, 2014 15:44, Sven Reissmann wrote:
 Hi,

 I'm having a comprehension question on certificate verification.

 Having a trustchain like this:

 rootCA - subCA - subCA2

 I can verify the subCA2 certificate using the command:

 openssl verify -CAfile rootCA.pem -untrusted subCA.pem subCA2.pem

 But, should't it also be possible to only verify the trust chain up to
 the subCA (i.e., if I fully trust this CA)?
yes, then the rootCA is in your cert store, and OpenSSL must have access
to this, implied by settings in openssl.cnf
 I would have expected that
 this will verify sucessfully:

 openssl verify -CAfile subCA.pem subCA2.pem

 Instead, I'm getting error 2 at 1 depth lookup:unable to get issuer
 certificate

 What do I miss?

settings in openssl.cnf

Walter

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Increment certificate serial numbers randomly

[Walter H.]

On 30.04.2014 03:57, Nikolay Elenkov wrote:


What hasn't been suggested is giving each server, etc. its own sub-CA signed by
the root. Then there won't be a need to have the root key at multiple places and
not problems with serial. Additionally, clients will only have to
install and trust
the root, which should make the whole thing easier to deploy.


I already mentioned this solution (not me has the many servers):

this is a design failure;  the certificates MUST all be signed on only 
one server for this reason;

or each server must have its own root/intermediate CA;

I want just come back to Jakob Bohm

I seem to (vaguely) recall that there was once an option or standard for
using a certificate-contents-related hash as the serial number, but I 
can't seem to find it right now.


if he has already found this - I'd use it for a totally different purpose;



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Increment certificate serial numbers randomly

[Walter H.]

On 29.04.2014 22:32, Tim Hudson wrote:

On 30/04/2014 6:05 AM, Walter H. wrote:

On 29.04.2014 21:38, d...@deadhat.com mailto:d...@deadhat.com wrote:


This all seems unecessarily complex. Make the serial number a 256 
bit or

greater true random number. There will be no collisions.

the serial number has maximum length ..., 256 bit is quite too big ..



In X.509 terms the serial number is an ASN1 integer value so there is 
no real length limit.
the maximum length is defined by the use of them; e.g. FF/TB accept 
only 128 bit or in other words,

they function properly with longer serial numbers;


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Increment certificate serial numbers randomly

[Walter H.]

On 29.04.2014 20:15, Jakob Bohm wrote:

I seem to (vaguely) recall that there was once an option or standard for
using a certificate-contents-related hash as the serial number, but I 
can't seem to find it right now. 

Hi,
could you please try to find this; I would be interested in such - a way 
of serial number that doesn't make

back reference in the number of certificates the CA has signed ...
Thanks,
Walter



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Increment certificate serial numbers randomly

[Walter H.]

On 29.04.2014 21:38, d...@deadhat.com wrote:


This all seems unecessarily complex. Make the serial number a 256 bit or
greater true random number. There will be no collisions.

the serial number has maximum length ..., 256 bit is quite too big ..



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Increment certificate serial numbers randomly

[Walter H.]

On 26.04.2014 05:52, csa321 wrote:

We've generated our own CA for self-signing certificates.



  The issue is that
we package up the openssl install  for installation on multiple servers.
Therefore, the root CA we create is part of the package as well.

the private key of the root CA should only exist on _ONE_ server; and as 
a backup on a external media;

The problem is that since the CA cert will have the same serial number
across all servers,

copying doesn't change serial number

  any certificates issued from that CA, on different
servers, end up having the same serial number.

of course;

  This causes browser issues
for obvious reasons.

this is a design failure;  the certificates MUST all be signed on only 
one server for this reason;

or each server must have its own root/intermediate CA;


Is there any way to control the incrementing of the serial number from the
root CA so that it is completely random,

No.





smime.p7s
Description: S/MIME Cryptographic Signature

Re: OpenSSL Security Advisory

[Walter H.]

On 10.04.2014 13:16, Rob Stradling wrote:

On 09/04/14 20:43, Salz, Rich wrote:
Can you please post a good and a bad server example. I have 
tested a lot of servers, including 'akamai.com', and they all show 
HEARTBEATING at the end:


Look at Victor's recent post about how to patch openssl/s_client to 
make your own test.  That's the simplest.


Simpler still...

https://gist.github.com/robstradling/10363389

It's based on what Viktor posted, but it works without patching the 
OpenSSL library code.




Hello,

I get a link error - the same es the 2nd comment mentions there;

how can I fix this?

Thanks,
Walter

--
Mit freundlichen Grüßen,
Best regards,
Mes salutations distinguées,

Ing. Walter Höhlhubmer _/  _/  _/_/
  _/  _/  _/_/
Lederergasse 47a/7   _/  _/  _/_/
A-4020 Linz a. d. Donau _/  _/  _/  _/_/_/_/
Austria/EUROPE _/_/_/_/_/  _/_/
  _/_/  _/_/  _/_/
(+43 664 / 951 83 72)_/  _/  _/_/



smime.p7s
Description: S/MIME Cryptographic Signature

Re: OpenSSL PKI Tutorial updated

[Walter H.]

Hello,

On Thu, March 27, 2014 10:47, Stefan H. Holek wrote:

 3. Is there a reason to not set a pathLen in the basicConstraints
 section of the Root CA's (to 1, to allow a maximum of one layer of
 CA's below the Root), but to do so on the Intermediate CA's?

 Pathlen is not used on root CA certs. A lot of things are not used on root
 CA certs. They only serve to publish a key and ID. I don't use pathlen on
 intermediate CAs either, just signing CAs.

Does this mean, you use certificates with a complete chain of at least 4
certificates?

- root ca cert. no pathlen
- intermediate ca cert. also no pathlen
- signing ca cert. with pathlen
- end cert

what is here said about the key length?

my CA uses a root with 4096 bits RSA key; does it make a sense, that
an intermediate or the signing ca has a stronger key than the root CA?

Greetings,
Walter

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Extend SSL Certificate

[Walter H.]

On 09.03.2014 14:39, Michael Post wrote:

last year i created my keys, certs and so on with the following steps
for an openvpn server:

the only certificate that is still valid is your self signed ca 
certificate;

# Serverside 

openssl req -new -x509 -newkey rsa:2048 -keyout ssl_priv.pem -out
ca_cert.pem -days 3650 -config ./openssl.conf

openssl x509 -in ca_cert.pem -out ca_cert.crt


ca_cert.pem and ca_cert.crt are the same, both are in PEM format;

openssl x509 -inform PEM -in ca_cert.pem -outform DER -out ca_cert.crt
would convert it from PEM to DER format;


openssl genrsa -out serverkey.pem -aes128 2048 -days 3650 -config
./openssl.conf

openssl req -new -key serverkey.pem -out req.pem -nodes -config
./openssl.conf

openssl ca -keyfile ssl_priv.pem -cert ca_cert.pem -in req.pem -notext
- -out servercert.pem -config ./openssl.conf

your openssl.cnf has the setting, for how many days the certificates are 
valid; the

-days 3650 from above's key generation step is ignored;



And today my certificate is invalid, cause due an error the
servercert.pem is only valid 365 days. It should be 3650 days.


# Serverside created, but copied to every client 

With the following commands i created the client certificates and keys

openssl req -new -keyout clients/client-key-X.pem -out
clients/client-req-XXX.pem -days 365 -config ./openssl.conf

why do you add the -days option, when generating the private key or 
cert. request and not when signing the request?

openssl ca -keyfile ssl_priv.pem -cert ca_cert.pem -in
clients/client-req-XXX.pem -notext -out client-cert-XXX.pem -outdir
clients -config ./openssl.conf
mv client-*.pem clients/


The Client certificates are also invalid due the same lack of my scripts.

The clients are not accessable per remote maintenance cause they are
umts clients with non static ip.

Is there any possibility to extend the certificates, keys and so on
server-side WITHOUT any change at client-side?

not really; every certificate got invalid; so every certificate must be 
renwed;

you can use the same private key and certificate request for this;
but without any change at client-side it will not work;

Greetings,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature

Quite a funny and strange behaviour

[Walter H.]

Hello,

it is already solved, but I just want to tell others;

I have two VMs, one with an older CentOS 4.x and one with a new CentOS 6.5

both run Postfix as MTA; both have configured a smarthost;
the smarthost allows STARTTLS and has a certificate, that is
issued by AlphaSSL; the

Authority Information Access:
  CA Issuers - URI:http://secure2.alphassl.com/cacert/gsalphag2.crt

this certificate (alphassl.txt) and it's root certificate (rootvalid.txt)
are attached;
the older CentOS 4.x has in it's ca-bundle.crt a root certificate that
expired at the end of last month (on Jan. 28th, 2014), also attached
(rootexpired.txt), no other valid root certificate of this CA (GlobalSign)
can be found in this ca-bundle.crt;

since then the /var/log/maillog shows the following

date time centos4x-vm postfix/smtp[]: certificate verification failed
for smarthost: num=10:certificate has expired
date time centos4x-vm postfix/smtp[]: certificate verification failed
for smarthost:certificate has expired
date time centos4x-vm postfix/smtp[]: Server certificate could not be
verified

the certificate of the smarthost itself has not expired:
   Signature Algorithm: sha1WithRSAEncryption
Issuer: O=AlphaSSL, CN=AlphaSSL CA - G2
Validity
Not Before: Nov  7 16:01:13 2012 GMT
Not After : Nov  8 16:01:13 2015 GMT

the linux clock is correct, syncs via a few NTP servers;

can someone tell me in clear logic, how it can be, that a totally
different root certificate was used to verify the server certificate?

I just copied the ca-bundle.crt from the new CentOS 6.5 VM to the older
CentOS 4.x VM; not any certificate error in /var/log/maillog since then;

Thanks;

Greetings,
Walter
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
04:00:00:00:00:01:2f:4e:e1:37:02
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA
Validity
Not Before: Apr 13 10:00:00 2011 GMT
Not After : Apr 13 10:00:00 2022 GMT
Subject: O=AlphaSSL, CN=AlphaSSL CA - G2
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c3:f0:65:88:df:1b:dd:c6:82:87:2f:c9:0b:ba:
54:c6:63:3f:46:75:ac:4b:14:1f:98:72:8b:1c:10:
ff:09:a9:52:6e:2f:65:df:65:84:3f:5f:81:b2:d8:
f1:4f:d7:f0:5a:bb:c9:af:d0:31:dd:26:46:2a:99:
9e:d8:a9:a3:b6:b8:07:c4:c9:71:f7:95:84:ef:d2:
ea:1f:54:a0:e5:be:e4:41:21:56:31:10:64:7d:1e:
63:8e:9c:71:5c:3c:a0:2e:de:67:dc:c8:9a:20:f0:
75:c8:b0:b6:27:81:eb:97:0d:ee:22:45:a5:c2:2f:
34:27:ec:e0:59:12:51:b3:1e:05:e5:38:20:d2:69:
59:7a:59:17:be:1a:4b:39:08:12:79:33:9b:64:68:
fe:58:81:dd:88:0c:6a:ba:59:b4:af:24:4f:61:e0:
ca:fc:17:5a:d2:3c:72:ab:a7:4c:b7:b9:ea:2d:e3:
f4:3f:99:a2:4d:c8:1d:58:f8:7f:53:35:8e:d7:22:
88:b7:61:76:08:13:13:69:66:b0:57:59:13:31:0a:
70:82:2b:93:d7:f6:e2:40:15:d0:1d:01:72:c7:13:
58:6a:5a:ec:19:89:16:3c:e0:c8:8d:86:2a:fa:37:
f0:35:32:dd:ec:e5:fe:80:8e:f7:05:67:b4:8b:42:
75:35
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Subject Key Identifier: 
14:EA:19:55:F0:0E:0D:32:C6:1F:74:33:B7:8E:66:1A:4C:12:31:1E
X509v3 Certificate Policies: 
Policy: X509v3 Any Policy
  CPS: https://www.alphassl.com/repository/

X509v3 CRL Distribution Points: 

Full Name:
  URI:http://crl.globalsign.net/root.crl

Authority Information Access: 
OCSP - URI:http://ocsp.globalsign.com/rootr1

X509v3 Authority Key Identifier: 

keyid:60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B

Signature Algorithm: sha1WithRSAEncryption
 06:30:42:9b:cf:49:02:7e:89:e9:f5:83:5a:3d:02:f3:bc:b2:
 46:de:4a:50:ee:b9:9a:90:73:da:a0:5c:26:ca:82:ac:0e:ad:
 b3:94:fa:28:2e:b2:e6:49:3f:50:77:0e:95:2f:68:f3:65:3c:
 9f:14:f2:68:60:92:b6:fc:04:0d:f6:a4:18:a1:69:60:0d:e3:
 9d:68:5b:bc:9e:0b:38:59:8d:21:da:23:fa:99:8a:09:b9:1f:
 a7:2e:b5:55:6c:47:e7:41:ec:e6:e2:7f:af:55:44:39:e0:ac:
 74:ee:65:d3:fa:ab:51:48:30:f1:3e:77:6d:ed:e4:0f:40:98:
 ee:47:7f:8d:b6:58:27:cd:92:6f:60:23:cc:02:9b:59:28:78:
 a2:51:9d:d0:4a:9c:e5:93:5e:98:8f:cb:ef:3f:ca:fe:e0:af:
 a4:c9:5b:6e:40:58:a5:92:2d:bd:5d:65:55:c5:bf:7c:04:41:
 

Re: Quite a funny and strange behaviour

[Walter H.]

On 20.02.2014 17:57, Viktor Dukhovni wrote:

On Thu, Feb 20, 2014 at 11:26:20AM +0100, Walter H. wrote:


the older CentOS 4.x has in it's ca-bundle.crt a root certificate that
expired at the end of last month (on Jan. 28th, 2014), also attached
(rootexpired.txt), no other valid root certificate of this CA (GlobalSign)
can be found in this ca-bundle.crt;

can someone tell me in clear logic, how it can be, that a totally
different root certificate was used to verify the server certificate?

When a root CA is re-issued with the same public key, subject name,
subject key identifier, ... updating only the expiration dates,
and serial number the old root looks like the right issuer of any
certificates issued by the new root to any verifiers (such as your
old CentOS box) that have only that certificate in their trust
store.

Thanks,

this sounds logic to me;

but one question:

in the extensions config file you have this:

subjectKeyIdentifier=hash

which parts of the certificate are included in generating this hash value?


Thanks,
Walter



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Extended Validation OIDS

[Walter H.]

On 07.02.2014 21:04, Tom Pfeifer wrote:

...which are required for Extended Validation (EV) certificates. I'm
currently using openSSL 1.0.1e-fips on Fedora 20, and I have these OIDs
specified in the [new_oids] section in openssl.cnf like this:

jurisdictionOfIncorporationLocalityName=1.3.6.1.4.1.311.60.2.1.1
jurisdictionOfIncorporationStateOrProvinceName=1.3.6.1.4.1.311.60.2.1.2
jurisdictionOfIncorporationCountryName=1.3.6.1.4.1.311.60.2.1.3

Also, referring to this web page (from 2010):
http://www.frank4dd.com/howto/openssl/add_oids_to_openssl.htm

...I looked in crypto/objects/objects.txt in the 1.0.1e source tree, and
they were not listed in that file with other OIDs. I also looked at the
1.0.1f source tree with the same result.

The issue I'm having is that they don't show up in the Subject line in
the certificate when specified in the -subj string, while all other OIDs
specified in the same -subj string do show up. They are just ignored,
with no error message.
You have to expand the [ policy_default ] or other section of your 
choice with something similar to


jurisdictionOfIncorporationLocalityName = optional
jurisdictionOfIncorporationStateOrProvinceName = optional
jurisdictionOfIncorporationCountryName = optional

Walter



smime.p7s
Description: S/MIME Cryptographic Signature

Re: A small note on Windows 8 GetVersion() depreciation

[Walter H.]

On 09.01.2014 19:48, Watson, Patrick wrote:

I'd recommend using VerifyVersionInfo: 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms725492(v=vs.85).aspx. 
It's supported from Win2k onward and isn't deprecated as of Win 8.1. I don't 
remember for sure if it's present in Windows CE and unfortunately I don't have 
my CE documentation handy at the moment.



I guess it must be a combination of GetVersion, GetVersionEx and newer APIs;

http://msdn.microsoft.com/en-us/library/windows/desktop/dn424972%28v=vs.85%29.aspx

Walter



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [openssl-users] Somewhat conflicting configuration and strange behaviour

[Walter H.]

On 14.12.2013 00:00, Dr. Stephen Henson wrote:


How are you disabling RSA key exchange?

by setting all ciphers beginning with RSA to no in FF

  If you disable RSA for authentication
too you'll hit problems if you don't have a non-RSA certificate. So for
example: ECDHE-ECDSA-3DES-EDE-SHA needs an ECDSA certificate (that's the same
as ECDHE-ECDSA-DES-CBC3-SHA).

can you please give an example of such an ECDSA certificate?

You can disable RSA key exchange by appending the string !kRSA to the cipher
string, for example: DEFAULT:!kRSA. Also if you want to support EDH
ciphersuites you need to set some DH parameters and for ECDH a suitable curve.

this the option in squid against my client:

http_port 3128 ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=4MB cert=/etc/squid/cert/squid.pem 
cipher=DEFAULT:!kRSA options=NO_SSLv2,SINGLE_DH_USE 
dhparams=/etc/squid/cert/dhparam.pem


Thanks,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [openssl-users] Somewhat conflicting configuration and strange behaviour

[Walter H.]

On 12.12.2013 14:16, Erwann Abalea wrote:

It's not strange.
You removed the RSA-* from client side, the result is that the server 
can't match anything in common between what the client proposed and 
what the server accepts. The error you get has been sent by the server.



The server is capable of ciphers DHE-* and others;
the list is quite longer than the avaiable ciphers of the client ...,
 so I think this is quite strange ...

openssl ciphers -V

shows e.g.  ECDHE-ECDSA-DES-CBC3-SHA
the site https://cc.dcsec.uni-hannover.de/ shows this: 
ECDHE-ECDSA-3DES-EDE-SHA


are these the same cipher suites but two confusing names?

Walter





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [openssl-users] Somewhat conflicting configuration and strange behaviour

[Walter H.]

On 13.12.2013 21:16, andrew cooke wrote:

well, i realised i couldn't answer the question seriously...  what is
ECDHE-ECDSA-3DES-EDE-SHA ?  the only reference i can find on the web is to
google chrome and firefox accepting it (a grep of openssl 1.0.1e fails to find
it).  does any server actually provide it?  if so, what mode does it use (EDE
is saying something about DES - how to build 3DES from DES - rather than
giving a mode, isn't it?)?

andrew

exact this is my problem - I need a ciphersuite from the OpenSSL list, 
that matches one of the FF list and doesn't make use of RSA for key 
exchange ...


Thanks,
Walter



smime.p7s
Description: S/MIME Cryptographic Signature

Somewhat conflicting configuration and strange behaviour (was: SELinux prevents running squid 3.3.11 on CentOS 6.5)

[Walter H.]

 work with squid nicely.
I do know it can be done with enough knowledge and couple additions.

If anyone is a SELinux expert or just can find the appropriate way of 
handling squid conflicts with SELinux I would be happy to try to push 
these into the RPMs.


For now the suggestion is to use selinux policy to permissive while on 
most squid systems(dedicated) you wont force selinux but I am still 
not sure why.


Fedora has some docs about it:
http://docs.fedoraproject.org/en-US/Fedora/13/html/Managing_Confined_Services/chap-Managing_Confined_Services-Squid_Caching_Proxy.html 



This setting direction policy will might help something:
 setsebool -P squid_connect_any 1

And at redhat couple notes:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Confined_Services/chap-Managing_Confined_Services-Squid_Caching_Proxy.html 




Can you share the errors you see in logs? either squid logs or 
messages log?


Are you using a cache_dir ?

There is also a demonstration on how to create a selinux module\policy 
fro qlproxy:
http://sichent.wordpress.com/2011/05/10/build-selinux-policy-for-your-next-daemon-part-1/ 



I hope it helps.

Eliezer

On 08/12/13 22:34, Walter H. wrote:

Hello,

I have the ident problem as here:
http://comments.gmane.org/gmane.comp.web.squid.general/99601

SELinux=enforcing prevents running squid ...

my system: a CentOS 6.5, squid-3.3.11

./configure --enable-ssl
 --enable-ssl-crtd
 --disable-htcp
 --disable-eui
 --disable-snmp
 --enable-useragent-log
 --enable-referer-log
 --enable-cachemgr-hostname=localhost
   --prefix=/usr
   --includedir=/usr/include
   --datadir=/usr/share
   --bindir=/usr/sbin
   --libexecdir=/usr/lib/squid
   --localstatedir=/var
   --sysconfdir=/etc/squid
 --with-dl
 --with-openssl
 --with-pthreads
 --with-logdir=/var/log/squid
 --with-default-user=squid

can someone give me a hint, what to do?

by the way, the binary packages from here:
http://wiki.squid-cache.org/SquidFaq/BinaryPackages#CentOS
have the same problem ...

Thanks,
Walter







smime.p7s
Description: S/MIME Cryptographic Signature

Squid - Proxy certificate

[Walter H.]

Hello,

can someone give me an example of the certificate, that is used here:

http_port 3128 ssl-bump cert=/etc/squid/cert/cert.pem

I'm using the latest CentOS release (6.5) with squid 3.1.10

I generated one with this:

openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -subj 
/CN=dnsname/C=--/O=my Org/OU=my Squid server -keyout cert.pem -out 
cert.pem


in case I generate a CA cert and this one and install the CA cert in my 
browser (FF);
does this help to remove the The Connection is untrusted messages of 
my browser (FF)?


Thanks,
Walter





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Verification of a x509 certificate signature

[Walter H.]

Hi,

On Wed, November 27, 2013 16:02, Dereck Hurtubise wrote:
 X509v3 Extended Key Usage:
 Trust Root

what is this strange?
'Trust Root' as Extended Key Usage?

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Verification of a x509 certificate signature

[Walter H.]

the ASN.1 dump of this certificate ...

  0 470: SEQUENCE {
  4 319:   SEQUENCE {
  8   3: [0] {
 10   1:   INTEGER 2
   :   }
 13   5: INTEGER 00 D6 2D F4 34
 20  13: SEQUENCE {
 22   9:   OBJECT IDENTIFIER sha1WithRSAEncryption (1 2 840 113549 1 1 5)
 33   0:   NULL
   :   }
 35  20: SEQUENCE {
 37  18:   SET {
 39  16: SEQUENCE {
 41   3:   OBJECT IDENTIFIER commonName (2 5 4 3)
 46   9:   PrintableString 'NL1SPF002'
   :   }
   : }
   :   }
 57  30: SEQUENCE {
 59  13:   UTCTime 13/11/2013 12:51:00 GMT
 74  13:   UTCTime 13/11/2014 12:51:00 GMT
   :   }
 89  20: SEQUENCE {
 91  18:   SET {
 93  16: SEQUENCE {
 95   3:   OBJECT IDENTIFIER commonName (2 5 4 3)
100   9:   PrintableString 'NL1SPF002'
   :   }
   : }
   :   }
111 157: SEQUENCE {
114  13:   SEQUENCE {
116   9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
127   0: NULL
   : }
129 139:   BIT STRING, encapsulates {
133 135: SEQUENCE {
136 129:   INTEGER
   : 00 C7 42 A0 7F FF A8 1F 65 A0 39 DC 63 D9 8B 09
   : 7C F2 D3 59 6D 84 A6 4B 1F 05 DE 30 1B 6B FA 42
   : B0 86 8C 88 75 9F A9 57 5B B2 6E E6 60 79 D7 12
   : 1E 22 1B 91 18 D5 93 41 80 28 2C 4D F7 D5 46 A6
   : 3E 9D 55 E1 A2 89 86 ED DC 88 9D 1B DE B8 F2 03
   : 5A 56 5B 0E CB 97 3D B1 32 74 6A A8 3B 24 6C 45
   : E7 1A 69 EB 2C EF D7 FD C1 4C 60 2A 6D BA 4B A3
   : 34 3C D6 56 4A 3E CA 32 CD 6C 5C 47 A1 05 E6 E7
   : 8D
268   1:   INTEGER 3
   :   }
   : }
   :   }
271  54: [3] {
273  52:   SEQUENCE {
275  15: SEQUENCE {
277   3:   OBJECT IDENTIFIER basicConstraints (2 5 29 19)
282   1:   BOOLEAN TRUE
285   5:   OCTET STRING, encapsulates {
287   3: SEQUENCE {
289   1:   BOOLEAN TRUE
   :   }
   : }
   :   }
292  11: SEQUENCE {
294   3:   OBJECT IDENTIFIER keyUsage (2 5 29 15)
299   4:   OCTET STRING, encapsulates {
301   2: BIT STRING 2 unused bits
   :   '11'B
   : }
   :   }
305  20: SEQUENCE {
307   3:   OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
312  13:   OCTET STRING, encapsulates {
314  11: SEQUENCE {
316   9:   OBJECT IDENTIFIER '1 3 6 1 5 5 7 48 1 11'
   :   }
   : }
   :   }
   : }
   :   }
   : }
327  13:   SEQUENCE {
329   9: OBJECT IDENTIFIER sha1WithRSAEncryption (1 2 840 113549 1 1 5)
340   0: NULL
   : }
342 129:   BIT STRING
   : C2 3A 8D 8E 2C A2 B5 46 7F CF 05 E2 01 38 C7 DF
   : 6F 6E 5F 4E E1 94 42 65 5A 67 BB 21 48 FE E1 FC
   : EB AB BE B2 34 65 AC 99 2E 2F 53 20 87 EC A5 0A
   : 14 5D 3A 08 DC 2B F2 1C 9E 46 F0 B3 E9 F9 26 FC
   : 6E 12 BD BF 95 4F E7 BC 11 CE 7C 22 05 B3 C7 28
   : E8 E9 67 A5 05 1B A0 47 C0 E1 DC B2 D1 96 9D 46
   : 90 97 66 C0 26 0F 88 90 A2 D1 6F 88 BB CB FE F4
   : BB A1 90 99 AB 82 A4 87 27 95 80 27 A4 59 69 87
   :   }


On Wed, November 27, 2013 16:02, Dereck Hurtubise wrote:
 The certificate is received in ASN.1 DER format. Not PEM.
 The only thing I want to do is verify the signature of the certificate,
 and
 thus verify the signature itself.
 It is self-signed so the public key in the certificate should be used to
 verify the signature, but it isn't working.

 Certificate:
 Data:
 Version: 3 (0x2)
 Serial Number: 3593335860 (0xd62df434)
 Signature Algorithm: sha1WithRSAEncryption
 Issuer: CN=NL1SPF002
 Validity
 Not Before: Nov 13 12:51:00 2013 GMT
 Not After : Nov 13 12:51:00 2014 GMT
 Subject: CN=NL1SPF002
 Subject Public Key Info:
 Public Key Algorithm: rsaEncryption
 Public-Key: (1024 bit)
 Modulus:
 00:c7:42:a0:7f:ff:a8:1f:65:a0:39:dc:63:d9:8b:
 09:7c:f2:d3:59:6d:84:a6:4b:1f:05:de:30:1b:6b:
 fa:42:b0:86:8c:88:75:9f:a9:57:5b:b2:6e:e6:60:
 79:d7:12:1e:22:1b:91:18:d5:93:41:80:28:2c:4d:
 f7:d5:46:a6:3e:9d:55:e1:a2:89:86:ed:dc:88:9d:
 1b:de:b8:f2:03:5a:56:5b:0e:cb:97:3d:b1:32:74:
 6a:a8:3b:24:6c:45:e7:1a:69:eb:2c:ef:d7:fd:c1:
 4c:60:2a:6d:ba:4b:a3:34:3c:d6:56:4a:3e:ca:32:
 cd:6c:5c:47:a1:05:e6:e7:8d
 Exponent: 3 (0x3)
 X509v3 extensions:
 X509v3 Basic Constraints: critical

Re: Error 18: self signed certificate

[Walter H.]

Windows has its own System wide certificate store;

look at  certmgr.msc

keep in mind, that some applications have their own store
e.g.  Mozilla ThunderBird, Mozilla FireFox
and some other can use this system wide certificate store
e.g. Adobe Reader/Pro/Std

Walter

On 15.11.2013 09:57, Manoj wrote:
Hi, I am trying to create a client/server application on windows 7, 
where I have used self signed certificate at server side as well as at 
client side. I used SSL_CTX_use_certificate_file and then 
SSL_CTX_use_PrivateKey_file API to load the certificate and key. When 
there is a SSL_connect() call from client, the handshaking fails with 
the error stating Error 18: self signed certificate. So I want help 
related to- how to use and verify self signed certificate. The 
certificate are generated by using following command openssl req -x509 
-nodes -days 1059 -newkey rsa:2048 -keyout testkey.pem -out 
testcert.pem -config pathtoconfig\openssl.cnf Regards Manoj
View this message in context: Error 18: self signed certificate 
http://openssl.6102.n7.nabble.com/Error-18-self-signed-certificate-tp47361.html
Sent from the OpenSSL - User mailing list archive 
http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html at Nabble.com.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Multi-level certificate chains

[Walter H.]

On Tue, November 12, 2013 05:47, Alan Jakimiuk wrote:
 Is there a way I can make all three linked?

this should be the default.

  ie. Cert A-Cert B-Cert C in the certification path?
 Any help would be appreciated

can you view the certificates?
openssl x509 -noout -text -in certfile

you should see in both, the intermediate and the Cert C something like


 X509v3 Authority Key Identifier:
keyid:EB:DF:B2:26:76:...
serial:6F:7F:C0:...

the serial in the intermediate here must match the serial of the root, and
of Cert C the one of the intermediate

Walter


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: SSL/TLS encryption algorithms

[Walter H.]

On 01.11.2013 23:12, Viktor Dukhovni wrote:

 $ openssl ciphers -v DHE-RSA-CAMELLIA256-SHA
 DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH   Au=RSA  Enc=Camellia(256) 
Mac=SHA1

 $ openssl ciphers -v AES128-SHA256
 AES128-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AES(128)  
Mac=SHA256

Does your application need to perform faster, offer forward-secrecy, be
most interoperable, ... ?

these was the result of using 2 different browsers with the same SSL
website ...
(1) an old firefox
(2) the latest IE - IE11 on Win 8.1

https://ssl.mathemainzel.info/info/
you can try your browser ...

how would I define forward-secrecy on Apache webserver?

If the server negotiated both ciphers, it already supports
forward-secrecy (aka PFS) if the client does too.


What about a browser that shows this

SSL_CIPHER=RC4-MD5
SSL_CIPHER_ALGKEYSIZE=128
SSL_CIPHER_EXPORT=false
SSL_CIPHER_USEKEYSIZE=128
SSL_COMPRESS_METHOD=NULL
SSL_PROTOCOL=TLSv1
SSL_SECURE_RENEG=true

Thanks,
Walter

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: SSL/TLS encryption algorithms

[Walter H.]

On 03.11.2013 18:27, Viktor Dukhovni wrote:

On Sun, Nov 03, 2013 at 06:18:38PM +0100, Walter H. wrote:


how would I define forward-secrecy on Apache webserver?

If the server negotiated both ciphers, it already supports
forward-secrecy (aka PFS) if the client does too.

What about a browser that shows this

SSL_CIPHER=RC4-MD5
SSL_CIPHER_ALGKEYSIZE=128
SSL_CIPHER_EXPORT=false
SSL_CIPHER_USEKEYSIZE=128
SSL_COMPRESS_METHOD=NULL
SSL_PROTOCOL=TLSv1
SSL_SECURE_RENEG=true

Your server supports PFS, some browsers don't.  Or prefer non-PFS
cipher-suites to PFS.  Default settings of OpenSSL 1.0.0 or later
have sensibly ordered ciphersuites.  Sufficiently recent versions
of Apache enable EDH/EECDH (aka PFS) cipher-suites by setting
appropriate parameters ((p,g) pairs or named curves).


Ok, I understand; how good is this encryption in comparison
to the other two I mentioned before?

what does SSL_SECURE_RENEG say to me?
some browsers show true, some show false ...

Thanks,
Walter

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

SSL/TLS encryption algorithms

[Walter H.]

Hello,

Which one of the following two is better (1) or (2)?

(1)

SSL_CIPHER=DHE-RSA-CAMELLIA256-SHA
SSL_CIPHER_ALGKEYSIZE=256
SSL_CIPHER_EXPORT=false
SSL_CIPHER_USEKEYSIZE=256
SSL_COMPRESS_METHOD=NULL
SSL_PROTOCOL=TLSv1
SSL_SECURE_RENEG=true


(2)

SSL_CIPHER=AES128-SHA256
SSL_CIPHER_ALGKEYSIZE=128
SSL_CIPHER_EXPORT=false
SSL_CIPHER_USEKEYSIZE=128
SSL_COMPRESS_METHOD=NULL
SSL_PROTOCOL=TLSv1.2
SSL_SECURE_RENEG=true

Thanks,
Walter


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: SSL/TLS encryption algorithms

[Walter H.]

Hello,

On 01.11.2013 22:34, Viktor Dukhovni wrote:

On Fri, Nov 01, 2013 at 09:56:10PM +0100, Walter H. wrote:


Which one of the following two is better (1) or (2)?

(1)

SSL_CIPHER=DHE-RSA-CAMELLIA256-SHA

 $ openssl ciphers -v DHE-RSA-CAMELLIA256-SHA
 DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH   Au=RSA  Enc=Camellia(256) 
Mac=SHA1


(2)

SSL_CIPHER=AES128-SHA256

 $ openssl ciphers -v AES128-SHA256
 AES128-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AES(128)  
Mac=SHA256

They're both fine.

Does your application need to perform faster, offer forward-secrecy, be
most interoperable, ... ?


these was the result of using 2 different browsers with the same SSL 
website ...

(1) an old firefox
(2) the latest IE - IE11 on Win 8.1

https://ssl.mathemainzel.info/info/
you can try your browser ...

how would I define forward-secrecy on Apache webserver?

Thanks,
Walter

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Signature Algorithm that was disabled because that algorithm is not secure

[Walter H.]

Hello,

On 30.10.2013 18:17, Marcus Schmitt wrote:

I have one problem after I created a root-CA, intermediate-CA and a server 
certificate. After I configured my apache with the server cert, key and 
intermediate cert and importing the root-CA to firefox 24 I received the 
following error when I browse to the website:

Could not verify this certificate because it was signed using a signature 
algoritm that was disabled because that algorithm is not secure


I assume the reason for this error message is that I see Certificate Signatore Algorithm is 
PKCS #1 MD5 With RSA Encryption for the Intermediate Certificate and Server Certificate. For the 
root-CA I see PKCS #1 SHA With RSA Encryption.

Unfortunately I was not able to find the reason for this issue, please find the 
lines I use below:

The problem is not in one of these lines, it is in the config file 
openssl.cnf

openssl genrsa -des3 -out private/cakey.pem 2048 -config ./openssl.cnf
openssl req -new -x509 -nodes -days 3650 -key private/cakey.pem -out 
certs/cacert.pem -config openssl.cnf

openssl genrsa -des3 -out private/cakey.pem 2048 -config ./openssl.cnf
openssl req -new -sha1 -key private/cakey.pem -out csr/ica.csr -config 
./openssl.cnf
openssl ca -config ./openssl.cnf -days 1825 -md sha1 -in ica.csr -out ica.crt 
-extensions v3_ca

openssl genrsa -des3 -out server.key 2048 -config ./openssl.cnf
openssl req -new -sha1 -key private/server.key -out csr/server.csr -config 
./openssl.cnf
openssl ca -config ./openssl.cnf -days 730 -md sha1 -in server.csr -out 
server.crt


look if you find there something similiar to

default_md = md5

change this to

default_md = sha1

and generate your certificates the same way as above

Greetings,
Walter
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Signature Algorithm that was disabled because that algorithm is not secure

[Walter H.]

Hello Marcus

On 30.10.2013 19:26, Marcus Schmitt wrote:

nameopt = default_ca
certopt = default_ca

what do this lines should mean in your openssl.cnf?

can you do the following with each of your generated certificates:

openssl x509 -text -noout -in cert.pem  cert.text

there you should see the mistake in these generated output cert.text

Greetings,
Walter
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Signature did not match the certificate request

[Walter H.]

On 08.10.2013 15:00, Rahul Tolani wrote:

Actual Subject Property =
subject=/CN=B1C43CD0-1624-5FBB-8E54-34CF17DFD3A1\x00

this is just a bug - the \x00 looks like the terminating \0 ...


Required Subject Property =
subject=/CN=B1C43CD0-1624-5FBB-8E54-34CF17DFD3A1

Greetings,
Walter
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Strange behaviour

[Walter H.]

I thought similar, but it becomes more strange;

if the webserver uses a certificate that is signed from a CA with built 
in token, then this needn't be;
and in case it is signed from my internediate certificate, this doesn't 
help ...


Greetings,
Walter

On 07.10.2013 09:39, Mat Arge wrote:

Just a wild guess: If you click on edit trust on the root certificate in
Firefox, you have to tick the box for web server certificates.

cheers
Mat

On Friday 04. October 2013 21:29:57 you wrote:

Hello,

there exists a self signed root CA certificate (A)
one intermediate CA certificate (B)
and this intermedia certificate has signed a SSL certificate (C) of a
web server;

the SSL certificate has in its 'Authority Information Access' extension
the URL to the
intermediate CA certificate, and the intermediate CA certificate has in
this extension the URL to the root CA certificate;
every certificate is stored in DER format;

in case the certificate database of the browser has only the root CA
certificate and I surf to this webserver
which itself sends the whole certificate chain; why does this work
without errors only in IE, and not in FireFox?

if the root CA certificate is a built-in token; then this works in
Firefox, too;

why this strange behaviour?

Thanks,
Walter


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Strange behaviour

[Walter H.]

Hello,

there exists a self signed root CA certificate (A)
one intermediate CA certificate (B)
and this intermedia certificate has signed a SSL certificate (C) of a 
web server;


the SSL certificate has in its 'Authority Information Access' extension 
the URL to the
intermediate CA certificate, and the intermediate CA certificate has in 
this extension the URL to the root CA certificate;

every certificate is stored in DER format;

in case the certificate database of the browser has only the root CA 
certificate and I surf to this webserver
which itself sends the whole certificate chain; why does this work 
without errors only in IE, and not in FireFox?


if the root CA certificate is a built-in token; then this works in 
Firefox, too;


why this strange behaviour?

Thanks,
Walter
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Version difference

[Walter H.]

Hello,

can someone please tell me the difference between

OpenSSL x.x.x any date
and
OpenSSL x.x.x-fips any date

is there a difference in functionality?
is there a difference in legality?

what does it tell to me, when
openssl version
shows fips, and what does it tell, when
openssl version
doesn't show fips?

Thanks,
Walter

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: OCSP Requestor behavior when OCSP Respone not received.

[Walter H.]

On 02.09.2013 10:33, deepak.kathuria wrote:

Hi,
I am using openssl OCSP utility as OCSP Responder in linux platform. OCSP
Requester sends the OCSP Request to OCSP Responder and if OCSP Responder
will not come, then what will be the expected behavior of OCSP Requester in
this case?

this can be configured ...
in Thunderbird/Firefox you can set both variants:
- to act as if the certificate is valid
- to act as if the certificate is invalid

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: CA hierarchy / pathlen:0

[Walter H.]

Hi,
this shouldn't be, because you marked this extension as critical;
what is your OpenSSL release?
and in case of Linux, which distro (version/release) are you using?
Walter

On 20.08.2013 20:18, Peter1234 wrote:

Hi all,

although I issued a certificate for an intermediate CA (CA2) with a
pathlength of zero (pathlen:0), I could use this certificate to create
certificates for further CAs (CA3).

Due to pathlen:0 I expected openssl would  either cancel creation of sub-CAs
with an error massage or would create normal client certificate instead of
CA certificates.
It seems as if opennssl doesn't consider the restrictions imposed by a
pathlength of zero or the configuration I use is incomplete.

Hope you can help me with this problem

Thanks  Regards
- Certificate of CA2 issued by Root CA ---
Certificate:
 Data:
 Version: 3 (0x2)
 Serial Number: 4122 (0x101a)
 Signature Algorithm: sha1WithRSAEncryption
 Issuer: C=.., ST=, L=.., O=..., OU=IT,
CN=CA/emailAddress=c...@testdomain.com
 Validity
 Not Before: Aug 20 17:02:11 2013 GMT
 Not After : May 16 17:02:11 2016 GMT
 Subject: C=.., ST=.., O=., OU=IT,
CN=CA2/emailAddress=c...@testdomain.com
 Subject Public Key Info:
 Public Key Algorithm: rsaEncryption
 RSA Public Key: (512 bit)
 Modulus (512 bit):
 00:d6:80:03:b9:83:a4:fa:8d:54:71:e2:9b:1e:ff:
 7a:f5:66:a5:f0:b8:95:fe:52:5c:06:0b:a5:48:8b:
 0a:63:62:d4:da:b2:c7:4d:cc:bb:6d:77:eb:d7:e4:
 d7:76:be:94:1e:26:75:9a:6c:40:63:99:2d:0c:3f:
 95:16:d2:d1:5f
 Exponent: 65537 (0x10001)
 X509v3 extensions:
 X509v3 Subject Key Identifier:
 5A:E4:98:4B:35:90:FE:F3:1F:9E:30:0E:10:31:1A:52:6E:25:73:B0
 X509v3 Authority Key Identifier:

keyid:0B:23:16:B4:6C:94:EE:EE:EF:3C:37:AB:0D:6A:75:9D:F2:6F:2F:27

DirName:/C=../ST=../L=./O=../OU=IT/CN=CA/emailAddress=c...@testdomain.com

  serial:EF:FC:FB:59:78:68:80:57
* X509v3 Basic Constraints: critical
 CA:TRUE, pathlen:0
* X509v3 Key Usage:
 Certificate Sign, CRL Sign
 Netscape Cert Type:
 SSL CA, S/MIME CA, Object Signing CA
 Signature Algorithm: sha1WithRSAEncryption

Re: OCSP and self signed

[Walter H.]

Eisenacher, Patrick wrote:

-Original Message-
From: Jakob Bohm

On 31-07-2013 11:02, Eisenacher, Patrick wrote:


-Original Message-
From: Jakob Bohm

On 30-07-2013 20:53, Walter H. wrote:


On 30.07.2013 19:51, Eisenacher, Patrick wrote:
  

Jakob, I don't understand your reasoning here.

You can't trust a signature of a compromised key. So if the root-ca's private
  

key gets compromised, you can't trust any of its issued crls and certificates
anymore.
This is where your and OpenSSL's logic fails:

If you receive a signed message from a CA saying it cannot be trusted, you
have 3 ways to react:

A) Just believe it and revoke the CA.

B) Assume it cannot have been legitimately generated and must thus have
   been created by means of a compromised key, thus concluding that the CA
   can no longer be trusted.

C) Ignore it and proceed as if you have not seen it, which is very, very
   stupid.

Because A and B have the same effect and require the same code, they are
equally good.

C is just plain crazy.


  As such, pre-generating a crl for the case the root-ca doesn't have access
  

to its private key anymore doesn't seem to make sense. The root-ca's only
choice here is communicating this fact out of band to its customers, so they
can remove the compromised root-ca certificate from their truststores,
which is exactly what is happening today. The browser vendors even put it
on an internal blacklist, so re-adding it to the truststore won't have any
effect. I can't see where openssl is broken in this regard.
All the recent out of band root revocations have involved revocation
against the will of a no longer trustworthy CA.  So the CA was not
communicating remove our root, and the trust store distributors had to
act out of band and take countermeasures in case the bad CA persisted in
socially engineering people to add them back in local trust stores.

My complaint is about situations where CA officials willingly revoke one
of their roots.



As I said before, there's no pki-inherent mechanism to revoke a self signed 
certificate other than to remove it from your truststore.
not really; a CA that has to revoke one of their root cert. - these are 
always self signed - uses a cert that comes from another root cert., or 
this root cert itself to sign the CRL where it revokes the compromised 
root cert;
doing so has a total different quality: the CA can't remove their 
compromised root cert from the trusted cert store of your system, but 
with the CRL they can tell your system, not to trust any cert that was 
signed by the compromised root cert;


for signing a CRL there is no restriction about the content; but for 
OCSP there exists a restriction: the cert used for signing the OCSP 
responders must have been signed by the same CA cert as the certs itself;
there exists a very strange situation when the CA cert has expired, 
because there is no CA cert available that can sign the OCSP responder 
certificate;


the only cert that can't be checked by OCSP is the root cert itself;

you would do a good job that your CA cert signs only certs, that will 
expire before the CA cert itself will expire ...


Greetings,
Walter


smime.p7s
Description: S/MIME Cryptographic Signature

Re: OCSP and self signed

[Walter H.]

On 31.07.2013 16:47, Jakob Bohm wrote:

the only cert that can't be checked by OCSP is the root cert itself;


This is where I disagree, can you point me to an actual reason why
not, which is not refuted by my logical ABC argument above. 
the Authority Information Access extension does not make any sense in 
root - self-signed - certs;


keep in mind: Google changes (or has already changed) the root cert. on 
their servers and this will not be noticed by any user in the world,
because the Google Internet Authority is issued by another CA that has 
its root in the trusted cert store of (nearly) every system in the world;


Greetings,
Walter



smime.p7s
Description: S/MIME Cryptographic Signature

Re: OCSP and self signed

[Walter H.]

On 30.07.2013 19:51, Eisenacher, Patrick wrote:

I was wondering how the root cert gets revoked. Anyway thanks for posting
that request.

A self-signed certificate can't be revoked via a crl, because you won't be able 
to successfully verify its signature.
keep in mind, that in case you detect a problem with your root 
certificate, you can revoke this cert, but have to use a different cert. 
for signing this CRL

  You have to communicate this fact out-of-band.

I never understood why some root-cas put a crldp extension into their own certs.


this has sense in any cert except the root (self-signed) cert.

Walter



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Building on Windows in 64 bit mode

[Walter H.]

 

Hello, 

look into the .DEF file, there is the information, which
type of dynamic library should be generated; 

it is very probable, that
your .DEF file is for 32-bit only; 

Walter 

Am 08.07.2013 10:59,
schrieb Andrew MARLOW: 

 Hello gentlemen,
 
 I am trying to build
openssl 1.0.1e on windows and am running into a few problems. I hope
someone will be able to help/advise.
 
 Following the instructions in
INSTALL.W32 seems to work for 32 bit release mode but not for other
combinations. Switching from Release to Debug does not result in the pdb
files being installed via the command nmake -f msntdll.mak install.
 

I tried to build in 64 bit by running vcvarsall amd64 then following the
build steps. The compilations were successful, with a few warnings about
conversions, but I got a linktime error:
 
 rc
/fotmp32dlllibeay32.res /d CRYPTO msversion32.rc
 link /nologo
/subsystem:console /opt:ref /debug /dll /out:out32dlllibeay32.dll
/def:ms/LIBEAY32.def @C:UsersmarlowaAppDataLocalTempnmEFE4.tmp

mp32dllx86cpuid.obj : fatal error LNK1112: module machine type 'X86'
conflicts with target machine type 'x64'
 MAKE : fatal error U1077:
'C:Program Files (x86)Microsoft Visual Studio 8VCBINamd64link.EXE' :
return code '0x458'
 Stop.
 
 I am on windows 7 (64 bit) using the
Visual Studio 2005 compiler.
 
 Googling, I see that others have hit
this problem as well:
 

http://comments.gmane.org/gmane.comp.encryption.openssl.devel/16256
[1]

http://stackoverflow.com/questions/2559358/fatal-error-lnk1112-module-machine-type-x86-conflicts-with-target-machine-typ
[2]

http://stackoverflow.com/questions/14704592/fatal-error-lnk1112-module-machine-type-x86-conflicts-with-target-machine-typ
[3]
 
 It looks to me like the 64 bit build is using some components
that came out of the 32 bit build, but I am not sure.
 
 Regards,
 

Andrew Marlow

 

Links:
--
[1]
http://comments.gmane.org/gmane.comp.encryption.openssl.devel/16256
[2]
http://stackoverflow.com/questions/2559358/fatal-error-lnk1112-module-machine-type-x86-conflicts-with-target-machine-typ
[3]
http://stackoverflow.com/questions/14704592/fatal-error-lnk1112-module-machine-type-x86-conflicts-with-target-machine-typ

Re: 0.9.8 vs 1.0.x

[Walter H.]

the major features that 1.0.x supports are

openssl ts (http://www.openssl.org/docs/apps/ts.html)
openssl cms (http://www.openssl.org/docs/apps/cms.html)

Greetings,
Walter


On 26.03.2013 18:50, Gopakumar Pillai wrote:


Hi,

Can any one point me to a location where I can find the major 
differences between versions 0.9.8 and 1.0.x?


Now that 0.9.8 may not live for long, planning to move to 1.0.x versions.

Are they API compatible? Any other restrictions?

Thank You in advance.

--Gopu





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Timestamp for Microsoft Authenticode?

[Walter H.]

On 25.03.2013 18:05, Jakob Bohm wrote:

This one lacks the data part, it seems to have been generated without
the -nodetach option.


- myreply02cms-asn1.text

This one has the data part, but lacks the signingTime attribute which
is the whole point of this exercise.


how can I correct this?

myreply03cms-asn1.text doesn't work either, same error

Thanks,
Walter
   0 3272: SEQUENCE {
   49:   OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
  15 3257:   [0] {
  19 3253: SEQUENCE {
  231:   INTEGER 1
  269:   SET {
  287: SEQUENCE {
  305:   OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
 :   }
 : }
  37  275:   SEQUENCE {
  419: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
  52  260: [0] {
  56  256:   OCTET STRING
 : 58 96 1F 89 99 E5 40 D4 4F F8 22 6B A8 B1 BC B4
 : 76 1C 58 30 59 82 4A B7 71 C7 6B 3D 5C 5D 9B A8
 : D6 93 D2 51 55 D3 BD BA 52 31 0F B5 A5 32 DD 23
 : BF 56 C4 96 6F E2 01 1D 40 01 66 6C CD 20 A7 35
 : 56 AE 0E C5 B8 A4 99 64 49 9A 9D C7 C8 DB 25 6C
 : 7B 28 C4 39 49 BA 22 44 63 84 40 9E B0 FF A3 53
 : 66 7D 22 01 7A FD D0 99 1C D9 B9 4E 86 CF 28 4D
 : 52 E5 DE 57 63 5C 8C 2B 74 FF 06 0E 4F 23 7B 3D
 : [ Another 128 bytes skipped ]
 :   }
 : }
 316 2330:   [0] {
 320 2326: SEQUENCE {
 324 1790:   SEQUENCE {
 3283: [0] {
 3301:   INTEGER 2
 :   }
 333   17: INTEGER 00 FB 3C 5C 98 3E E3 B7 65 C5 49 61 7C 8A 07 21 
F8
 352   13: SEQUENCE {
 3549:   OBJECT IDENTIFIER
 : sha1WithRSAEncryption (1 2 840 113549 1 1 5)
 3650:   NULL
 :   }
 367  211: SEQUENCE {
 370   29:   SET {
 372   27: SEQUENCE {
 3743:   OBJECT IDENTIFIER commonName (2 5 4 3)
 379   20:   PrintableString 'WaldiNetwork Root CA'
 :   }
 : }
 401   26:   SET {
 403   24: SEQUENCE {
 4053:   OBJECT IDENTIFIER organizationName (2 5 4 10)
 410   17:   PrintableString 'WaldiNetwork Ltd.'
 :   }
 : }
 429   31:   SET {
 431   29: SEQUENCE {
 4333:   OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
 438   22:   PrintableString 'WaldiNetwork Ltd. Home'
 :   }
 : }
 462   13:   SET {
 464   11: SEQUENCE {
 4663:   OBJECT IDENTIFIER localityName (2 5 4 7)
 4714:   PrintableString 'Linz'
 :   }
 : }
 477   22:   SET {
 479   20: SEQUENCE {
 4813:   OBJECT IDENTIFIER stateOrProvinceName (2 5 4 8)
 486   13:   PrintableString 'Upper Austria'
 :   }
 : }
 501   11:   SET {
 5039: SEQUENCE {
 5053:   OBJECT IDENTIFIER countryName (2 5 4 6)
 5102:   PrintableString 'AT'
 :   }
 : }
 514   42:   SET {
 516   40: SEQUENCE {
 5189:   OBJECT IDENTIFIER
 : emailAddress (1 2 840 113549 1 9 1)
 529   27:   IA5String 'waldinetwork.h...@liwest.at'
 :   }
 : }
 558   21:   SET {
 560   19: SEQUENCE {
 5623:   OBJECT IDENTIFIER serialNumber (2 5 4 5)
 567   12:   PrintableString '47110815wldi'
 :   }
 : }
 :   }
 581   30: SEQUENCE {
 583   13:   UTCTime 26/10/2012 00:00:00 GMT
 598   13:   UTCTime 26/10/2017 23:59:59 GMT
 :   }
 613  227: SEQUENCE {
 616   45:   SET {
 618   43: SEQUENCE {
 6203:   OBJECT IDENTIFIER commonName (2 5 4 3)
 625   36:   PrintableString 'WaldiNetwork Time-Stamping 
Service 1'
 :   }
 : }
 663   26:   SET {
 665   24: SEQUENCE {
 6673:   OBJECT IDENTIFIER organizationName (2 5 4 10)
 672   17:   PrintableString 'WaldiNetwork Ltd.'
 :   }
 : }
 691   31:   SET {
 693   29:  

Re: Timestamp for Microsoft Authenticode?

[Walter H.]

Hi,

thanks for your infos

can you please tell me, where I can find your postings to this topic, 
you made in the past?


On 19.03.2013 20:07, Jakob Bohm wrote:
Won't work (as you saw), this function doesn't take the actual 
ContentInfo structure as input, but data which it will (mis)treat

as an e-mail and then wrap in its own ContentInfo.  Notice how the
messageDigest in your result is not the one in the result from the
original RSADSI/VeriSign/Thawte/Symantec server.

When the input specifies a content type of data, you could use
the bytes inside the inner OCTET STRING as input to cms like this
   openssl cms -sign -binary -content filewithrawdata.bin -outform DER
how should this work, because when calling openssl like this expects 
input from stdin ...

to get something close to the right response, but this won't work
if the request specifies a different content type.

I think there was a SourceForge project related to this
   (http://sf.net/projects/osslsigncode/)
But I don't know its status.


this is a good project, but I already have signcode.exe / signtool.exe;
I want to create the timestamp server part ..., using OpenSSL

I havn't used the OpenSSL source before ...

Thanks for any help,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature

Re: possible Bug in OpenSSL - rfc 3161 - TSA service

[Walter H.]

On 17.03.2013 16:37, kap...@mizera.cz wrote:



Dne 16.3.2013 20:58, Walter H. napsal(a):


I tried this with my Adobe Acrobat,
and you wouldn't believe it; it doesn't work with Adobe Acrobat, too.

the error message - I use German version:
Fehler beim Erstellen der Unterschriftseigenschaften des Zeitstempels:
Verifizierungsfehler
in English this is
Error on creating the signature properties of the timestamp:
verification error

so that means, this is not conforming to RFC 3161 ..., because Adobe
Acrobat does ...


But it could be consequence of using this testing TSA - maybe could 
help to add the root certificate of this testing TSA chain ?



(Obwohl die Fehlermeldung  scheint etwas anderes zu bedeuten als 
untrusted TSA).


correct, the error message means, that the received timestamp could not 
be verified - the same as you had ...

OpenSSL and Adobe conform to RFC 3161;
but not this TSA ...




smime.p7s
Description: S/MIME Cryptographic Signature

Re: possible Bug in OpenSSL - rfc 3161 - TSA service

[Walter H.]

On 17.03.2013 18:48, kap...@mizera.cz wrote:

be verified - the same as you had ...
OpenSSL and Adobe conform to RFC 3161;
but not this TSA ...

correct, the error message means, that the received timestamp could not


But the discussed TSA postsignum would not exist at all if there would 
be a problem with signed PDF's (it is most used usage).

the other use is Microsoft Authenticode, but this is different protocol;
The problem there is that only OpenSSL fails to verify their TS's 
(what does not care them much, unfortunately).


Adobe also fails ..., as I have tried ...; it would be nonsense, when 
the Test TSA fails and the Production TSA passes,
because, they want money for generated time stamps, and nobody will 
trust this, because of failing Test TSA;

?= it could be probably problem on yours side.

not really ...

What Adobe product and version are you using ? Maybe too old ?

not newest, but RFC 3161 is old, too

It is possible that Adobe has add attr.cert. support (CMS, ...).


can you please tell me, what an attr.cert is?
because every cert has attributes ...

And does it work with another official TSA ?
E.g. with TSA service: http://timestamp.comodoca.com/rfc3161

yes with this and some other;

- timestamp.geotrust.com
- universign.eu
- ca.signfiles.com
- tsa.starfieldtech.com





smime.p7s
Description: S/MIME Cryptographic Signature

Re: possible Bug in OpenSSL - rfc 3161 - TSA service

[Walter H.]

On 16.03.2013 19:27, kap...@mizera.cz wrote:

Dne 16.3.2013 12:58, Walter H. napsal(a):

Unfortunately not, it is official paid service.
But You can make tests on testing TSA:
http://www.postsignum.cz/testovaci_casova_razitka.html

I don't understand this language; can you tell me the URL of this 
Test TSA?


Try to use translate.google.com (just enter the link and translate)

URL 1: https://www3.postsignum.cz/DEMOTSA/TSS_user/
URL 2: https://www.postsignum.cz/DEMOTSA/TSS_user/

Username: demoTSA
Password: demoTSA2010


lets have a try ...



But unfortunately our laws do not accept other TS then these from
qualified TSAs authorised by our government.


a little bit strange;
do they operate an atomic clock?


Yes. They specially use attribute certificate to evidence the time is 
synchronized. Funny is that it is the one certificate, which makes 
problems while verify the TSR in openssl.

Ok,
I tried this with my Adobe Acrobat,
and you wouldn't believe it; it doesn't work with Adobe Acrobat, too.

the error message - I use German version:
Fehler beim Erstellen der Unterschriftseigenschaften des Zeitstempels: 
Verifizierungsfehler

in English this is
Error on creating the signature properties of the timestamp: 
verification error


so that means, this is not conforming to RFC 3161 ..., because Adobe 
Acrobat does ...


Greetings,
Walter




smime.p7s
Description: S/MIME Cryptographic Signature

Re: possible Bug in OpenSSL - rfc 3161 - TSA service

[Walter H.]

On 13.03.2013 01:19, kap...@mizera.cz wrote:


Dne 12.3.2013 20:36, Walter H. napsal(a):

Hello,

I found the following:

http://tsa.postsignum.cz:444


do you have account by this TSA ?


No.
if there is a need to have an account; then this page is not conforming 
to any RFC - HTTP 400 is not an indicator for wrong login credentials; 
this must be 401


produces the following error, when using this as time stamp server with
adobe standard/pro

BER decoding error


Are you sure you (adobe program) get timestamp and not just HTML error 
page ?

Try to get TSReply manually with CURL:

are you shure this TSA is working at all?
openssl ts -query -data file.txt -sha256 -cert -no_nonce 
file.txt-nononce-sha256-cert.tsq


curl -k -v -H Content-Type: application/timestamp-query -u 
name:password --data-binary @file.txt-nononce-
sha256-cert.tsq https://tsa.postsignum.cz:444 
file.txt-nononce-sha256-cert.postsignum.tsr


what do you mean with my solution with OpenSSL works ?

that my OpenSSL TS server works ...

That you use own testing, opennsl based TS server ?

correct
If yes and only timestamps from  tsa.postsignum.cz:444 server cause 
this problem then it would be interesting, because the CA (TS 
Authority) claims that only openssl client has problem with their 
timestamps.
can you give me for a try userid and pwd, then I may find out where the 
bug is;

try this:
https://timestamp.geotrust.com/
(this is really free, no auth. neccessary)

Adobe client no.


which Adobe version they claim not having problems with ...?

Greetings
Walter



smime.p7s
Description: S/MIME Cryptographic Signature

Re: openssl-user - UTF8 characters in configuration file

[Walter H.]

Hello John,

I had the same problem; the solution is just:

UTF8String or UTF8 and not UTF8STRING

Walter

On 14.03.2013 17:06, rasmu...@us.ibm.com wrote:
I'm using the following configuration file section in an attempt to 
create a CA with UTF8 characters in subject (and other) fields.


string_mask = utf8only
prompt  = no

[ req ]

default_bits= 2048
default_keyfile = /opt/rasmussjCa/private/cakey.pem
default_md  = md5
prompt  = no
distinguished_name  = root_ca_distinguished_name
x509_extensions = root_ca_extensions

[ root_ca_distinguished_name ]

commonName  = UTF8STRING:Root
stateOrProvinceName = MA
countryName = US
emailAddress= r...@abc.com
organizationName= abc

When I use commonName  = UTF8STRING:Root, I am getting a 
format=PRINTABLESTRING containing the UTF8STRING:Root value


   45:d=5  hl=2 l=   3 prim: OBJECT:commonName
   50:d=5  hl=2 l=  15 prim: PRINTABLESTRING   :UTF8STRING:Root

Not a UTF8STRING format as I'm expecting such as this ...

  108:d=5  hl=2 l=   3 prim: OBJECT:commonName
  113:d=5  hl=2 l=  23 prim: UTF8STRING:XX

In addition to string_mask = utf8, I've also tried the -utf8 option 
on the req with the same results:


openssl req -x509 -newkey rsa:1024 -out rootcacert.pem -utf8 -outform PEM

+++

In addition when I try to assign a policy root_commonName to the 
commonName field


commonName  = root_commonName
stateOrProvinceName = MA
countryName = US
emailAddress= r...@abc.com
organizationName= abc

[ root_commonName ]

commonName  = UTF8STRING:Root

I am am just getting the root_commonName policy assigned to the 
field rather than the UTF8STRING:Root value assigned within the policy


  174:d=5  hl=2 l=   3 prim: OBJECT:commonName
  179:d=5  hl=2 l=  15 prim: T61STRING :root_commonName

Any comments are greatly appreciated.

Thanks

John 




smime.p7s
Description: S/MIME Cryptographic Signature

Re: possible Bug in OpenSSL - rfc 3161 - TSA service

[Walter H.]

Hello,

I found the following:

http://tsa.postsignum.cz:444

produces the following error, when using this as time stamp server with 
adobe standard/pro


BER decoding error

what software do they use?

my solution with OpenSSL works ...

Greetings,
Walter



smime.p7s
Description: S/MIME Cryptographic Signature