The day I lost my job due to monit

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

The day I lost my job due to monit

rexkogitans@gmx.at
I configured monit to monitor the TLS certificate validity of all of our
highly productive websites. To all websites, the unnecessary full
certificate (without root CA) was installed. However, on 30th of May
2020 one of the chain certificates (COMODO) ran out of its validity
period. Obviously monit only checks for the server certificate, that's
why the check did not notice this, and such a check is completely
pointless. It led to a massive damage to my company, and since I was to
deal with monitoring as well as TLS certificates, I had to move on to
find a new job.

During the notice period, I implemented an own check in PHP and let
monit execute this PHP program to check TLS certificates. This PHP
program did not just check the entire chain, but also the chain against
the system's own trust store (in /etc/ssl/certs). I think it would be an
interesting feature to deal with TLS certificates like this in monit in
order to avoid more people losing the jobs.


Reply | Threaded
Open this post in threaded view
|

Re: The day I lost my job due to monit

monit-general mailing list
You didn't lose your job due to monit, by your own description of what took place. The proximate cause was Comodo.

On December 4, 2020 7:52:55 AM PST, "[hidden email]" <[hidden email]> wrote:
I configured monit to monitor the TLS certificate validity of all of our
highly productive websites. To all websites, the unnecessary full
certificate (without root CA) was installed. However, on 30th of May
2020 one of the chain certificates (COMODO) ran out of its validity
period. Obviously monit only checks for the server certificate, that's
why the check did not notice this, and such a check is completely
pointless. It led to a massive damage to my company, and since I was to
deal with monitoring as well as TLS certificates, I had to move on to
find a new job.

During the notice period, I implemented an own check in PHP and let
monit execute this PHP program to check TLS certificates. This PHP
program did not just check the entire chain, but also the chain against
the system's own trust store (in /etc/ssl/certs). I think it would be an
interesting feature to deal with TLS certificates like this in monit in
order to avoid more people losing the jobs.



--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Reply | Threaded
Open this post in threaded view
|

Re: The day I lost my job due to monit

monit-general mailing list
In reply to this post by rexkogitans@gmx.at
You did not lose your job due to Monit, and you know that - you clearly
described what the proximate cause was of your losing your job. It makes
for a 'sensational' headline, but blaming it on Monit is absurd.

On 12/4/2020 7:52 AM, [hidden email] wrote:

> I configured monit to monitor the TLS certificate validity of all of our
> highly productive websites. To all websites, the unnecessary full
> certificate (without root CA) was installed. However, on 30th of May
> 2020 one of the chain certificates (COMODO) ran out of its validity
> period. Obviously monit only checks for the server certificate, that's
> why the check did not notice this, and such a check is completely
> pointless. It led to a massive damage to my company, and since I was to
> deal with monitoring as well as TLS certificates, I had to move on to
> find a new job.
>
> During the notice period, I implemented an own check in PHP and let
> monit execute this PHP program to check TLS certificates. This PHP
> program did not just check the entire chain, but also the chain against
> the system's own trust store (in /etc/ssl/certs). I think it would be an
> interesting feature to deal with TLS certificates like this in monit in
> order to avoid more people losing the jobs.
>
>

--
Paul Theodoropoulos
www.anastrophe.com


Reply | Threaded
Open this post in threaded view
|

Re: The day I lost my job due to monit

Szépe Viktor
In reply to this post by rexkogitans@gmx.at
I am very sorry that you were fired.
I wouldn't go into "why".

If you or someone else runs/monitors SSL certificates it is highly  
advised to follow industry news.
There are blogs, Twitter accounts, newsletters etc.
Especially closely listen to the CA that signs your certificates.
All the best to you!


Idézem/Quoting [hidden email]:

> I configured monit to monitor the TLS certificate validity of all of our
> highly productive websites. To all websites, the unnecessary full
> certificate (without root CA) was installed. However, on 30th of May
> 2020 one of the chain certificates (COMODO) ran out of its validity
> period. Obviously monit only checks for the server certificate, that's
> why the check did not notice this, and such a check is completely
> pointless. It led to a massive damage to my company, and since I was to
> deal with monitoring as well as TLS certificates, I had to move on to
> find a new job.
>
> During the notice period, I implemented an own check in PHP and let
> monit execute this PHP program to check TLS certificates. This PHP
> program did not just check the entire chain, but also the chain against
> the system's own trust store (in /etc/ssl/certs). I think it would be an
> interesting feature to deal with TLS certificates like this in monit in
> order to avoid more people losing the jobs.


