try to allow certificate-chains

Currently the verification of certificates uses only the first pem in
the ca-file and the first pem in the certificate-file. This breaks if an
intermediate certificate is needed.

A simple workaround is to put the full chain into the ca-file and give
the ca-file instead of the X509-structure to the VerifyCertificate()
methode. There we can just do the usual business but add the full
ca-file again to OpenSSLs SSL_CTX_load_verify_locations().

While this seems a little bit hackish it should at least allow the
proper verification of a certificate chain without introducing any
security implications for setups with just a single root-ca.
The only downside currently: while the CLI "pki verify" will correctly
check the supplied parameters, it still only shows the topmost
certificate from the ca-file (which I guess is fine for the moment).

lib/base/tlsutility.cpp

@@ -878,8 +878,10 @@ String RandomString(int length)
 	return result;
 }
 
-bool VerifyCertificate(const std::shared_ptr<X509> &caCertificate, const std::shared_ptr<X509> &certificate, const String& crlFile)
+bool VerifyCertificate(const String& caFile, const std::shared_ptr<X509> &certificate, const String& crlFile)
 {
+	std::shared_ptr<X509> caCertificate = GetX509Certificate(caFile);
+
 	X509_STORE *store = X509_STORE_new();
 
 	if (!store)
@@ -891,6 +893,8 @@ bool VerifyCertificate(const std::shared_ptr<X509> &caCertificate, const std::sh
 		AddCRLToSSLContext(store, crlFile);
 	}
 
+	X509_STORE_load_locations(store, caFile.CStr(), NULL); /* ignore any errors for the moment, since this is just the convenient way to add full chain */
+
 	X509_STORE_CTX *csc = X509_STORE_CTX_new();
 	X509_STORE_CTX_init(csc, store, certificate.get(), nullptr);
 

lib/base/tlsutility.hpp

@@ -53,7 +53,7 @@ String SHA1(const String& s, bool binary = false);
 String SHA256(const String& s);
 String RandomString(int length);
 
-bool VerifyCertificate(const std::shared_ptr<X509>& caCertificate, const std::shared_ptr<X509>& certificate, const String& crlFile);
+bool VerifyCertificate(const String& caFile, const std::shared_ptr<X509>& certificate, const String& crlFile);
 bool IsCa(const std::shared_ptr<X509>& cacert);
 int GetCertificateVersion(const std::shared_ptr<X509>& cert);
 String GetSignatureAlgorithm(const std::shared_ptr<X509>& cert);

lib/cli/pkiverifycommand.cpp

@@ -130,7 +130,7 @@ int PKIVerifyCommand::Run(const boost::program_options::variables_map& vm, const
 		bool signedByCA;
 
 		try {
-			signedByCA = VerifyCertificate(cacert, cert, crlFile);
+			signedByCA = VerifyCertificate(caCertFile, cert, crlFile);
 		} catch (const std::exception& ex) {
 			Log logmsg (LogCritical, "cli");
 			logmsg << "CRITICAL: Certificate with CN '" << certCN << "' is NOT signed by CA: ";

lib/remote/jsonrpcconnection-pki.cpp

@@ -60,7 +60,7 @@ Value RequestCertificateHandler(const MessageOrigin::Ptr& origin, const Dictiona
 		logmsg << "Received certificate request for CN '" << cn << "'";
 
 		try {
-			signedByCA = VerifyCertificate(cacert, cert, listener->GetCrlPath());
+			signedByCA = VerifyCertificate(listener->GetDefaultCaPath(), cert, listener->GetCrlPath());
 			if (!signedByCA) {
 				logmsg << " not";
 			}
@@ -216,7 +216,7 @@ Value RequestCertificateHandler(const MessageOrigin::Ptr& origin, const Dictiona
 	 * we're using for cluster connections (there's no point in sending a client
 	 * a certificate it wouldn't be able to use to connect to us anyway) */
 	try {
-		if (!VerifyCertificate(cacert, newcert, listener->GetCrlPath())) {
+		if (!VerifyCertificate(listener->GetDefaultCaPath(), newcert, listener->GetCrlPath())) {
 			Log(LogWarning, "JsonRpcConnection")
 				<< "The CA in '" << listener->GetDefaultCaPath() << "' does not match the CA which Icinga uses "
 				<< "for its own cluster connections. This is most likely a configuration problem.";