I'm setting the PVC on Kubernetes use vSphere cloud provider with self signed certificate, I tried put the flag insecure-flag = "1" on my vsphere.conf, but I get this error:
F0320 14:55:19.410777 1 controllermanager.go:213] error building controller context: cloud provider could not be initialized: could not init cloud provider "vsphere": warning:can't store data at section "VirtualCenter", subsection "vsphere-node01", variable "insecure-flag"
Environment:
Linux version: Red Hat 7.7 (Maipo)
Kubernetes version: v1.17.2
Vsphere version: 6.5.0
Can anyone help me with this problem?
This issue was solved with the link information:
https://vmware.github.io/vic-product/assets/files/html/1.3/vic_vsphere_admin/obtain_thumbprint.html
vCenter Server Appliance or ESXi Host
You can use SSH and OpenSSL to obtain the certificate thumbprint for a vCenter Server Appiance instance or an ESXi host.
Use SSH to connect to the vCenter Server Appliance or ESXi host as root user.
$ ssh root#vcsa_or_esxi_host_address
Use openssl to view the certificate fingerprint.
vCenter Server Appliance:
openssl x509 -in /etc/vmware-vpx/ssl/rui.crt -fingerprint -sha1 -noout
Result: SHA1 Fingerprint=G5:2T:G4:4E:FE:32:D1:24:4F:25:39:GR:63:19:2B:5D:29:D1:R1:2C
ESXi host:
openssl x509 -in /etc/vmware/ssl/rui.crt -fingerprint -sha1 -noout
Result: SHA1 Fingerprint=G5:2T:G4:4E:FE:32:D1:24:4F:25:39:GR:63:19:2B:5D:29:D1:R1:2C
Copy the certificate thumbprint for use in the --thumbprint option of vic-machine commands or to set it as an environment variable.
On the vsphere.conf file put this information on "thumbprint"
[Global]
[VirtualCenter "host.net"]
user = "administrator#vsphere.local"
password = "XYZ#!xyz"
port = "443"
thumbprint = "G5:2T:G4:4E:FE:32:D1:24:4F:25:39:GR:63:19:2B:5D:29:D1:R1:2C"
datacenters = "dc-vcenter"
[Workspace]
server = "host.net"
datacenter = "dc-vcenter"
default-datastore = "ds-vcenter"
resourcepool-path = "rs-vcenter/rp-app"
folder = "kubevol"
[Disk]
scsicontrollertype = pvscsi
This setting will allow the kubernetes API connect to vSphere and make authentication with a self signed certificate.
Related
I am trying to use minio as a local S3 server. I am following this article
I downloaded key and cert files.
I added the env parameters:
set MINIO_KMS_KES_ENDPOINT=https://play.min.io:7373
set MINIO_KMS_KES_KEY_FILE=D:\KMS\root.key
set MINIO_KMS_KES_CERT_FILE=D:\KMS\root.cert
set MINIO_KMS_KES_KEY_NAME=my-minio-key
I started minio server: D:\>minio.exe server D:\Photos
It logs after sturt up:
Endpoint: http://169.254.182.253:9000 http://169.254.47.198:9000 http://172.17.39.193:9000 http://192.168.0.191:9000 http://169.254.103.105:9000 http://169.254.209.102:9000 http://169.254.136.71:9000 http://127.0.0.1:9000
AccessKey: minioadmin
SecretKey: minioadmin
Browser Access:
http://169.254.182.253:9000 http://169.254.47.198:9000 http://172.17.39.193:9000 http://192.168.0.191:9000 http://169.254.103.105:9000 http://169.254.209.102:9000 http://169.254.136.71:9000 http://127.0.0.1:9000
Command-line Access: https://docs.min.io/docs/minio-client-quickstart-guide
$ mc.exe alias set myminio http://169.254.182.253:9000 minioadmin minioadmin
Object API (Amazon S3 compatible):
Go: https://docs.min.io/docs/golang-client-quickstart-guide
Java: https://docs.min.io/docs/java-client-quickstart-guide
Python: https://docs.min.io/docs/python-client-quickstart-guide
JavaScript: https://docs.min.io/docs/javascript-client-quickstart-guide
.NET: https://docs.min.io/docs/dotnet-client-quickstart-guide
Detected default credentials 'minioadmin:minioadmin', please change the credentials immediately using 'MINIO_ACCESS_KEY' and 'MINIO_SECRET_KEY'
I opened UI in browser: http://localhost:9000/minio/mybacket/
I tried to upload a jpg file and got an exception:
<?xml version="1.0" encoding="UTF-8"?> <Error><Code>InternalError</Code><Message>We encountered an internal error, please try again.</Message><Key>Completed.jpg</Key><BucketName>mybacket</BucketName><Resource>/minio/upload/mybacket/Completed.jpg</Resource><RequestId>1634A6E5663C9D70</RequestId><HostId>4a46a947-6473-4d53-bbb3-a4f908d444ce</HostId></Error>
And I got this exception in minio console:
Error: Post "https://play.min.io:7373/v1/key/generate/my-minio-key": x509: certificate signed by unknown authority
3: cmd\api-errors.go:1961:cmd.toAPIErrorCode()
2: cmd\api-errors.go:1986:cmd.toAPIError()
1: cmd\web-handlers.go:1116:cmd.(*webAPIHandlers).Upload()
Most probably your OS trust store (containing the Root CA certificates) does not trust Let's Encrypt (the Let's Encrypt Authority X3 CA certificate).
The server https://play.min.io:7373 serves a TLS certificates issued by Let's Encrypt.
See:
openssl s_client -showcerts -servername play.min.io -connect play.min.io:7373
Eventually, check your the root CA store of your windows machine.
See: https://security.stackexchange.com/questions/48437/how-can-you-check-the-installed-certificate-authority-in-windows-7-8
While performing certificate verification the certutil.exe connects to different external resources.
The util freezes for 5-10 seconds on the step CERT_CHAIN_POLICY_BASE, on endentity and even Root certificates.
How it can be disabled and why does it happen?
I copied certutil.exe from another server where no such issue, compared hashes, launched but the same.
Command: certutil.exe -verify GlobalSign_root.cer
OS: Microsoft Windows Server 2016 Standard 10.0.14393 N/A Build 14393
External resources it connects:
a95-101-142-11.deploy.static.akamaitechnologies.com:http
map2.hwcdn.net:http
80-239-217-59.customer.teliacarrier.com:http
Others
Procmon64.exe.exe shows who connects: certutil.exe
Command output:
C:\Temp\certs>certutil -verify GlobalSign.cer
Issuer:
CN=GlobalSign
O=GlobalSign
OU=GlobalSign Root CA - R3
Name Hash(sha1): f59c687f2418d62a790f7592330756ea85e94707
Name Hash(md5): 01728e1ecf7a9d86fb3cec8948aba953
Subject:
CN=GlobalSign
O=GlobalSign
OU=GlobalSign Root CA - R3
Name Hash(sha1): f59c687f2418d62a790f7592330756ea85e94707
Name Hash(md5): 01728e1ecf7a9d86fb3cec8948aba953
Cert Serial Number: 04000000000121585308a2
dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
CertContext[0][0]: dwInfoStatus=10c dwErrorStatus=0
Issuer: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3
NotBefore: 3/18/2009 3:00 AM
NotAfter: 3/18/2029 3:00 AM
Subject: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R3
Serial: 04000000000121585308a2
Cert: d69b561148f01c77c54578c10926df5b856976ad
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication
Application[1] = 1.3.6.1.5.5.7.3.2 Client Authentication
Application[2] = 1.3.6.1.5.5.7.3.3 Code Signing
Application[3] = 1.3.6.1.5.5.7.3.4 Secure Email
Application[4] = 1.3.6.1.5.5.7.3.8 Time Stamping
Application[5] = 1.3.6.1.4.1.311.10.3.4 Encrypting File System
Application[6] = 1.3.6.1.5.5.7.3.6 IP security tunnel termination
Application[7] = 1.3.6.1.5.5.7.3.7 IP security user
Exclude leaf cert:
Chain: da39a3ee5e6b4b0d3255bfef95601890afd80709
Full chain:
Chain: d69b561148f01c77c54578c10926df5b856976ad
------------------------------------
Verified Issuance Policies: All
Verified Application Policies:
1.3.6.1.5.5.7.3.1 Server Authentication
1.3.6.1.5.5.7.3.2 Client Authentication
1.3.6.1.5.5.7.3.3 Code Signing
1.3.6.1.5.5.7.3.4 Secure Email
1.3.6.1.5.5.7.3.8 Time Stamping
1.3.6.1.4.1.311.10.3.4 Encrypting File System
1.3.6.1.5.5.7.3.6 IP security tunnel termination
1.3.6.1.5.5.7.3.7 IP security user
Cert is a CA certificate
Cannot check leaf certificate revocation status
CertUtil: -verify command completed successfully.
C:\Temp\certs>
It got also pass for endentity certificate but still make external connection.
....
Cert is an End Entity certificate
Leaf certificate revocation check passed
CertUtil: -verify command completed successfully
If you disable network communication (so, for example, non-hostfile DNS can't be contacted), is the output different?
copied certutil.exe from another server where no such issue, compared hashes, launched but the same.
Can you clarify? You mean you copied an alternate version of certutil.exe from a different server and did not see the same behavior?
If so, there is a documented issue with certutil.exe in the exact build of Windows Server 2016 you're running, described here:
https://www.pkisolutions.com/certutil-bug-in-windows-server-2016-fails-to-enumerate-issuance-application-policies-and-oids/
In that case, the error was a failure to enumerate or verify certificate policies enforced by the issuing CA, but since the Microsoft recommendation is to:
copy the certutil (and the accompanying certutil.exe.mui) file from the System32 folder on either a Windows Server 2012 R2, Windows Server 2019 or Windows 10 machine. Place the files and the certificate file you’re wanting to check in a separate folder and run it from there.
...you might want to validate the behavior on other versions of Windows Server or with other versions of certutil.
I used this tool in this link to generate a self-signed certificate for a Windows webserver.
The command to generate the cert is like following
New-SelfSignedCertificateEx -Subject "CN=192.168.56.111" -SAN "192.168.56.111" -IsCA $true -EKU "Server Authentication", "Client Authentication" -KeyLength 2048 -KeySpec "Signature" -KeyUsage "DigitalSignature" -FriendlyName "192.168.56.111" -NotAfter $([datetime]::now.AddYears(5)) -StoreLocation "LocalMachine" -Exportable
After installing the certificate with IIS, and add the certificate to the trusted root CA store in a Windows 10 client, I was able to browse the website with no certificate errors.
However when I try to do the same in a ubuntu 18.04 client by installing the cert to the CA certs store and test using cURL, it doesn't work
Install cert to Ubuntu ca-certificates
openssl s_client -connect 192.168.56.111:443 -showcerts > out.txt
#then use vim to edit out.txt and save the cert to 192.168.56.111.crt
sudo cp 192.168.56.111.crt /usr/local/share/ca-certificates
sudo update-ca-certificates
Test the connection using cURL
curl https://192.168.56.111
And got the error message
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
When adding the cert to the Chrome Certifiates store, Chrome shows NET::ERR_CERT_INVALID
So my question is, why does it work in Windows client but not in Ubuntu 18.04? I can't see any error indicating what's wrong with the certificate in Ubuntu so I'm stuck at the moment.
Your openssl command is not correct:
jonathan.muller#jonathan-muller-C02ZC4EPLVDQ$ openssl s_client -connect drylm.org:443 -showcerts
CONNECTED(00000005)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = blog.drylm.org
verify return:1
---
Certificate chain
0 s:/CN=blog.drylm.org
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
-----BEGIN CERTIFICATE-----
MIIFUzCCBDugAwIBAgISA0xYp5ZHU+NGF1EW/RcUuV0fMA0GCSqGSIb3DQEBCwUA
...
you have a lot of noise in the output.
Here is how to extract the certificate:
echo | openssl s_client -connect 192.168.56.111:443 2>/dev/null | openssl x509 > 192.168.56.111.pem
and you can copy this pem file to the truststore.
Edit:
I just made the exercise by creating a self sign certificate on this website
in my shell:
john#kona$ curl https://test.drylm.org
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
then
john#kona$ echo | openssl s_client -connect test.drylm.org:443 2>/dev/null | openssl x509 > test.drylm.org.crt
sudo cp test.drylm.org.crt /usr/local/share/ca-certificates/
john#kona$ sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
Adding debian:test.drylm.org.pem
done.
done.
and finally:
john#kona$ curl https://test.drylm.org
Path : ~
No more error message with curl.
I am using DelphiMongoDB from Grijjy (DelphiMongoDB) which is working pretty cool so far. But I can't find any functions to authenticate against a MongoDB. Did anybody getting this work or figured out how to do it?
Thanks and best regards
Update: The most up to date version of the Grijjy driver now supports TLS, X.509 client certificate authentication, SCRAM SHA-1 and SHA-256 authentication. We have also tested it against MongoDB Atlas instance at Azure.
Here is a simple example of how to use the authentication.
var
Settings: TgoMongoClientSettings;
Client: IgoMongoClient;
Database: IgoMongoDatabase;
Collection: IgoMongoCollection;
Doc: TgoBsonDocument;
begin
Settings := TgoMongoClientSettings.Create;
Settings.Secure := True;
Settings.AuthMechanism := TgoMongoAuthMechanism.SCRAM_SHA_1;
Settings.AuthDatabase := 'admin';
Settings.Username := 'username';
Settings.Password := 'password';
//Settings.QueryFlags := [TgoMongoQueryFlag.SlaveOk];
Client := TgoMongoClient.Create('my.mongodb.server.com', 27017, Settings);
Database := Client.GetDatabase('mydatabase');
Collection := Database.GetCollection('mycollection');
for Doc in Collection.Find() do
Writeln(Doc.ToJson(TgoJsonWriterSettings.Pretty));
end;
Legacy: Yes, the published Grijjy driver does not support authentication, but we have tested it internally and may add this ability in the near future to Github. You are also welcome to make a pull request if you want to adapt the following changes:
MongoDB currently supports 2 types of authentication, SCRAM and x.509 Certificate Authentication. Internally we have tested the x.509 Certificate Authentication, but the current driver on Github does not reflect this ability. We have not experimented with SCRAM yet.
To make it work with the MongoDB driver we published on Github, you may have to make a couple of changes.
You need to create a self-signed CA and certificate for your MongoDB server.
You need to configure your MongoDB server to use certs.
You need to create a self-signed certificate for your MongoDB client or clients. You can use the same cert for all clients.
You need to enable SSL/TLS connections and use your client certificate with the MongoDB driver.
1 To create all the certificates, you need an existing CA or create a self-signed CA. You can use the openssl.exe binary to do most of this:
Create root certificate authority (ca.pem and privkey.pem):
openssl req -out ca.pem -new -x509 -days 3650 -subj "/C=US/ST=California/O=Company/CN=root/emailAddress=root#domain.com"
To create a self-signed certificate for your MongoDB server (server.pem):
openssl genrsa -out server.key 2048
openssl req -key server.key -new -out server.req -subj "/C=US/ST=California/O=Company/CN=db.myserver.com/emailAddress=user#domain.com"
openssl x509 -req -in server.req -CA ca.pem -CAkey privkey.pem -CAcreateserial -out server.crt -days 3650
type server.key server.crt > server.pem
openssl verify -CAfile ca.pem server.pem
2 To configure MongoDB to use certs on the Windows version (similar on other versions), edit the c:\data\mongod.cfg:
systemLog:
destination: file
path: c:\data\log\mongod.log
storage:
dbPath: c:\data\db
net:
port: 27017
bindIp: 127.0.0.1
ssl:
mode: requireSSL
PEMKeyFile: c:\data\server.pem
CAFile: c:\data\ca.pem
{allowConnectionsWithoutCertificates: true }
{allowInvalidHostnames: true }
You may need allowInvalidHostnames to True if you are using a self signed certificate.
3 To create a self-signed certificate for your MongoDB client (client1.pem):
openssl genrsa -out client1.key 2048
openssl req -key client1.key -new -out client1.req -subj "/C=US/ST=California/O=Company/CN=client1/emailAddress=user#domain.com"
openssl x509 -req -in client1.req -CA ca.pem -CAkey privkey.pem -CAserial ca.srl -out client1.crt -days 3650
type client1.key client1.crt > client1.pem
openssl verify -CAfile ca.pem client1.pem
Note: You will also need to use the client certificate in whatever tool you are using to admin the MongoDB server.
4 To enable SSL/TLS connections for MongoDB driver you may have to change the source files. Our unit Grijjy.Http shows how to enable the driver for ‘https’. Essentially you need to do 2 things to the Connection inside the Grijjy.MongoDB.Protocol unit probably within the method TgoMongoProtocol.Connect :
Set Connection.SSL := True;
Set the Connection.Certificate to the client1.pem you created.
You will have to do some testing, but I hope it points you in the correct direction to make it work. Would love your contribution to the open source project if you can.
As far as I can understand the sources, https://github.com/grijjy/DelphiMongoDB/ doesn't support authentication.
Also from the source, https://github.com/stijnsanders/TMongoWire doesn't either.
FireDAC Mongo uses the C Mongo client library, which supports authentication.
Our Open Source SynMongoDB.pas supports authentication, FPC and almost all Delphi versions (even pre-Unicode). Using variant late-binding to access the BSON/JSON content, it is pretty easy to work with it. Just check the corresponding documentation pages. You can write for instance:
var doc: variant;
...
doc := Coll.FindOne(5);
writeln('Name: ',doc.Name);
writeln('Number: ',doc.Number);
or
var docs: TVariantDynArray;
...
Coll.FindDocs(docs);
for i := 0 to high(docs) do
writeln('Name: ',docs[i].Name,' Number: ',docs[i].Number);
The TMongoClient.OpenAuth method supports both old/deprecated MONGODB-CR method, and the new SCRAM-SHA-1 method:
Client := TMongoClient.Create('localhost',27017);
try
DB := Client.OpenAuth('mydb','mongouser','mongopwd');
...
Note that even if it is part of the mORMot framework, this unit is stand-alone: you don't need to use the ORM, SOA, or MVC parts of the framework - even if it works very well with the ORM, and is able to convert SQL-like statements into MongoDB pipelines, which is a unique very powerful feature. Another unique feature is proper Decimal128 support.
Over a network, also ensure that you use a TLS connection to the server. SynMongoDB.pas can do that under Windows, with no external OpenSSL library needed (it uses the raw Windows SO API).
I am currently testing with EJBCA while having a problem in accessing the administration page.
The EJBCA-4.0.13 is running on CentOS 6.2, with apache-ant-1.8.4, jboss-5.1.0-GA, mysql and mysql-connector-java. Installation is OK and no error occured in the jboss server log and I can access the EJBCA public web page with the url: https://:8443/ejbca. While I cannot access the administration page(https://:8443/ejbca/adminweb) with this information:
Authorization Denied
Cause: Your certificate is revoked or cannot be located in the database.
Any idea will be appreciated!
This is done in LocalCertificateStoreSessionBean.authenticate method. This could mean that you have not properly generated SuperAdmin certificate, or it is revoked, timed out or is issued by another CA that EJBACA's AdminCA.
Check your superadmin.p12 with:
openssl pkcs12 -nokeys -in ./superadmin.p12 -out superadmin.pem
openssl x509 -in ./superadmin.pem -text