SZÉPE Viktor, webes alkalmazás üzemeltetés / Running your application
https://github.com/szepeviktor/debian-server-tools/blob/master/CV.md
~~~
ügyelet 🌶️ hotline: +36-20-4242498  [hidden email]  skype: szepe.viktor
Budapest, III. kerület





smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The day I lost my job due to monit

Werner Flamme
In reply to this post by rexkogitans@gmx.at
Am 04.12.2020 um 16:52 schrieb [hidden email]:
> I configured monit to monitor the TLS certificate validity of all of our
> highly productive websites. To all websites, the unnecessary full
> certificate (without root CA) was installed. However, on 30th of May
> 2020 one of the chain certificates (COMODO) ran out of its validity
> period. Obviously monit only checks for the server certificate, that's
> why the check did not notice this, and such a check is completely
> pointless. It led to a massive damage to my company, and since I was to
> deal with monitoring as well as TLS certificates, I had to move on to
> find a new job.

I do not understand why a server certificate is valid longer than any of
the intermediate certificates. Has the COMODO intermediate certificate
been revoked or did it reach its valid date?

Regards,
Werner


--
Werner Flamme, Abt. WKDV
SAP Certified Technology Associate for NetWeaver/Oracle

Helmholtz-Zentrum für Umweltforschung GmbH - UFZ
Permoserstr. 15 - 04318 Leipzig / Germany
Tel.: +49 341 235-1921 - Fax +49 341 235-451921

Information nach §§ 37a HGB, 35a GmbHG:
Sitz der Gesellschaft: Leipzig
Registergericht: Amtsgericht Leipzig, Handelsregister Nr. B 4703
Vorsitzender des Aufsichtsrats: MinDirig'in Oda Keppler
Wissenschaftlicher Geschäftsführer: Prof. Dr. Georg Teutsch
Administrative Geschäftsführerin: Dr. Sabine König


smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The day I lost my job due to monit

Szépe Viktor
Idézem/Quoting Werner Flamme <[hidden email]>:

> Am 04.12.2020 um 16:52 schrieb [hidden email]:
>> I configured monit to monitor the TLS certificate validity of all of our
>> highly productive websites. To all websites, the unnecessary full
>> certificate (without root CA) was installed. However, on 30th of May
>> 2020 one of the chain certificates (COMODO) ran out of its validity
>> period. Obviously monit only checks for the server certificate, that's
>> why the check did not notice this, and such a check is completely
>> pointless. It led to a massive damage to my company, and since I was to
>> deal with monitoring as well as TLS certificates, I had to move on to
>> find a new job.
>
> I do not understand why a server certificate is valid longer than any of
> the intermediate certificates. Has the COMODO intermediate certificate
> been revoked or did it reach its valid date?
>
Hello Werner!

It was a transition to anther signing root.
PKI is a changing landscape.
Google for COMODO 2020 cross-signing.



SZÉPE Viktor, webes alkalmazás üzemeltetés / Running your application
https://github.com/szepeviktor/debian-server-tools/blob/master/CV.md
~~~
ügyelet 🌶️ hotline: +36-20-4242498  [hidden email]  skype: szepe.viktor
Budapest, III. kerület





smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The day I lost my job due to monit

rexkogitans@gmx.at
In reply to this post by monit-general mailing list
Sure, I admit I sought for a kind of a sensational headline. Monit is a
great tool which surveils the services of this company since many years
and alarmed us for many serious problems.

The more important line is the last sentence: There is room for
improvement. Since I wasn't into C since more than a decade, I am sorry
that I cannot really contribute to Monit, otherwise I would. I remember
that it was roughly 400 lines of PHP code which made a reliable check of
the TLS certificate chain and against the trust store in /etc/ssl/certs.
What I want to give to the developers of Monit is this idea so they may
improve this great tool even more.

