When generating certificate via directadmin using letsencrypt for mail.domain.com, directadmin told me that it generated a certificate called:
letsencrypt.key
But in order to make the mail.domain.com contains the certificate, I have to edit the dovcot config like below:
ssl_cert = </etc/letsencrypt/live/YOURSITE/fullchain.pem
ssl_key = </etc/letsencrypt/live/YOURSITE/privkey.pem
But as shown above dovcot only take 2 parameters for certs and I only have letsencrypt.key
How do I point this certificate in dovcot so, that it will use let's encrypt certs ?
UPDATE:
I read that the built-in feature letsencrypt in DA actually combined the cert into one. I search Google and redirected to a site that we can manually install the DA letsencrypt so that it will generate 3 files for certs where I can use to link in dovcot.
So in order to do this do I have to disable the built in feature of DA Let's encrypt?
The URL: https://www.interserver.net/tips/kb/letsencrypt-support-directadmin-control-panel/
Is this the best way? What about the renewal process? Will directadmin handle the cert's renewal process or we need to create cronjob for that ? I'm lost.
My aim is just to enable certificate for the mail.domain.com (using let's encrypt) so when I log in using 3rd party email client, it would not complain about invalid certs.
I never heard about mail_sni someone pointed out that I should use this to make it work. Following this documentation, everything is working:
http://forum.directadmin.com/showthread.php?t=56297
Related
Is it possible to have Wazuh Manager served through custom SSL certificates? The wazuh-certs-tool gives you a self cert, and every other way to get it served through SSL has failed.
The closest I've gotten to getting this to work is I've had the dashboard being served by a custom SSL, I had agents connecting to it successfully and providing a heartbeat, but had zero log flows or events happening. When I had it in this state, I saw the API calls were coming from what appeared to be a Java instance, erroring out complaining about receiving certificate. I saw a keystore file located at /etc/wazuh-indexer. Do I also need to add the root-ca cert here as well?
It seems that your indexer's excepted certificates do not match the certificates in your manager or the dashboard.
If you follow the normal installation guide, it shows how and where to place your certificates, that are created using the wazuh-cert-tool. But, certificates can be created from any other source, as long as they have the expected information, you can check that informationenter link description here here.
I would recommend you follow the installation steps in the installation guide, from scratch to make sure you copy each excepted certificate in it's place and that the configuration files for your indexer, dashboard, and manager take into account the correct files. All you would need to change, the creation of the certificates, to have your own custom certs.
In case of further doubt, do not hesitate to ask.
I have implemented SSO login to argocd through Active Directory.
When I try to access argocd, I get error :
Your connection is not private
Attackers might be trying to steal your information from argo-cd.daa.pks.dell.com (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_AUTHORITY_INVALID
When I check the logs of argocd pod, I see this error :
finished unary call with code Unauthenticated" error="rpc error: code = Unauthenticated desc = no session information" grpc.code=Unauthenticated grpc.method=List grpc.service=application.ApplicationService grpc.start_time="2022-05-02T02:06:34Z" grpc.time_ms=5.178 span.kind=server system=grpc
But when I open ArgoWorkflow and try to open argocd, it works.
Please help me in understanding what is the issue?
You have to use a trusted certificate (by a certificate authority like letsencrypt for example if you want to use it on internet)
Example: (sorry it's in French but you got the point)
https://blog.blaisot.org/letsencrypt-wildcard-part1.html
https://blog.blaisot.org/letsencrypt-wildcard-part2.html
However if it's in your enterprise network, just ask for an SSL certificate from the authority of certification and use it. ( https://argo-cd.readthedocs.io/en/stable/operator-manual/tls/ )
You can also disable TLS/ssl to avoid this kind of error if you want.
Bguess
We are using IdentityServer4 and our version loads the signing key from a PFX file in file system or from the windows certificate store. Using the certificate works. The question is - which certificate issuer should be used in production?
Is a certificate from a public CA recommended? Or is it enough to have a self-signed certificate (without a CA at all) such as it can be created with IIS Manager?
In our tests we have found that the client could still validate the signature in the access token, even if the signing certificate would not have a valid CA chain on the client.
In the docs, it says that you can also use raw key material instead of a certificate:
http://docs.identityserver.io/en/latest/topics/crypto.html#token-signing-and-validation
In this scenario there would be no CA chain whatsoever.
That leads me to the assumption, that when the client loads the public signing key (via the HTTP(s) endpoint), the CA chain information might not be passed anyways. Is that right? Through the loading mechanism via HTTPs you also have a combined security mechanism.
So my conclusion is that for the signing credential a self-signed cert is just as safe as one from VeriSign. Can this be confirmed?
There is no certificate involved in signing and verifying the tokens. Only a private and public key (RSA or ECDSA key).
However a certificate can be useful to "import/transport" the keys into .NET. So, because of that we don't care about who issued the certificate.
When importing the key, one approach is to bundle the certificate that holds the public key + the private key and store it in a PKCE#12 file (.pfx/.p12 extension). Then load that file into .NET. Before .NET 5 working with keys was a bit hard.
The more important thing is that you can manage and deploy the private key in a secure way and that it is persisted over time.
Optionally, you can add support for key-rotation.
Currently our company uses a digital certificate from Versign/Symtanec for code signing our software.
We have someone in our company attempting to persuade us to use a self-signed certificate instead of one purchased from Verisign/Symantec. Partially as a "cost-down" procedure (even though they're pretty damn cheap for a 2-3 year renewal), and partially to make things easier in a patching sense, as the systems our software runs on (industrial machines) has installed software with a non-Windows certificate store in which our certificate also needs to be managed. Apparently they want use to use the Windows Root CA in order to generate our certificate so we don't have to keep patching new certificates on and our certificate will essentially last as long as the Windows Root CA is valid ...
Everywhere I've been looking, I've found that some people use self-signed certificates for things like website identity verification over the net, but when used in a code-signing context, there are a lot of examples for certificate generation and people saying that you can use them for testing in an environment that's closer to a production environment (which I have done in the past), but I can't find any hard reasons as to why not to use a self-signed certificate for code-signing production software.
It's been a while since I've had to look a the certificate side of things, but this just feels wrong.
It's possible that just I'm not experienced enough with certificates to see why this is a good idea. Does anyone have any input to help me understand the full implications of this?
Using a self-signed certificate should not work. The idea is that "someone trustable" (not you; but Verisign or some other party that should check your credentials) confirms that something is certified.
I'm not sure exactly how this works in Windows. Might be that they didn't implement something properly.
There is no problem using a self signed certificate in windows. Just put the root CA certificate and the signing cert in the Windows cert store of the client machines that will run the signed application and/or driver.
Managing self signed certs within an organization is a PITA. Hence why people pay good money to get somebody else to do it.
If you are going to distribute your signed code outside your organization it is even more painful as you will need to persuade your customers to accept your CA certificate, and nobody should ever accept a root certificate from an unknown source or sent via an insecure or unverifiable means.
See this answer for instructions on creating a self signed CA and signing certificates using it.
The same is possible (but in my opinion more complicated) using Windows PowerShell, The sequence is he same but the commands change.
I'd like to automate the task of requesting client certificates from the CA attached to our Active Directory. Currently, I use certmgr and click "Request New Certificate" from the menu and do several other selections, including selecting an appropriate policy.
Surely, Powershell can help me with this, as I already use it to get rid of old certificates. Is there a module which can be used for this or does Powershell 3 cover this out-of-the-box?
I think certreq could be what you are looking for.
Certreq can be used to request certificates from a certification authority (CA), to retrieve a response to a previous request from a CA, to create a new request from an .inf file, to accept and install a response to a request, to construct a cross-certification or qualified subordination request from an existing CA certificate or request, and to sign a cross-certification or qualified subordination request.
Then there is another useful utility when dealing with certificates in windows - certutil