During initial configuration of the Puppet agent, the agent obtains a security certificate signed by an authority recognized by the master -- most often the master itself -- with which it will subsequently identify itself to the master. Does this certificate ever expire or require an update?
Yes, all certificates signed by the Puppet CA have an expiration date, including agents' certificates, the master's certificate, and the CA's own self-signed certificate if in fact it is using such. The expiration timestamp is set by adding a fixed offset (specified by the configuration setting ca_ttl) to the date & time at which the cert is signed. The default ttl is five years, which is long enough to cover the full service life of all machines in many organizations.
More problematic than an agent's certificate expiring is the CA cert expiring. If you let that happen without configuring a new CA cert then master and nodes will thereafter reject each others' certs, forcing you to manually configure new certs for all of them.
Related
How can the certificates inside a Corda network be signed by Certificate Authority? Is there a defined process for managing the certificates for each Node and participants in Corda network?
To join a Corda network a Node needs to obtain a certificate from the Identity Manager of the network they want to connect to. It is described in the documentation of Corda Enterprise:
To connect to a compatibility zone you need to register with its
certificate signing authority (or doorman) by submitting a certificate
signing request (CSR) to obtain a valid identity for the zone. This
process is only necessary when the node connects to the network for
the first time, or when the certificate expires. You could do this out
of band, for instance via email or a web form, but there’s also a
simple request/response utility built into the node.
Before using this utility, you must first have received the trust
store file containing the root certificate from the zone operator. For
high security zones, this might be delivered physically.
So, first the node operator needs to get in touch with the network operator offline and provide its X.509 information. The network operator will provide the node with:
truststore.jks, the network/zone operator’s root certificate in keystore with a locally configurable password as protection against
certain attacks
At this point the node can then use the node utilities to make a CSR (Certificate Signing Request) to the Identity Manager to obtain the node certificate and receive the following:
nodekeystore.jks, which stores the node’s identity key pairs and certificates
Note that this can be also provided directly by the network operatort, I guess it depends on their policy. It is also described in the documentation.
The node can also create its own sslkeystore.jks,
which stores the node’s TLS key pair and certificate
that can be used, for example, to connect an external RPC client to the node.
The node certificate expires and can be revoked by the Identity Manager, so in that case it needs to make other specific request to obtain a new certificate.
Further readings:
https://docs.corda.net/docs/corda-enterprise/4.8/network/permissioning.html
https://docs.corda.net/docs/cenm/1.5/pki-guide.html#certificate-hierarchy-guide
My payment gateway requires ssl certificate pinning for their payment gateway endpoint on my side.
Does Firebase support ssl pinning for cloud functions/hosting?
I can't find this information in the official documentation or anywhere else on the net.
Details published in the bank's technical requirements form:
Response URL and Port Number
Specify the Response URL and Port Number for us to send you payment notification.
SSL Certificate:
(To establish secure connection with your Response URL.)
The standard SSL certificate authority are Comodo or Versign.
Please upload the SSL Certificates for both environments that associate with the UAT and Production URL respectively.
SSL certificates can be in format of .cer or .crt or you may zip it in one zip file.
Note: Payment notification will fail to reach you if you provide incorrect SSL Certificate.
What is described here is a really strange requirement -- it sounds like they're telling you you have to provide them with the specific SSL certificate your site is running.
This is unrealistic for nearly all cases as SSL certificates expire after a year, and particularly unrealistic for Firebase Hosting where certificates only last for three months.
You should be able to download the certificate for your Firebase Hosting site (see e.g. this ServerFault question) and upload it to your bank, but the certificate is going to change approximately every two months.
I'd reach out to your bank and ask them more about this requirement, as it seems bizarre and unduly burdensome. Perhaps they are merely trying to ask for the root certificate in the trust chain? If that's the case, you can provide the Let's Encrypt root certificate and it should be fine for the time being (note: Firebase Hosting does not make a promise of keeping the same certificate authority indefinitely).
I am trying to set up smart card authentication for a website that I have created. Setting authentication to Windows and setting SSL to required I can get the smart card reader to pop up when they go to the web site. There are 2 credentials on the card though and only one of them is showing up as an option (the information I need is on the other credential). I asked a co worker and he said in IIS 6 there was a way to specify a location on the smart card to look for certificates. I have been researching this issue for about a week now but haven't been able to find a solution to this issue yet. Does anyone know how to do this?
IIS really only knows about certificate-based authentication, not smart-cards per se (which is really just a form of cert-based authentication). Configure your site to use certificate-based authentication, eg "Require Client Certificates" and IIS will chain the call down to Windows security, which, in turn, recognizes that among the sources for identity certificates is the smartcard reader. Depending upon your site requirements, you may also need to enable Certificate Mapping, which translates certificates into Windows account identities.
When certificates are required (or accepted) IIS will ask for a client cert in the SSL negotiation when the session is started. IIS will send a list of the Certificate Authorities it trusts to the client. The client then takes those and sees which match the list of Certificate Authorities it trusts. It then take sthe list of common entries and checks to see if it has any certs issued by a CA both sides trust. Generally, if there are none it will simply not send a cert and the request fails if the cert is required. If there is just one certificate IE will generally send that without asking the client which cert to send, but it will prompt for a PIN if required. Finally, if there are more than one certificate issued by a CA both sides trust then a dialog box will be presented to the client asking which cert to use.
In this case it sounds like perhaps the credential (certificate) you want the client to send is issued by a Certificate Authority that isn't trusted by one or both sides.
I have asp.net site on my local machine.
IIS configuration:
binding: https binding with self-signed certificate,
ssl settings: Require SSL and Require client certificates
I have installed next certificates on my machine:
CA certificate (call it 'CA Center') in Trusted Root Certification Authorities store.
Client certificate issued by 'CA Center' in Personal store
I go to site and accept server certificate. But next i get error:
HTTP Error 403.7 - Forbidden. The page you are attempting to access requires your browser to have a Secure Sockets Layer (SSL) client certificate that the Web server recognizes.
That means browser (IE) doesn't send applicable client certificates to server.
What's wrong? Should I configure something else?
I had exactly this problem, and it took me an age to figure out the cause. Turned out it was because my computer was part of a domain, and there was some sort of group policy for that domain was restricting the trusted root certificates that IIS would be willing to accept. I don't know exactly what the setting was or how to alter it, but I found I could work around it by choosing to install my certificate into the enterprise physical store using the certutil command:
certutil -addstore -v -enterprise root CertificateAuthority.cer
It sounds like the browser never prompted you to select a client certificate to send which means something is incorrect with the SSL Handshake. Try testing this with OpenSSL.
Additionally, a very common problem is having too many certificates in the Trusted Root CA folder. When the server sends the list of CAs, there is a limit to how large the list can be so if it exceeds the limit, it will truncate the remaining CA certificates. Make sure the Trusted Root CA folder doesn't have too many certificates. One way to check this is temporarily modifying the SCHANNEL in the registry editor to not send the CA List, and then re-try.
Start > Run > 'regedit' > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL >
right-click > New > DWORD > 'SendTrustedIssuerList' > Value:0
Re-install the certificates and check their effective dates. From Microsoft Support:
Download the root server certificate in a browser on the server
computer. Run the Iisca.exe command line utility that is located in
the Inetsrv directory.
Check the effective date on the client certificate and make sure that
the date and time has arrived.
Check the expiration date and make sure that the certificate has not
expired. Contact your certificate authority to see if your
certificate has expired.
Issues have been asked many times about how to handle self-signed certificates with Java and implementations are often provided. However, I'm not sure that these implementations will give me the security/trust I am looking for.
My circumstance is as follows: I have a client program connecting to our server application. Both of these we have complete control over. Our client post's a stream using https to a URL at our server, and the server responds. Currently (and this is what I'm trying to fix) the server has a self signed certificate. Java doesn't like this and FOR TESTING ONLY, we are pretty much ignoring the certificate altogether by trusting any certificate.
I have little knowledge of SSL. My boss says we can use our self-signed certificate and it will be secure as long we don't make our crypt. key public. This sounds correct to me, but a lot of posts say self-signed cert's are automatically vulnerable to man-in-the-middle attacks. Does this mean SSL sends the crypt. key along with the certificate?
Since we have control over both ends, should we just encrypt our data ourselves with a secret key, and decrypt it at the end using our key? Or is there reason to use SSL?
Instead of trusting any certificate blindly (which would make the connection vulnerable to MITM attacks), configure your Java client to trust that particular certificate. Self-signed certificates do not inherently make SSL/TLS connections vulnerable to MITM attacks, they just make their distribution and the evaluation of trust more specific to this particular deployment (i.e. you have to configure it manually).
You can do this in at least 3 ways (pick the easiest one for you, I'd suggest bullet point #2):
Import the server certificate into your client's global trust store (lib/security/cacerts in your JRE directory). This will make all applications run with this JRE trust this certificate.
Import the server certificate into another truststore (possibly a local copy of lib/security/cacerts) and make this particular application use this truststore. This can be done using the javax.net.ssl.trustStore system properties.
Make your client application use an SSLContext initialised with an X509TrustManager configured to trust that certificate: either something written manually or a trust manager coming from TrustManagerFactory initialised by loading a local keystore that contains that particular certificate (as in the previous method).
You'll find more details about all this in the JSSE Reference Guide.
(This answer to a similar question should give you the details for doing all this properly, in particular keytool -import ....)
The arguments against self signed certificates mainly apply to web-applications. Since with the current infrastructure a browser won't be able to validate your self-signed certificate.
Since you have control over the client, you can simply hardcode the certificate you expect into the client. For example you might calculate the sha1 hash of the certificate, and check if that matches the expected value. That way you don't even need to trust hundreds of CAs.
To achieve secure communication you need to first ensure your talking to the right computer. When the client first attempts to establish a secure connection, it pings the server and the server responds with its cert. At this point you MUST validate the servers cert before continuing. The cert includes a public key and signature that can be used to ensure the cert is valid. For example, in web browsers this means checking to see it's been signed by an authority listed as trusted in your browser settings, if that check fails you'll see red warnings in your browser. In your case this will mean you have manually (or in code) added the servers cert into a trust store so that it is trusted.