Kind regards,

rex kogitans

Am 04.12.20 um 20:03 schrieb Paul Theodoropoulos:

> You did not lose your job due to Monit, and you know that - you
> clearly described what the proximate cause was of your losing your
> job. It makes for a 'sensational' headline, but blaming it on Monit is
> absurd.
>
> On 12/4/2020 7:52 AM, [hidden email] wrote:
>> I configured monit to monitor the TLS certificate validity of all of our
>> highly productive websites. To all websites, the unnecessary full
>> certificate (without root CA) was installed. However, on 30th of May
>> 2020 one of the chain certificates (COMODO) ran out of its validity
>> period. Obviously monit only checks for the server certificate, that's
>> why the check did not notice this, and such a check is completely
>> pointless. It led to a massive damage to my company, and since I was to
>> deal with monitoring as well as TLS certificates, I had to move on to
>> find a new job.
>>
>> During the notice period, I implemented an own check in PHP and let
>> monit execute this PHP program to check TLS certificates. This PHP
>> program did not just check the entire chain, but also the chain against
>> the system's own trust store (in /etc/ssl/certs). I think it would be an
>> interesting feature to deal with TLS certificates like this in monit in
>> order to avoid more people losing the jobs.
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: The day I lost my job due to monit

martinp@tildeslash.com
We can extend the certificate verification to the whole chain.

Best regards,
Martin


> On 8 Dec 2020, at 19:11, [hidden email] wrote:
>
> Sure, I admit I sought for a kind of a sensational headline. Monit is a
> great tool which surveils the services of this company since many years
> and alarmed us for many serious problems.
>
> The more important line is the last sentence: There is room for
> improvement. Since I wasn't into C since more than a decade, I am sorry
> that I cannot really contribute to Monit, otherwise I would. I remember
> that it was roughly 400 lines of PHP code which made a reliable check of
> the TLS certificate chain and against the trust store in /etc/ssl/certs.
> What I want to give to the developers of Monit is this idea so they may
> improve this great tool even more.
>
> Kind regards,
>
> rex kogitans
>
> Am 04.12.20 um 20:03 schrieb Paul Theodoropoulos:
>> You did not lose your job due to Monit, and you know that - you
>> clearly described what the proximate cause was of your losing your
>> job. It makes for a 'sensational' headline, but blaming it on Monit is
>> absurd.
>>
>> On 12/4/2020 7:52 AM, [hidden email] wrote:
>>> I configured monit to monitor the TLS certificate validity of all of our
>>> highly productive websites. To all websites, the unnecessary full
>>> certificate (without root CA) was installed. However, on 30th of May
>>> 2020 one of the chain certificates (COMODO) ran out of its validity
>>> period. Obviously monit only checks for the server certificate, that's
>>> why the check did not notice this, and such a check is completely
>>> pointless. It led to a massive damage to my company, and since I was to
>>> deal with monitoring as well as TLS certificates, I had to move on to
>>> find a new job.
>>>
>>> During the notice period, I implemented an own check in PHP and let
>>> monit execute this PHP program to check TLS certificates. This PHP
>>> program did not just check the entire chain, but also the chain against
>>> the system's own trust store (in /etc/ssl/certs). I think it would be an
>>> interesting feature to deal with TLS certificates like this in monit in
>>> order to avoid more people losing the jobs.
>>>
>>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: The day I lost my job due to monit

Werner Flamme
In reply to this post by Szépe Viktor
Am 2020-12-06 um 12:18 schrieb SZÉPE Viktor:

> Idézem/Quoting Werner Flamme <[hidden email]>:
>
>> Am 04.12.2020 um 16:52 schrieb [hidden email]:
>>> I configured monit to monitor the TLS certificate validity of all of our
>>> highly productive websites. To all websites, the unnecessary full
>>> certificate (without root CA) was installed. However, on 30th of May
>>> 2020 one of the chain certificates (COMODO) ran out of its validity
>>> period. Obviously monit only checks for the server certificate, that's
>>> why the check did not notice this, and such a check is completely
>>> pointless. It led to a massive damage to my company, and since I was to
>>> deal with monitoring as well as TLS certificates, I had to move on to
>>> find a new job.
>>
>> I do not understand why a server certificate is valid longer than any of
>> the intermediate certificates. Has the COMODO intermediate certificate
>> been revoked or did it reach its valid date?
>>
>
> Hello Werner!
>
> It was a transition to anther signing root.
> PKI is a changing landscape.
> Google for COMODO 2020 cross-signing.
Hello Viktor,

