In ethernet connected system I use harbor registry for docker images in login session it returns x509: certificate relies on legacy Common Name field, use SANs instead error.
How I resolve this certification problem?
You should regenerate your Harbor certificate, the previous maybe
generated by Common Name, use the SAN field to sign the certificate, https://goharbor.io/docs/2.5.0/install-config/configure-https/
Related
I have an ES Cluster(ES version 7.4.2) that has been running for 3 years.
when I run the following query.
GET _ssl/certificates
I'm getting the output.
"expiry" : "2022-11-20T07:27:29.000Z"
in /usr/share/elasticsearch
For the new 'temescls01-ca.p12' certificate
I run './bin/elasticsearch-certutil cert --ca /etc/elasticsearch/certs/temescls01-ca.p12' and when I enter the 'CA CERT password' it generates a new temescl01-ca.p12 certificate.
For the new 'temescls01-certificates.p12' certificate
I run './bin/elasticsearch-certutil cert /etc/elasticsearch/certs/temescls01-certificates.p12' and enter the 'keystore password'.
I'm using the old certificates' passwords for both new certificates.
I was able to create all 2 certificates. But when I stop the elasticsearch service and replace the old certificates with new certificates by following the document here, the node cannot join the cluster. When I replace the old certificate, the node joins the cluster without any problems.
An example from elasticsearch.yml
elasticsearch.yml
xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: certs/temescls01-certificates.p12
xpack.security.transport.ssl.keystore.password: XXXXXXXXX
xpack.security.transport.ssl.truestore.path: certs/temescls01-certificates.p12
xpack.security.transport.ssl.truestore.password: XXXXXXXXX
Is there something i did wrong?
It’s not possible to extend the expiry date of a certificate. But you can create a new one. If you are using PKCS #12 format of SSL/TLS (p12) certificate you can use this article to create a new certificate.
https://medium.com/p/99820ff87615
We have a service that will generate a CA cert and use that CA cert to sign all other required certs on startup.
The CA cert has an associated private key and is stored in the windows certificate store with Exportable flag. This works fine on most machines but on one of our QA's machine we run into some nasty issues.
When I load the CA cert from the cert store in code and checked HasPrivateKey flag it returns true. Then when I attempt to use the CA cert to sign another cert. It throws keyset does not exist exception.
In the certificate store it says the certificate is valid. On the general page it says
You have a private key that corresponds to this certificate
Good sign! But when we try to right click -> Task -> Export it. The include private key button is grayed out and says
The associated private key cannot be found. Only the certificate can
be exported
We thought its a permission issue so we run mmc in admin mode and still the same result.
On my dev machine I noticed that the private key file is stored in %APPDATA%\Microsoft\Crypto\Keys but its not the case for our QA's machine. We cannot find the private key file in the same folder with the timestamp = CA cert generated time. We also looked into
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\SystemKeys
%WINDIR%\ServiceProfiles\LocalService
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\Keys
but no luck still.
The account used to run the service is Local System so permission shouldnt be an issue here. No special anti-virus installed other than Windows Defender and nothing in Defender's history either.
I was recently ordered by our IT team to disable the NAT pools on my service fabric cluster due to security risks. The only way I could do this was to deploy a new cluster with all its components.
Because this is a test environment I opt to use a self signed cert without a password for my cluster, the certificate is in my vault and the cluster is up and running.
The issue I have now is when I try to deploy my application from an Azure Devops Release Pipeline I get the following message:
An error occurred attempting to import the certificate. Ensure that your service endpoint is configured properly with a correct certificate value and, if the certificate is password-protected, a valid password. Error message: Exception calling "Import" with "3" argument(s): "The specified network password is not correct.
I generated the self signed certificate in Key Vault, downloaded the certificate and used Powershell to get the Base64 string for the service connection.
Should I create the certificate myself, with a password?
With the direction of the two comments supplied, I ended up generating a certificate on my local machine using the powershell script included with service fabric's local run time.
A small caveat here is to change the key size in the script to a large key size than the default, because ke vault does not support 1024 keys.
I then exported the pfx from my user certificates added a password(this is required for the service connection) and impoted the new pfx into my key vault.
Redeployed my cluster and it worked.
We have a root certificate authority made with OpenSSL. Its file-based, runs on RHEL, uses "serial" and "index.txt" etc.
Now in a lab environment we have added an intermediate standalone certificate authority using Active Directory Certificate Services, standalone (i.e. not an AD or domain member), running on Windows Server 2012 (all latest updates applied). We signed the intermediate CA with our root and ADCS is up and running successfully. But what we're finding is that we actually cannot issue any certs from this intermediate CA.
When we use the management console and attempt to issue a requested cert, the cert ends up in "Failed Requests" with the message:
Active Directory Certificate Services denied request 4 because The revocation function was unable to check revocation for the certificate. 0x80092012 (-2146885614 CRYPT_E_NO_REVOCATION_CHECK).
The request was for CN=obelisk.sand.idfconnect.lan, OU=IDFC, O="IDF Connect, Inc.", L=Wilmington, S=Delaware, C=US. Additional information: Error Constructing or Publishing Certificate Resubmitted by OBELISK\Administrator
If I look at the request, I can see the is defined as:
[1]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=file:////obelisk.sand.idfconnect.lan/CertEnroll/Obelisk Intermediate CA.crl (file:////obelisk.sand.idfconnect.lan/CertEnroll/Obelisk%20Intermediate%20CA.crl)
If I use IE to browse that file:// url, it pops open Windows Explorer, where I see the files I'd expect, i.e.
nsrev_Obelisk Intermediate CA.asp
Obelisk Intermediate CA.crl
Obelisk Intermediate CA+.crl
obelisk.sand.idfconnect.lan_Obelisk Intermediate CA.crt
Lastly, when I view the properties of the intermediate CA from the MMC, and look at its certificate, at the bottom of the details it says: "Extended Error Information: Revocation Status : The revocation function was unable to check revocation for the certificate."
Any advice to get this intermediate CA working greatly appreciated!
Add the public root certificate to the machine store (certlm.msc) trusted root certificate authorities.
Add the public root certificate CRL to the machine store (certlm.msc) trusted root certificate authorities.
My certificate is stored in a custom store under "Certificates(Local Computer)" instead of under "Personal".
Normally, if the cert is located under personal, i just use C:>netsh http add sslcert ipport:0.0.0.0: certhash= appid= certstorename=MY
where, certstorename=MY is already assumed by default if not specified.
This works fine until we were required to store the certificate in a custom store other than the existing personal, trusted people, trusted publishers, etc. etc.
If we called our new store "my cert store", how would the new netsh command look like?
how does the word "MY" map to the "Personal" store? is there a dictionary someplace that maps these?
i checked the System.Security.Cryptography.X509Certificates namespace and there exises an enum called StoreName with the following values:
AddressBook - The X.509 certificate store for other users.
AuthRoot - The X.509 certificate store for third-party certificate authorities (CAs).
CertificateAuthority - The X.509 certificate store for intermediate certificate authorities (CAs).
Disallowed - The X.509 certificate store for revoked certificates.
My - The X.509 certificate store for personal certificates.
Root - The X.509 certificate store for trusted root certificate authorities (CAs).
TrustedPeople - The X.509 certificate store for directly trusted people and resources.
TrustedPublisher - The X.509 certificate store for directly trusted publishers.
I tried all of them on the netsh command as certstorename and i always get this error:
SSL Certificate add failed, Error:1312
A specified logon session does not exist. It may already have been terminated.
What you are trying to do seems correct. Could you retry after applying hotfix http://support.microsoft.com/kb/981506 for a problem which actually matches your symptoms exactly.
A huge flaw is that even if the PrivateKey is not persisted properly, the private key icon will still show up in mmc and it will say "There is a private key associated with this certificate". To know for sure that the private key is being properly imported,
Right click on C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys and take a note of how many files are in the folder (this is where the private keys are kept).
Import the pfx file / however you are adding the certificate/key to the store
Check the file count again of that folder, there should be 1 more file than before
You can try testing this with a newly created, self-signed certificate with a tool like open-ssl. Was stuck on this for weeks until I found this stackoverflow post, Inserting Certificate (with privatekey) in Root, LocalMachine certificate store fails in .NET 4
Another gotcha is to be sure the certificate is in Local Computer (not user), but it looks like you already got that part down.
Open your certificate and double check whether it actually contains a PrivateKey. Depending on how you exported/imported it, it may have been truncated to a public-only data.
In explorer, just double click and check whether "this cert contains private key" warning label is visible on the first tab, just under the expiry dates
I had this problem when the certificate was installed in my local user store, instead of the local machine store. Installing in localMachine/my cleared it up.
Derrick. The certstorename just needs quotes. The AppId is the hardpart. Remove the EnhancedKeyUsageList part if you made a self-signed cert. Otherwise prefer to use a cert designed for a server side certificate.
$appid = "appid={"+(get-host).InstanceId.guid+"}"
$certhash = ls Cert:\LocalMachine\my | where {$_.EnhancedKeyUsageList -Match 'Server' -and $_.subject -match (hostname)}|select -expand Thumbprint -last 1
$cmdline='netsh http add sslcert ipport=0.0.0.0:443 certhash=' + $certhash + ' "' + $appid + '"'
resulting with netsh http add sslcert ipport=0.0.0.0:443 certhash=DD2AA37F947FC61766AF95ADA93DFDC1B171CB8B "appid={723b1673-7ec2-42f2-96c3-e1f5b726feaf}" certstorename="my cert store"
netsh http delete sslcert ipport=0.0.0.0:443
Invoke-Expression $cmdline
SSL Certificate successfully added