Why did we get many erros like
Plugin: ODDB::SwissmedicPlugin Error: OpenSSL::SSL::SSLError Message: SSL_connect returned=1 errno=0 state=error: certificate verify failed
When visisting https://www.swissmedic.ch I see that the certificate got renewed on 28.08.2017 via QuoVadisRootCA2G3 via the "Swiss Government PKI". Does OpenSSL have a problem with it?
According to https://certificatedetails.com/e59d5930824758ccacfa085436867b3ab5044df0/727b609/swissgovernmentsslca01 it was emitted in 2014 by This digital certificate with serial number 07:27:b6:09 was issued on Wednesday Sep 10, 2014 at 6:50PM by Baltimore.
What does openssh return?
openssl s_client -connect www.swissmedic.ch:443
CONNECTED(00000003)
depth=3 C = BM, O = QuoVadis Limited, CN = QuoVadis Root CA 2 G3
verify return:1
depth=2 C = BM, O = QuoVadis Limited, CN = QuoVadis Enterprise Trust CA 2 G3
verify return:1
depth=1 C = CH, O = Swiss Government PKI, OU = Services, OU = Certification Authorities, CN = Swiss Government Public Trust Standard CA 02
verify return:1
depth=0 C = CH, ST = BE, L = Bern, O = Bundesamt fuer Informatik und Telekommunikation, OU = Swiss Government PKI, CN = www.swissmedic.ch
verify return:1
---
Certificate chain
0 s:/C=CH/ST=BE/L=Bern/O=Bundesamt fuer Informatik und Telekommunikation/OU=Swiss Government PKI/CN=www.swissmedic.ch
i:/C=CH/O=Swiss Government PKI/OU=Services/OU=Certification Authorities/CN=Swiss Government Public Trust Standard CA 02
1 s:/C=CH/O=Swiss Government PKI/OU=Services/OU=Certification Authorities/CN=Swiss Government Public Trust Standard CA 02
i:/C=BM/O=QuoVadis Limited/CN=QuoVadis Enterprise Trust CA 2 G3
2 s:/C=BM/O=QuoVadis Limited/CN=QuoVadis Enterprise Trust CA 2 G3
i:/C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 2 G3
3 s:/C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 2 G3
i:/C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 2 G3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIH0zCCBbugAwIBAgIQH1COu4BDa2CplVNWCy+mjDANBgkqhkiG9w0BAQsFADCB
mjELMAkGA1UEBhMCQ0gxHTAbBgNVBAoMFFN3aXNzIEdvdmVybm1lbnQgUEtJMREw
DwYDVQQLDAhTZXJ2aWNlczEiMCAGA1UECwwZQ2VydGlmaWNhdGlvbiBBdXRob3Jp
dGllczE1MDMGA1UEAwwsU3dpc3MgR292ZXJubWVudCBQdWJsaWMgVHJ1c3QgU3Rh
bmRhcmQgQ0EgMDIwHhcNMTcwODI4MTMyMjAwWhcNMTkwODI4MTMyMjAwWjCBnjEL
MAkGA1UEBhMCQ0gxCzAJBgNVBAgMAkJFMQ0wCwYDVQQHDARCZXJuMTgwNgYDVQQK
DC9CdW5kZXNhbXQgZnVlciBJbmZvcm1hdGlrIHVuZCBUZWxla29tbXVuaWthdGlv
bjEdMBsGA1UECwwUU3dpc3MgR292ZXJubWVudCBQS0kxGjAYBgNVBAMMEXd3dy5z
d2lzc21lZGljLmNoMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyg1p
kXoPVUWIRSkEtg+UBL9CspsM6t0kXnJil3MAawgbqzetdxS3jG5vczEZK12teqAl
54RUWuVR1QcBuhEnAzfkk3/Z7fQxvqd3eeaKRQeG4eiOzexn0rrdNCcFcqFEtNzZ
ghD05DkoHC7l3M9uGgBtSJQYdgTu3FXj64lId4/dQXcTeIdlGhNRWTckjKr1xf3p
TeghY4xasoDz8Vk+MJPp4oQI5CtQT8PUcp9zkrUt19L4qne90L7C9PNkMbhaQCOu
U+V1YM7ANRUSfvpJWxepuwY6c33/s+KbUIyQ95gpekek3qsefL41ED8DLy57gA3P
YZ3derz3UB3BK/gjEwIDAQABo4IDDTCCAwkwHAYDVR0RBBUwE4IRd3d3LnN3aXNz
bWVkaWMuY2gwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggr
BgEFBQcDAjCCARgGA1UdIASCAQ8wggELMIIBBwYIYIV0AREDPg4wgfowRAYIKwYB
BQUHAgEWOGh0dHA6Ly93d3cucGtpLmFkbWluLmNoL2Nwcy9DUFNfMl8xNl83NTZf
MV8xN18zXzYxXzAucGRmMIGxBggrBgEFBQcCAjCBpBqBoVJlbGlhbmNlIG9uIHRo
ZSBTRyBSb290IENBIElJSSBDZXJ0aWZpY2F0ZSBieSBhbnkgcGFydHkgYXNzdW1l
cyBhY2NlcHRhbmNlIG9mIHRoZSB0aGVuIGFwcGxpY2FibGUgc3RhbmRhcmQgdGVy
bXMgYW5kIGNvbmRpdGlvbnMgb2YgdXNlIGFuZCB0aGUgU0cgUm9vdCBDQSBJSUkg
Q1BTMHYGCCsGAQUFBwEBBGowaDA2BggrBgEFBQcwAoYqaHR0cDovL3d3dy5wa2ku
YWRtaW4uY2gvYWlhL1BUU1RDQTAyQkMuY3J0MC4GCCsGAQUFBzABhiJodHRwOi8v
d3d3LnBraS5hZG1pbi5jaC9haWEvYmNvY3NwMIHXBgNVHR8Egc8wgcwwLqAsoCqG
KGh0dHA6Ly93d3cucGtpLmFkbWluLmNoL2NybC9QVFNUQ0EwMi5jcmwwgZmggZag
gZOGgZBsZGFwOi8vYWRtaW5kaXIuYWRtaW4uY2g6Mzg5L2NuPVN3aXNzJTIwR292
ZXJubWVudCUyMFB1YmxpYyUyMFRydXN0JTIwU3RhbmRhcmQlMjBDQSUyMDAyLG91
PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvdT1TZXJ2aWNlcyxvPUFkbWlu
LGM9Q0gwHwYDVR0jBBgwFoAUhFhOhy2lsE5Jhbu8AXHmtMdV/xAwHQYDVR0OBBYE
FDD2cHSKYpZ4WT31m7HC/A6zPilZMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEL
BQADggIBAGmXsrNQ9O3jxtmn8cXL4DyfefsFrxlLNPjQtdX+fuNydEPoBi2avU08
xFb+jS3Gh0H9AXeeh22MSFMk9De6GVNhnAZh/gYO1TDiZ97gUHjo+S87lx76MfOi
o/sfnHtSabO2quIz9A0byAuGM+DaJNeE/xcZJsiAPtzAxSI8EFc2LjRFrwH298Us
ZNHxtnmTejWV5tdkm2inTFQNdLs5omAXWV61e+0MlfgDAytcMmwdRLHta+9YIiXF
t9Nve7weXMAPAL2PnpA4k5QGxruSaGB00utWp4WoL98XavTs2utcY897WNaIWJm9
1EsvwQ+rY3mSL3pgVcprqsMLPe8DbNMyoGU4NspqHoIyA7rPffO+1UxQa8lVSzoD
CeYGwHhYzc3iZtTH/lC60CiiQtO8QNw+kkKS6ddn07UfdOdTlFdNdiwmyOzhQ7q6
59s/vewyDJ8r9mykM6qcfSTjB0aR/tJQJTWSiMLhd/zmVRhgeMew2kpxMfVrGA2/
7NcY6OWhV/UPr9Osh/g08kJkfpSnt8HJu76g58y0Kf+65iC5CDVZ1HHCSu1IBDTc
92ETPB3XeM59DjVUpFUyBOBCYY/xhKw0HhkXFEDtDywDjkwfziramixgk9RM0XVp
xms7p+fEGkXi7KWnanvJ9uYWVCHdfpw8YlQacoaNsYsfoXrU3QZ2
-----END CERTIFICATE-----
subject=/C=CH/ST=BE/L=Bern/O=Bundesamt fuer Informatik und Telekommunikation/OU=Swiss Government PKI/CN=www.swissmedic.ch
issuer=/C=CH/O=Swiss Government PKI/OU=Services/OU=Certification Authorities/CN=Swiss Government Public Trust Standard CA 02
---
No client certificate CA names sent
Peer signing digest: SHA256
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 10776 bytes and written 434 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: B268B48206AC28679B309CB36EF5D0EF34DBB3FC81F7D41852C281C23E8520FF
Session-ID-ctx:
Master-Key: E25B19C6D2729F1BD05D9A78B9B3298C9E862D20FC2918745FE97FAAF75830B93BDC0DC8E09320E7BF77306F5F0E4FB3
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1504507179
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
Looks like we do not have a certificate for its root installed
[@
sudo find /etc/ssl/ -name "*Authority.pem"
/etc/ssl/certs/Verisign_Class_1_Public_Primary_Certification_Authority.pem
/etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority.pem
/etc/ssl/certs/COMODO_Certification_Authority.pem
/etc/ssl/certs/USERTrust_ECC_Certification_Authority.pem
/etc/ssl/certs/ePKI_Root_Certification_Authority.pem
/etc/ssl/certs/VeriSign_Universal_Root_Certification_Authority.pem
/etc/ssl/certs/WellsSecure_Public_Root_Certificate_Authority.pem
/etc/ssl/certs/COMODO_ECC_Certification_Authority.pem
/etc/ssl/certs/StartCom_Certification_Authority.pem
/etc/ssl/certs/Entrust_Root_Certification_Authority.pem
/etc/ssl/certs/COMODO_RSA_Certification_Authority.pem
/etc/ssl/certs/USERTrust_RSA_Certification_Authority.pem
/etc/ssl/certs/GeoTrust_Primary_Certification_Authority.pem
/etc/ssl/certs/Network_Solutions_Certificate_Authority.pem
/etc/ssl/certs/E-Tugra_Certification_Authority.pem
/etc/ssl/certs/TWCA_Root_Certification_Authority.pem
When running sudo -u apache bundle-240 exec ruby-240 jobs/import_swissmedic_only on oddb-ci2 I do not get this error.
On oddb-ci2 I have the certificates for QuoVadis
ls -lrt /etc/ssl/certs/ | grep -i QuoVadis lrwxrwxrwx 1 root root 55 Oct 4 2016 QuoVadis_Root_CA.pem -> /usr/share/ca-certificates/mozilla/QuoVadis_Root_CA.crt lrwxrwxrwx 1 root root 57 Oct 4 2016 QuoVadis_Root_CA_2.pem -> /usr/share/ca-certificates/mozilla/QuoVadis_Root_CA_2.crt lrwxrwxrwx 1 root root 57 Oct 4 2016 QuoVadis_Root_CA_3.pem -> /usr/share/ca-certificates/mozilla/QuoVadis_Root_CA_3.crt lrwxrwxrwx 1 root root 68 Sep 4 08:57 QuoVadis_Root_CA_1_G3.pem -> ../../../usr/share/ca-certificates/mozilla/QuoVadis_Root_CA_1_G3.crt lrwxrwxrwx 1 root root 68 Sep 4 08:57 QuoVadis_Root_CA_3_G3.pem -> ../../../usr/share/ca-certificates/mozilla/QuoVadis_Root_CA_3_G3.crt lrwxrwxrwx 1 root root 68 Sep 4 08:57 QuoVadis_Root_CA_2_G3.pem -> ../../../usr/share/ca-certificates/mozilla/QuoVadis_Root_CA_2_G3.crt lrwxrwxrwx 1 root root 20 Sep 4 09:05 080911ac.0 -> QuoVadis_Root_CA.pem lrwxrwxrwx 1 root root 25 Sep 4 09:05 064e0aa9.0 -> QuoVadis_Root_CA_2_G3.pem lrwxrwxrwx 1 root root 22 Sep 4 09:05 76faf6c0.0 -> QuoVadis_Root_CA_3.pem lrwxrwxrwx 1 root root 25 Sep 4 09:05 e18bfb83.0 -> QuoVadis_Root_CA_3_G3.pem lrwxrwxrwx 1 root root 25 Sep 4 09:05 749e9e03.0 -> QuoVadis_Root_CA_1_G3.pem lrwxrwxrwx 1 root root 22 Sep 4 09:05 d7e8dc79.0 -> QuoVadis_Root_CA_2.pem
whereas on thinpower they are no longer valide
ls -lrt /etc/ssl/certs/ | grep -i QuoVadi lrwxrwxrwx 1 root root 55 6. Feb 2014 QuoVadis_Root_CA.pem -> /usr/share/ca-certificates/mozilla/QuoVadis_Root_CA.crt lrwxrwxrwx 1 root root 57 6. Feb 2014 QuoVadis_Root_CA_2.pem -> /usr/share/ca-certificates/mozilla/QuoVadis_Root_CA_2.crt lrwxrwxrwx 1 root root 57 6. Feb 2014 QuoVadis_Root_CA_3.pem -> /usr/share/ca-certificates/mozilla/QuoVadis_Root_CA_3.crt
Tasks:
We must list each domain name, as letsencrypt does not yet support wildcards
Pushed the commits
Running the certbot-auto failed initially as it did not accept the sl_errors.oddb.org domain name. As I tried them with less domains, it generated under /etc/letsencrypt/live/ also the directories ch.oddb.org-0001 and ch.oddb.org-0002. I hope that this will not lead to problems.
Activating my new apache.conf lead to problems. Reloading the apache gave around 15 warnings [Mon Sep 04 11:08:43 2017] [warn] VirtualHost 62.12.131.38:443 overlaps with VirtualHost 62.12.131.38:443, the first has precedence, perhaps you need a NameVirtualHost directive [ ok ]
https://httpd.apache.org/docs/2.4/en/vhosts/name-based.html states
IP-based virtual hosts use the IP address of the connection to determine the correct virtual host to serve. Therefore you need to have a separate IP address for each host. With name-based virtual hosting, the server relies on the client to report the hostname as part of the HTTP headers. Using this technique, many different hosts can share the same IP address.
https://wiki.apache.org/httpd/NameBasedSSLVHosts says, that this is possible if all hosts use the same certificate.
In the thinpower apache log I find /var/log/apache2/error_log:[Mon Sep 04 11:08:44 2017] [warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
Pushed commit Used https for show_ads.js
Pushed two commits to fix unit tests Fixed test sfor show_add_sense and Fix test for plugin/medical_products.rb
Example is: http://ch.oddb.org/de/gcc/search/zone/drugs/search_query/66085/search_type/st_registration?
Looking for relevant lines in /var/www/oddb.org/log/oddb/debug/2017/09.log on thinpower gets
2017-09-01 07:41:57 +0200: /var/www/oddb.org/:1223:in `parse_textinfo': skip pi as 66085 Kisplyx® not found in Packungen.xlsx 2017-09-01 07:41:57 +0200: /var/www/oddb.org/src/plugin/text_info.rb:1223:in `parse_textinfo': skip pi as 66085 Kisplyx® not found in Packungen.xlsx
Why ist it skipped? This was decision taken and dokumented under http://dev.ywesee.com/Niklaus/20160406-importonly-active-PI#importonly-active-P. From the log we can see that we skipped today 221 entries. Attach:skipped_pi.txt
If I just continue in this case, the plugin tries to add a patinfo, but this does not work correctly and neither the FI nor the PI can be displayed. Trying to fix this problem.
Visiting the FI after the import leads to the following error
NoMethodError: undefined method `empty?' for nil:NilClass
/var/www/oddb.org/src/view/drugs/fachinfo.rb:221:in `display_names'
/var/www/oddb.org/src/view/drugs/fachinfo.rb:106:in `init'
/var/www/oddb.org/vendor/ruby/2.4.0/gems/htmlgrid-1.1.4/lib/htmlgrid/component.rb:139:in `initialize'
/var/www/oddb.org/src/view/drugs/fachinfo.rb:398:in `new'
/var/www/oddb.org/src/view/drugs/fachinfo.rb:398:in `chapter_chooser'
/var/www/oddb.org/vendor/ruby/2.4.0/gems/htmlgrid-1.1.4/lib/htmlgrid/composite.rb:83:in `create'
/var/www/oddb.org/vendor/ruby/2.4.0/gems/htmlgrid-1.1.4/lib/htmlgrid/composite.rb:284:in `compose_component'
/var/www/oddb.org/vendor/ruby/2.4.0/gems/htmlgrid-1.1.4/lib/htmlgrid/composite.rb:213:in `block in compose'
/var/www/oddb.org/vendor/ruby/2.4.0/gems/htmlgrid-1.1.4/lib/htmlgrid/composite.rb:209:in `each'
/var/www/oddb.org/vendor/ruby/2.4.0/gems/htmlgrid-1.1.4/lib/htmlgrid/composite.rb:209:in `compose'
/var/www/oddb.org/vendor/ruby/2.4.0/gems/htmlgrid-1.1.4/lib/htmlgrid/composite.rb:72:in `init'
/var/www/oddb.org/src/view/drugs/fachinfo.rb:394:in `init'
/var/www/oddb.org/src/view/drugs/fachinfo.rb:480:in `init'
/var/www/oddb.org/vendor/ruby/2.4.0/gems/htmlgrid-1.1.4/lib/htmlgrid/component.rb:139:in `initialize'
/var/www/oddb.org/src/view/publictemplate.rb:71:in `new'
/var/www/oddb.org/src/view/publictemplate.rb:71:in `content'
/var/www/oddb.org/vendor/ruby/2.4.0/gems/htmlgrid-1.1.4/lib/htmlgrid/composite.rb:83:in `create'
/var/www/oddb.org/vendor/ruby/2.4.0/gems/htmlgrid-1.1.4/lib/htmlgrid/composite.rb:284:in `compose_component'
/var/www/oddb.org/vendor/ruby/2.4.0/gems/htmlgrid-1.1.4/lib/htmlgrid/composite.rb:213:in `block in compose'
/var/www/oddb.org/vendor/ruby/2.4.0/gems/htmlgrid-1.1.4/lib/htmlgrid/composite.rb:209:in `each'
/var/www/oddb.org/vendor/ruby/2.4.0/gems/htmlgrid-1.1.4/lib/htmlgrid/composite.rb:209:in `compose'
/var/www/oddb.org/vendor/ruby/2.4.0/gems/htmlgrid-1.1.4/lib/htmlgrid/composite.rb:72:in `init'
/var/www/oddb.org/src/view/publictemplate.rb:68:in `init'
/var/www/oddb.org/src/view/privatetemplate.rb:17:in `init'
/var/www/oddb.org/vendor/ruby/2.4.0/gems/htmlgrid-1.1.4/lib/htmlgrid/component.rb:139:in `initialize'
/var/www/oddb.org/vendor/ruby/2.4.0/gems/sbsm-1.5.9/lib/sbsm/state.rb:241:in `new'
/var/www/oddb.org/vendor/ruby/2.4.0/gems/sbsm-1.5.9/lib/sbsm/state.rb:241:in `view'
/var/www/oddb.org/vendor/ruby/2.4.0/gems/sbsm-1.5.9/lib/sbsm/state.rb:174:in `to_html'
/var/www/oddb.org/vendor/ruby/2.4.0/gems/sbsm-1.5.9/lib/sbsm/session.rb:547:in `to_html'
/var/www/oddb.org/vendor/ruby/2.4.0/gems/sbsm-1.5.9/lib/sbsm/session.rb:279:in `block in process_rack'
/var/www/oddb.org/vendor/ruby/2.4.0/gems/sbsm-1.5.9/lib/sbsm/session.rb:209:in `synchronize'
/var/www/oddb.org/vendor/ruby/2.4.0/gems/sbsm-1.5.9/lib/sbsm/session.rb:209:in `process_rack'
/var/www/oddb.org/vendor/ruby/2.4.0/gems/sbsm-1.5.9/lib/sbsm/app.rb:127:in `call'
<..>
192.168.0.1, 192.168.0.80 - - [04/Sep/2017 14:35:22] "GET https://oddb-ci2.dyndns.org/de/gcc/new_fachinfo/reg/66085/chapter/composition HTTP/1.1" 500 148225 0.0233 "Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
Fixed this problem. Updating new patinfo still does not work. I must probably replace patinfo.descriptions[lang] = patinfo_lang by eval("patinfo.descriptions['#{lang}']= patinfo_lang") as I did when saving the change_log.
When I try to access the newly generate patinfo via bin/admin I get the following error
ch.oddb> registration('66085')
-> #<ODDB::Registration:0x007fb5fcdf7500>
ch.oddb> registration('66085').packages.size
-> 1
ch.oddb> registration('66085').packages.first
-> #<ODDB::Package:0x00557be8e99558>
ch.oddb> registration('66085').packages.first.patinfo.de
-> connection closed
ch.oddb> registration('66085').packages.first.patinfo
-> connection closed
New trying to save a new patinfo for all packages (in a sequence using) (line 315 ff on src/plugin/text_info.rb
patinfo = @app.create_patinfo;
patinfo.descriptions; # create descriptions by default
eval("patinfo.descriptions['#{lang}']= patinfo_lang");
# we do not have to call store_patinfo_change_diff, as it is the first time
sequence = reg.sequences.values.first;
@app.update sequence.pointer, patinfo.descriptions;
sequence.patinfo.odba_store;
sequence.odba_store;
reg.odba_store;