so, the intermediate cert was valid when the change happened. How would
one monitor this change in advance?

Ithink, in such cases you have to be awake personally. You should have
gotten information beforehand, issued by COMODO. You should've had time
to renew and change the certificates. I do not see how to get monit to
warn you here.

Werner

--



smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The day I lost my job due to monit

Szépe Viktor

Idézem/Quoting Werner Flamme <[hidden email]>:

> Hello Viktor,
>
> so, the intermediate cert was valid when the change happened. How  
> would one monitor this change in advance?
>
> Ithink, in such cases you have to be awake personally. You should  
> have gotten information beforehand, issued by COMODO. You should've  
> had time to renew and change the certificates. I do not see how to  
> get monit to warn you here.

Skynet is not up yet, so humans must work.
It is highly advised to be in contact with your service providers.



SZÉPE Viktor, webes alkalmazás üzemeltetés / Running your application
https://github.com/szepeviktor/debian-server-tools/blob/master/CV.md
~~~
ügyelet 🌶️ hotline: +36-20-4242498  [hidden email]  skype: szepe.viktor
Budapest, III. kerület





smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The day I lost my job due to monit

PhilTee
In reply to this post by Werner Flamme
This issue was highlighted on a number of IT news pages and blogs in the week or two prior to the issuing CA expiring.  A decent CA should also have made contact with their customers.

We were also bitten by this issue as well, so I now have a shell script which checks all certificates in a chain for impending expiry.  I'm happy to share if that would help anyone.

Phil

On Wed, 9 Dec 2020 at 10:57, Werner Flamme <[hidden email]> wrote:
Am 2020-12-06 um 12:18 schrieb SZÉPE Viktor:
> Idézem/Quoting Werner Flamme <[hidden email]>:
>
>> Am 04.12.2020 um 16:52 schrieb [hidden email]:
>>> I configured monit to monitor the TLS certificate validity of all of our
>>> highly productive websites. To all websites, the unnecessary full
>>> certificate (without root CA) was installed. However, on 30th of May
>>> 2020 one of the chain certificates (COMODO) ran out of its validity
>>> period. Obviously monit only checks for the server certificate, that's
>>> why the check did not notice this, and such a check is completely
>>> pointless. It led to a massive damage to my company, and since I was to
>>> deal with monitoring as well as TLS certificates, I had to move on to
>>> find a new job.
>>
>> I do not understand why a server certificate is valid longer than any of
>> the intermediate certificates. Has the COMODO intermediate certificate
>> been revoked or did it reach its valid date?
>>
>
> Hello Werner!
>
> It was a transition to anther signing root.
> PKI is a changing landscape.
> Google for COMODO 2020 cross-signing.

Hello Viktor,

so, the intermediate cert was valid when the change happened. How would
one monitor this change in advance?

Ithink, in such cases you have to be awake personally. You should have
gotten information beforehand, issued by COMODO. You should've had time
to renew and change the certificates. I do not see how to get monit to
warn you here.

Werner

--


Reply | Threaded
Open this post in threaded view
|

Re: The day I lost my job due to monit

Werner Flamme
Am 10.12.2020 um 12:53 schrieb Phil Townes:
> This issue was highlighted on a number of IT news pages and blogs in the
> week or two prior to the issuing CA expiring.  A decent CA should also have
> made contact with their customers.
>
> We were also bitten by this issue as well, so I now have a shell script
> which checks all certificates in a chain for impending expiry.  I'm happy
> to share if that would help anyone.

Sorry, I still don't get it. How can a certificate in the chain expire
before the "last" certificate (for the server) expires? That means that
a CA signs customer certificates for a longer period than their own
certificate is valid. Can this happen? I never saw this with mine. Their
validity was shortened due to the limited validity of the CA's certificate.

