Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[stunnel-users] Difference between verify=2, 3 and 4
1,067 views
Skip to first unread message
Nikolaus Rath
Sep 14, 2013, 1:55:14 AM9/14/13
to
Hello,
Thanks for writing stunnel, it looks like a great tool!
I have, however, a really hard time understanding the difference between
verify=2,3 and 4. In the manpage, I found
verify = level
verify peer certificate
level 0 - request and ignore peer certificate
level 1 - verify peer certificate if present
level 2 - verify peer certificate
level 3 - verify peer with locally installed certificate
level 4 - ignore CA chain and only verify peer certificate
default - no verify
Levels 0-2 seem pretty clear cut, but then it becomes confusing for me.
First, I do not understand how level 3 differs from level2. What does
"against a locally installed certificate" mean? It seems to me that I
certainly need to have a local copy of the trusted CAs even in level 2
-- at least I hope that they aren't somehow build in to stunnel. But
there is also just one CApath option, so will that be used for level 2
or level 3?
For level 4, the "ignore the CA chain" path is fine -- but where do I
put the peer certificates that I'm willing to accept? CApath seems
wrong, but cert is already used for the server's own certificate...
Best,
-Nikolaus
--
»Time flies like an arrow, fruit flies like a Banana.«
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
_______________________________________________
stunnel-users mailing list
stunne...@stunnel.org
https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
Javier
Sep 16, 2013, 7:17:16 PM9/16/13
to
On Fri, 13 Sep 2013 22:55:14 -0700
Nikolaus Rath <Niko...@rath.org> wrote:
> Hello,
>
> Thanks for writing stunnel, it looks like a great tool!
>
> I have, however, a really hard time understanding the difference between
> verify=2,3 and 4. In the manpage, I found
>
> verify = level
> verify peer certificate
>
> level 0 - request and ignore peer certificate
> level 1 - verify peer certificate if present
> level 2 - verify peer certificate
> level 3 - verify peer with locally installed certificate
> level 4 - ignore CA chain and only verify peer certificate
> default - no verify
>
> Levels 0-2 seem pretty clear cut, but then it becomes confusing for me.
>
> First, I do not understand how level 3 differs from level2. What does
> "against a locally installed certificate" mean? It seems to me that I
> certainly need to have a local copy of the trusted CAs even in level 2
> -- at least I hope that they aren't somehow build in to stunnel. But
> there is also just one CApath option, so will that be used for level 2
> or level 3?
Hi,
Nikolaus Rath <Niko...@rath.org> wrote:
> Hello,
>
> Thanks for writing stunnel, it looks like a great tool!
>
> I have, however, a really hard time understanding the difference between
> verify=2,3 and 4. In the manpage, I found
>
> verify = level
> verify peer certificate
>
> level 0 - request and ignore peer certificate
> level 1 - verify peer certificate if present
> level 2 - verify peer certificate
> level 3 - verify peer with locally installed certificate
> level 4 - ignore CA chain and only verify peer certificate
> default - no verify
>
> Levels 0-2 seem pretty clear cut, but then it becomes confusing for me.
>
> First, I do not understand how level 3 differs from level2. What does
> "against a locally installed certificate" mean? It seems to me that I
> certainly need to have a local copy of the trusted CAs even in level 2
> -- at least I hope that they aren't somehow build in to stunnel. But
> there is also just one CApath option, so will that be used for level 2
> or level 3?
They differ in how you manage certificates to validate them.
The level 2 verify the peer certificate against CA (CAfile).
The level 3 verify the peer certificate against CA and also with a local copy
of that certificate in the CAfile. In other words, in addition to the CAs
certificates you'll have the incoming peer certificates in that file. And you
verify that not only is valid against the CA, but against the certificate itself,
in that file.
It's a way of a double check to ensure it's not a fake certificate.
> For level 4, the "ignore the CA chain" path is fine -- but where do I
> put the peer certificates that I'm willing to accept? CApath seems
> wrong, but cert is already used for the server's own certificate...
I didn't use level 4, but if I'm not wrong, it doesn't check for a local certificate
but just the top CA, without the full CAs chain (all CAs part of the certificate).
If no one corrects me, L4 is as I told. But the best way is to test it.
Regards.
Michal Trojnara
Sep 19, 2013, 3:05:44 PM9/19/13
to
On 2013-09-17 01:17, Javier wrote:
> I didn't use level 4, but if I'm not wrong, it doesn't check for a local certificate
> but just the top CA, without the full CAs chain (all CAs part of the certificate).
>
> If no one corrects me, L4 is as I told. But the best way is to test it.
It looks like I'll be the one to correct you. It is the opposite:
> I didn't use level 4, but if I'm not wrong, it doesn't check for a local certificate
> but just the top CA, without the full CAs chain (all CAs part of the certificate).
>
> If no one corrects me, L4 is as I told. But the best way is to test it.
"verify = 4" *only* checks your peer certificate, ignoring all the other
certs in the chain. The rationale behind this mode is to be able to use:
1. Specific certificates issued by CAs you don't trust for any other
certificates. This can also be achieved by "verify = 3".
2. Specific certificates issued by CAs for which you don't *have* the
root certificate. This may happen, as SSL does only requires servers to
send the remaining part of the chain. Sending the root certificate
itself is optional.
IMHO most stunnel deployments *should* use "verify = 4".
Mike
Javier
Sep 19, 2013, 10:30:32 PM9/19/13
to
On Thu, 19 Sep 2013 21:05:44 +0200
Michal Trojnara <Michal....@mirt.net> wrote:
> On 2013-09-17 01:17, Javier wrote:
> > I didn't use level 4, but if I'm not wrong, it doesn't check for a local certificate
> > but just the top CA, without the full CAs chain (all CAs part of the certificate).
> >
> > If no one corrects me, L4 is as I told. But the best way is to test it.
>
> It looks like I'll be the one to correct you.
Hi.
Michal Trojnara <Michal....@mirt.net> wrote:
> On 2013-09-17 01:17, Javier wrote:
> > I didn't use level 4, but if I'm not wrong, it doesn't check for a local certificate
> > but just the top CA, without the full CAs chain (all CAs part of the certificate).
> >
> > If no one corrects me, L4 is as I told. But the best way is to test it.
>
> It looks like I'll be the one to correct you.
Better you, as the developer, than anyone else haha. So, glad you did :)
> It is the opposite:
> "verify = 4" *only* checks your peer certificate, ignoring all the other
> certs in the chain. The rationale behind this mode is to be able to use:
> 1. Specific certificates issued by CAs you don't trust for any other
> certificates. This can also be achieved by "verify = 3".
> 2. Specific certificates issued by CAs for which you don't *have* the
> root certificate. This may happen, as SSL does only requires servers to
> send the remaining part of the chain. Sending the root certificate
> itself is optional.
>
> IMHO most stunnel deployments *should* use "verify = 4".
But a bit contradictory to accept a certificate that has been issued by a CA
you don't trust, just for the main purpose of establish an SSL connection.
It depends in the service you are offering, I guess.
I the other hand, I mainly use Stunnel in client mode.
Thanks for the explanation, Michal :)
Nikolaus Rath
Sep 19, 2013, 11:27:17 PM9/19/13
to
Michal Trojnara <Michal....@mirt.net> writes:
> On 2013-09-17 01:17, Javier wrote:
>> I didn't use level 4, but if I'm not wrong, it doesn't check for a local certificate
>> but just the top CA, without the full CAs chain (all CAs part of the certificate).
>>
>> If no one corrects me, L4 is as I told. But the best way is to test it.
>
> It looks like I'll be the one to correct you. It is the opposite:> On 2013-09-17 01:17, Javier wrote:
>> I didn't use level 4, but if I'm not wrong, it doesn't check for a local certificate
>> but just the top CA, without the full CAs chain (all CAs part of the certificate).
>>
>> If no one corrects me, L4 is as I told. But the best way is to test it.
>
> "verify = 4" *only* checks your peer certificate, ignoring all the other
> certs in the chain. The rationale behind this mode is to be able to use:
> 1. Specific certificates issued by CAs you don't trust for any other
> certificates. This can also be achieved by "verify = 3".
> 2. Specific certificates issued by CAs for which you don't *have* the
> root certificate. This may happen, as SSL does only requires servers to
> send the remaining part of the chain. Sending the root certificate
> itself is optional.
>
> IMHO most stunnel deployments *should* use "verify = 4".
Thanks for explanations. So in which case would I ever use 3? Somehow I
can't think of such a situation. If I already explicitly trust a
specific certificate, why would I be interested in checking the CA
chain?
Best,
-Nikolaus
--
»Time flies like an arrow, fruit flies like a Banana.«
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
Michal Trojnara
Sep 20, 2013, 1:28:37 AM9/20/13
to
On 2013-09-20 05:27, Nikolaus Rath wrote:
>> IMHO most stunnel deployments *should* use "verify = 4".
> Thanks for explanations. So in which case would I ever use 3? Somehow I
> can't think of such a situation. If I already explicitly trust a
> specific certificate, why would I be interested in checking the CA
> chain?
Good point. The reason is historical: "verify = 4" was added just 2
>> IMHO most stunnel deployments *should* use "verify = 4".
> Thanks for explanations. So in which case would I ever use 3? Somehow I
> can't think of such a situation. If I already explicitly trust a
> specific certificate, why would I be interested in checking the CA
> chain?
years ago. As stunnel is 15 years old I decided to keep "verify = 3"
for backward compatibility. Alternatively I could have replaced the
existing functionality of "verify = 3", but most people expect
modifications of the already defined functionality on software updates
to be as small as possible.
Mike
Michal Trojnara
Sep 20, 2013, 1:36:23 AM9/20/13
to
On 2013-09-20 04:30, Javier wrote:
> But a bit contradictory to accept a certificate that has been issued by a CA
> you don't trust, just for the main purpose of establish an SSL connection.
It seems to be contradictory, but it is not. You often cannot control
> But a bit contradictory to accept a certificate that has been issued by a CA
> you don't trust, just for the main purpose of establish an SSL connection.
the certificate of your peer server. In case its certificate is issued
by a large CA, you really want to make sure you're connecting to this
specific server, and not any other server with certificate issued by the
same CA. Web browsers use CNAME/SubjectAltName verification to solve
the same problem in a different way.
Mike
Thomas Eifert
Sep 20, 2013, 4:10:27 AM9/20/13
to
On 9/16/2013 6:17 PM, Javier wrote:
> I didn't use level 4, but if I'm not wrong, it doesn't check for a
> local certificate but just the top CA, without the full CAs chain (all
> CAs part of the certificate). If no one corrects me, L4 is as I told.
> But the best way is to test it.
certificate only. Yet, I'm currently
using at least one peer certificate that requires the top CA to be
present in the .pem file. If I remove it,
L4 fails. Go figure.
Best regards,
Thomas
--
Attention: This message and all attachments are private and may contain information that is confidential and privileged. If you received this message in error, please notify the sender by reply email and delete the message immediately.
Michal Trojnara
Sep 20, 2013, 6:16:46 AM9/20/13
to
On 09/20/2013 10:10 AM, Thomas Eifert wrote:
> Testing is the best way, for sure. In theory, L4 checks for the peer
> certificate only. Yet, I'm currently
> using at least one peer certificate that requires the top CA to be
> present in the .pem file. If I remove it,
> L4 fails. Go figure.
I wasn't able to reproduce this issue. Could you send some more details.
> Testing is the best way, for sure. In theory, L4 checks for the peer
> certificate only. Yet, I'm currently
> using at least one peer certificate that requires the top CA to be
> present in the .pem file. If I remove it,
> L4 fails. Go figure.
A step-by-step procedure to would be great.
Mike
Jochen Bern
Sep 20, 2013, 6:34:32 AM9/20/13
to
On 20.09.2013 04:30, Javier wrote:
> But a bit contradictory to accept a certificate that has been issued by a CA
> you don't trust, just for the main purpose of establish an SSL connection.
Why? I can easily see a provider (say, e-mail) buying a server cert from
> But a bit contradictory to accept a certificate that has been issued by a CA
> you don't trust, just for the main purpose of establish an SSL connection.
an ultra-el-cheapo CA that *I* wouldn't trust to hold the door open for
me. As long as that CA only gets the CSR from the provider (and never
sees the private key), there's no reason why I shouldn't trust *the
keypair*, though. And the server cert effectively is the embodiment of
that keypair / the pubkey in the SSL exchange.
(And "I don't care about the CA, just gimme encryption to prevent
eavesdropping" *is* how web browsers used HTTPS for quite some time.
Which then got supplanted by "everyone works along the list of CAs that
come preinstalled in browsers today" ... :-S )
On 20.09.2013 05:27, Nikolaus Rath wrote:
> So in which case would I ever use 3? Somehow I
> can't think of such a situation. If I already explicitly trust a
> specific certificate, why would I be interested in checking the CA
> chain?
corresponding revocations becoming available to your machine (by OS
updates, OCSP, whatever) before you hear of the incident.
Regards,
J. Bern
--
*NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>:
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/>
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel
Nikolaus Rath
Sep 20, 2013, 12:25:24 PM9/20/13
to
Jochen Bern <Joche...@LINworks.de> writes:
> On 20.09.2013 05:27, Nikolaus Rath wrote:
>> So in which case would I ever use 3? Somehow I
>> can't think of such a situation. If I already explicitly trust a
>> specific certificate, why would I be interested in checking the CA
>> chain?
>
> Imagine the CA (or one of the intermediate CAs) getting compromised and
> corresponding revocations becoming available to your machine (by OS
> updates, OCSP, whatever) before you hear of the incident.
> On 20.09.2013 05:27, Nikolaus Rath wrote:
>> So in which case would I ever use 3? Somehow I
>> can't think of such a situation. If I already explicitly trust a
>> specific certificate, why would I be interested in checking the CA
>> chain?
>
> Imagine the CA (or one of the intermediate CAs) getting compromised and
> corresponding revocations becoming available to your machine (by OS
> updates, OCSP, whatever) before you hear of the incident.
FWIW, I still don't see why I'd use verify=3 in that case.
Best,
Nikolaus
--
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
»Time flies like an arrow, fruit flies like a Banana.«
Thomas Eifert
Sep 20, 2013, 12:38:43 PM9/20/13
to
Mike,
Okay, here's the simple way to test it. This is repeatable in Stunnel
4.56 and 5.00:
Start with a simple stunnel.conf:
debug = 6
fips = no
delay = yes
output = stunnel.log
[nntps.3]
client = yes
accept = 127.0.0.1:119
connect = news.eternal-september.org:563
Point your favorite newsreader to 127.0.0.1/119, then connect to the
server.
Having done that, open the stunnel log window. From the menu bar,
choose "save peer certificate".
Save the certificate, which will now be "peer-nntps.3.pem" in the
stunnel directory.
Add certificate verification to stunnel conf:
[nntps.3]
client = yes
cafile = peer-nntps.3.pem
verify = 4
accept = 127.0.0.1:119
connect = news.eternal-september.org:563
Reload the configuration file.
Attempt to reconnect to the server. The certificate verify will fail:
2013.09.20 11:12:35 LOG4[3964]: CERT: Verification error: unable to get
local issuer certificate
2013.09.20 11:12:35 LOG4[3964]: Certificate check failed: depth=0,
/description=z8x2a0S5FjpJGCa7/C=DE/CN=news.eternal-september.org/emailAddress=wolf...@weyand-hg.de
2013.09.20 11:12:35 LOG3[3964]: SSL_connect: 14090086:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
verify failed
If you paste the certificate for the root CA into the peer-nntps.3.pem
file, then it will verify okay.
I have a feeling you'll find something wrong with the certificate that's
causing this to happen. The guy that runs the server
likes to "roll his own".
Best regards,
Thomas
On 9/20/2013 5:16 AM, Michal Trojnara wrote:
> On 09/20/2013 10:10 AM, Thomas Eifert wrote:
>> Testing is the best way, for sure. In theory, L4 checks for the peer
>> certificate only. Yet, I'm currently
>> using at least one peer certificate that requires the top CA to be
>> present in the .pem file. If I remove it,
>> L4 fails. Go figure.
>
> I wasn't able to reproduce this issue. Could you send some more details.
> A step-by-step procedure to would be great.
>
> Mike
Okay, here's the simple way to test it. This is repeatable in Stunnel
4.56 and 5.00:
Start with a simple stunnel.conf:
debug = 6
fips = no
delay = yes
output = stunnel.log
[nntps.3]
client = yes
accept = 127.0.0.1:119
connect = news.eternal-september.org:563
Point your favorite newsreader to 127.0.0.1/119, then connect to the
server.
Having done that, open the stunnel log window. From the menu bar,
choose "save peer certificate".
Save the certificate, which will now be "peer-nntps.3.pem" in the
stunnel directory.
Add certificate verification to stunnel conf:
[nntps.3]
client = yes
cafile = peer-nntps.3.pem
verify = 4
accept = 127.0.0.1:119
connect = news.eternal-september.org:563
Reload the configuration file.
Attempt to reconnect to the server. The certificate verify will fail:
2013.09.20 11:12:35 LOG4[3964]: CERT: Verification error: unable to get
local issuer certificate
2013.09.20 11:12:35 LOG4[3964]: Certificate check failed: depth=0,
/description=z8x2a0S5FjpJGCa7/C=DE/CN=news.eternal-september.org/emailAddress=wolf...@weyand-hg.de
2013.09.20 11:12:35 LOG3[3964]: SSL_connect: 14090086:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
verify failed
If you paste the certificate for the root CA into the peer-nntps.3.pem
file, then it will verify okay.
I have a feeling you'll find something wrong with the certificate that's
causing this to happen. The guy that runs the server
likes to "roll his own".
Best regards,
Thomas
On 9/20/2013 5:16 AM, Michal Trojnara wrote:
> On 09/20/2013 10:10 AM, Thomas Eifert wrote:
>> Testing is the best way, for sure. In theory, L4 checks for the peer
>> certificate only. Yet, I'm currently
>> using at least one peer certificate that requires the top CA to be
>> present in the .pem file. If I remove it,
>> L4 fails. Go figure.
>
> I wasn't able to reproduce this issue. Could you send some more details.
> A step-by-step procedure to would be great.
>
> Mike
> _______________________________________________
> stunnel-users mailing list
> stunne...@stunnel.org
> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
>
> stunnel-users mailing list
> stunne...@stunnel.org
> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
>
--
Attention: This message and all attachments are private and may contain information that is confidential and privileged. If you received this message in error, please notify the sender by reply email and delete the message immediately.
Attention: This message and all attachments are private and may contain information that is confidential and privileged. If you received this message in error, please notify the sender by reply email and delete the message immediately.
Ludolf Holzheid
Sep 20, 2013, 1:29:38 PM9/20/13
to
On Fri, 2013-09-20 09:25:24 -0700, Nikolaus Rath wrote:
> Jochen Bern <Joche...@LINworks.de> writes:
> > On 20.09.2013 05:27, Nikolaus Rath wrote:
> >> So in which case would I ever use 3? Somehow I
> >> can't think of such a situation. If I already explicitly trust a
> >> specific certificate, why would I be interested in checking the CA
> >> chain?
> >
> > Imagine the CA (or one of the intermediate CAs) getting compromised and
> > corresponding revocations becoming available to your machine (by OS
> > updates, OCSP, whatever) before you hear of the incident.
>
> FWIW, I still don't see why I'd use verify=3 in that case.
Nikolaus,
> Jochen Bern <Joche...@LINworks.de> writes:
> > On 20.09.2013 05:27, Nikolaus Rath wrote:
> >> So in which case would I ever use 3? Somehow I
> >> can't think of such a situation. If I already explicitly trust a
> >> specific certificate, why would I be interested in checking the CA
> >> chain?
> >
> > Imagine the CA (or one of the intermediate CAs) getting compromised and
> > corresponding revocations becoming available to your machine (by OS
> > updates, OCSP, whatever) before you hear of the incident.
>
> FWIW, I still don't see why I'd use verify=3 in that case.
With verify=3, you don't explicitly trust the peer certificate, but
you restrict the use of /valid/ certificates issued by a certain CA to
the ones locally installed.
Revoking the server certificate or one of the intermediate
certificates renders the peer certificate as invalid and stunnel will
reject it (if the CRLs are available to stunnel), even though it still
is locally installed.
Ludolf
--
Bihl+Wiedemann GmbH
Floßwörthstraße 41
68199 Mannheim, Germany
Tel: +49 621 33996-0
Fax: +49 621 3392239
mailto:lhol...@bihl-wiedemann.de
http://www.bihl-wiedemann.de
Sitz der Gesellschaft: Mannheim
Geschäftsführer: Jochen Bihl, Bernhard Wiedemann
Amtsgericht Mannheim, HRB 5796
Jochen Bern
Sep 20, 2013, 2:33:16 PM9/20/13
to
On 20.09.2013 18:25, Nikolaus Rath wrote:
> Jochen Bern <Joche...@LINworks.de> writes:
>> On 20.09.2013 05:27, Nikolaus Rath wrote:
>>> So in which case would I ever use 3? Somehow I
>>> can't think of such a situation. If I already explicitly trust a
>>> specific certificate, why would I be interested in checking the CA
>>> chain?
>>
>> Imagine the CA (or one of the intermediate CAs) getting compromised and
>> corresponding revocations becoming available to your machine (by OS
>> updates, OCSP, whatever) before you hear of the incident.
>
> FWIW, I still don't see why I'd use verify=3 in that case.
> Jochen Bern <Joche...@LINworks.de> writes:
>> On 20.09.2013 05:27, Nikolaus Rath wrote:
>>> So in which case would I ever use 3? Somehow I
>>> can't think of such a situation. If I already explicitly trust a
>>> specific certificate, why would I be interested in checking the CA
>>> chain?
>>
>> Imagine the CA (or one of the intermediate CAs) getting compromised and
>> corresponding revocations becoming available to your machine (by OS
>> updates, OCSP, whatever) before you hear of the incident.
>
> FWIW, I still don't see why I'd use verify=3 in that case.
Because verify=4 doesn't know the CA chain (barring the oddity reported
by Thomas) and thus would not consider the server cert invalid because
of the CA cert revocation.
Whether you *want* that to happen is a somewhat different question.
Under normal circumstances, one would expect such a situation to result
in the server operators installing a new server cert from another CA, at
which point your stunnel setup will stop working, anyway. (Unless the
attacker was able to snarf the server's privkey from the CA's archives
and has already set up a MitM attack against *your* connections.) In
other words, using 4 instead of 3 where possible gains you maybe a
couple days of continued operation, at the expense of probably not
learning that fast *how* the CA was compromised and what that means for
the trustworthiness of the server cert.
(I currently have another case at hand where the difference would be
much more pronounced, though. IMHO the CA blundered there - as in, the
server cert is valid until late 2015, but one intermediate CA's cert
expires early in 2014. Ho hum ... !)
Regards,
J. Bern
--
*NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>:
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/>
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel
0 new messages