Werner

>
> On Wed, 9 Dec 2020 at 10:57, Werner Flamme <[hidden email]> wrote:
>
>> Am 2020-12-06 um 12:18 schrieb SZÉPE Viktor:
>>> Idézem/Quoting Werner Flamme <[hidden email]>:
>>>
>>>> Am 04.12.2020 um 16:52 schrieb [hidden email]:
>>>>> I configured monit to monitor the TLS certificate validity of all of
>> our
>>>>> highly productive websites. To all websites, the unnecessary full
>>>>> certificate (without root CA) was installed. However, on 30th of May
>>>>> 2020 one of the chain certificates (COMODO) ran out of its validity
>>>>> period. Obviously monit only checks for the server certificate, that's
>>>>> why the check did not notice this, and such a check is completely
>>>>> pointless. It led to a massive damage to my company, and since I was to
>>>>> deal with monitoring as well as TLS certificates, I had to move on to
>>>>> find a new job.
>>>>
>>>> I do not understand why a server certificate is valid longer than any of
>>>> the intermediate certificates. Has the COMODO intermediate certificate
>>>> been revoked or did it reach its valid date?
>>>>
>>>
>>> Hello Werner!
>>>
>>> It was a transition to anther signing root.
>>> PKI is a changing landscape.
>>> Google for COMODO 2020 cross-signing.
>>
>> Hello Viktor,
>>
>> so, the intermediate cert was valid when the change happened. How would
>> one monitor this change in advance?
>>
>> Ithink, in such cases you have to be awake personally. You should have
>> gotten information beforehand, issued by COMODO. You should've had time
>> to renew and change the certificates. I do not see how to get monit to
>> warn you here.
>>
>> Werner
>>
>> --
>>
>>
>>
>
--
Werner Flamme, Abt. WKDV
SAP Certified Technology Associate for NetWeaver/Oracle

Helmholtz-Zentrum für Umweltforschung GmbH - UFZ
Permoserstr. 15 - 04318 Leipzig / Germany
Tel.: +49 341 235-1921 - Fax +49 341 235-451921

Information nach §§ 37a HGB, 35a GmbHG:
Sitz der Gesellschaft: Leipzig
Registergericht: Amtsgericht Leipzig, Handelsregister Nr. B 4703
Vorsitzender des Aufsichtsrats: MinDirig'in Oda Keppler
Wissenschaftlicher Geschäftsführer: Prof. Dr. Georg Teutsch
Administrative Geschäftsführerin: Dr. Sabine König


smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The day I lost my job due to monit

Szépe Viktor
Idézem/Quoting Werner Flamme <[hidden email]>:

> Am 10.12.2020 um 12:53 schrieb Phil Townes:
>> This issue was highlighted on a number of IT news pages and blogs in the
>> week or two prior to the issuing CA expiring.  A decent CA should also have
>> made contact with their customers.
>>
>> We were also bitten by this issue as well, so I now have a shell script
>> which checks all certificates in a chain for impending expiry.  I'm happy
>> to share if that would help anyone.
>
> Sorry, I still don't get it. How can a certificate in the chain expire
> before the "last" certificate (for the server) expires? That means that
> a CA signs customer certificates for a longer period than their own
> certificate is valid. Can this happen? I never saw this with mine. Their
> validity was shortened due to the limited validity of the CA's certificate.
It is called cross-signing :) Google it!

e.g. https://scotthelme.co.uk/content/images/2019/04/image-3.png



SZÉPE Viktor, webes alkalmazás üzemeltetés / Running your application
https://github.com/szepeviktor/debian-server-tools/blob/master/CV.md
~~~
ügyelet 🌶️ hotline: +36-20-4242498  [hidden email]  skype: szepe.viktor
Budapest, III. kerület





smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The day I lost my job due to monit

PhilTee
In reply to this post by Werner Flamme
The certificate was signed by two Root CAs, a process called 'cross-signing'.

One Issuing/Intermediate CA certificate had an expiration date prior to the subject certificate's expiration date, which is what caused these issues.

In a 'normal' situation, if a certificate is only being signed by a single Root CA, the you could expect the subject certificate not to expire after it's Root. This isn't the case for cross-signed certs, or for certs issued by unscrupulous CAs.

The reason for cross-signing is to get the subject certificate to be trusted on as wide a range of devices and browsers as possible.  Many older devices, especially Android devices and embedded devices do not have an up-to-date list of Trusted Root Certificates. By cross-signing a subject certificate with an older Root CA cert that is present in those out-dated Root Cert Stores then a Certificate Authority can offer a wider range of compatibility.

The 'fix' in this case was to swap the expired Issuing CA cert out of the certificate chain on the affected web servers.  This forced modern browsers to read the certificate path that was still valid, rather than falling back to the path with the expired CA certificate.  This, of course, came at the cost of losing Trusted status on older devices - but better to drop those older devices than be down for everyone.

Hope that helps, happy to provide more info if needed!

Best,
Phil

On Fri, 11 Dec 2020, 8:57 am Werner Flamme, <[hidden email]> wrote:
Am 10.12.2020 um 12:53 schrieb Phil Townes:
> This issue was highlighted on a number of IT news pages and blogs in the
> week or two prior to the issuing CA expiring.  A decent CA should also have
> made contact with their customers.
>
> We were also bitten by this issue as well, so I now have a shell script
> which checks all certificates in a chain for impending expiry.  I'm happy
> to share if that would help anyone.

Sorry, I still don't get it. How can a certificate in the chain expire
before the "last" certificate (for the server) expires? That means that
a CA signs customer certificates for a longer period than their own
certificate is valid. Can this happen? I never saw this with mine. Their
validity was shortened due to the limited validity of the CA's certificate.

Werner

>
> On Wed, 9 Dec 2020 at 10:57, Werner Flamme <[hidden email]> wrote:
>
>> Am 2020-12-06 um 12:18 schrieb SZÉPE Viktor:
>>> Idézem/Quoting Werner Flamme <[hidden email]>:
>>>
>>>> Am 04.12.2020 um 16:52 schrieb [hidden email]:
>>>>> I configured monit to monitor the TLS certificate validity of all of
>> our
>>>>> highly productive websites. To all websites, the unnecessary full
>>>>> certificate (without root CA) was installed. However, on 30th of May
>>>>> 2020 one of the chain certificates (COMODO) ran out of its validity
>>>>> period. Obviously monit only checks for the server certificate, that's
>>>>> why the check did not notice this, and such a check is completely
>>>>> pointless. It led to a massive damage to my company, and since I was to
>>>>> deal with monitoring as well as TLS certificates, I had to move on to
>>>>> find a new job.
>>>>
>>>> I do not understand why a server certificate is valid longer than any of
>>>> the intermediate certificates. Has the COMODO intermediate certificate
>>>> been revoked or did it reach its valid date?
>>>>
>>>
>>> Hello Werner!
>>>
>>> It was a transition to anther signing root.
>>> PKI is a changing landscape.
>>> Google for COMODO 2020 cross-signing.
>>
>> Hello Viktor,
>>
>> so, the intermediate cert was valid when the change happened. How would
>> one monitor this change in advance?
>>
>> Ithink, in such cases you have to be awake personally. You should have
>> gotten information beforehand, issued by COMODO. You should've had time
>> to renew and change the certificates. I do not see how to get monit to
>> warn you here.
>>
>> Werner
>>
>> --
>>
>>
>>
>

--
Werner Flamme, Abt. WKDV
SAP Certified Technology Associate for NetWeaver/Oracle

Helmholtz-Zentrum für Umweltforschung GmbH - UFZ
Permoserstr. 15 - 04318 Leipzig / Germany
Tel.: +49 341 235-1921 - Fax +49 341 235-451921

Information nach §§ 37a HGB, 35a GmbHG:
Sitz der Gesellschaft: Leipzig
Registergericht: Amtsgericht Leipzig, Handelsregister Nr. B 4703
Vorsitzender des Aufsichtsrats: MinDirig'in Oda Keppler
Wissenschaftlicher Geschäftsführer: Prof. Dr. Georg Teutsch
Administrative Geschäftsführerin: Dr. Sabine König