NX-OS disabled tcp timestamps

Does anyone know the NX-OS equivalent of the IOS command 'no ip tcp timestamp'? This would be to disable tcp timestamps so an attacker cannot gather system uptime.
Thanks.

I don't believe it can be disabled.
As you've noted, the command is not available in NX-OS. Furthermore, there doesn't appear to be any equivalent recommended in Cisco's guide to securing NX-OS. One can only assume that Cisco does not consider it to be a vulnerability.
I checked by scanbing a Nexus 5548UP just now (with the latest NX-OS 5.2(1)N1 installed) and nmap was able to get a close estimate of the actual system uptime (varied by a couple of days from that reported from the device's CLI).

Similar Messages

RV042 TCP Timestamp disable

We have an RV042 router at location that we are a tenant of. They ran a security scan of it and found that TCP timestamp is on. Is there a way to disable that feature? I do not see an option in the web management tool. Any ideas?
Thanks,
Keith

Hi Keith,
Sorry, the RV042 does not have any setting to disable TCP Timestamp. I have never seen that setting on any of the Small Business routers.

TCP1323Opts question - TCP Timestamps

Hi,
We have to be PCI-DSS compliant and have several Windows servers running ISA and TMG.
We have:
Win 2K with ISA 2000 (on it's way out)
Win 2K3 with ISA 2006
Win 2K8 R2 with TMG 2010
All of these servers, in the registry have TCP1323Opts set to '0' as per
http://technet.microsoft.com/en-us/library/cc938205.aspx to disable TCP Timestamps.
This is confirmed using Netsh where RFC 1323 Timestamps : disabled
However, for PCI-DSS compliance we have to run vulnerability scans.
Although only informational, all these servers come back as giving Timestamp replies.
Although vulnerabilities due to this are minimal, from the timestamp is can be calculated how long a server has been running and therefore you can work out if it is missing the latest patches due to a lack of a reboot.
I'm mainly puzzled as to why this is showing up when it is meant to be disabled.
I've searched high and low across the Internet and can't find anything apart from the instructions as to how to change that reg entry.
Do I need to do anything extra for the driver or something?
Any help appreciated,
Adrian

Hi,
Thanks for the post.
Please check if you add the Tcp1323Opts registry key as follows:
Tcp1323Opts
Key: Tcpip\Parameters
Value Type: REG_DWORD—number (flags)
Valid Range: 0 or 2
0 (disable the use of the TCP timestamps option)
2 (enable the use of the TCP timestamps option)
Default: No value.
Description:
This value controls the use of the RFC 1323 TCP Timestamp option. The default behavior of the TCP/IP stack is to not use the Timestamp options when initiating TCP connections, but use them if the TCP peer that is initiating
communication includes them in their synchronize (SYN) segment.
For more information about TCP/IP Registry Values, you could access this link:
http://download.microsoft.com/download/c/2/6/c26893a6-46c7-4b5c-b287-830216597340/tcpip_reg.doc
Hope this helps.
Miles
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

TCP timestamps security vulnerabilities

On my ASA 5520 with version 9.1(2)8 I am getting a warning about tcp timestamps when running the external security scan.
" It was detected that the host implements RFC1323"
Solution = Disable TCP timestamps
Please correct me if I am wrong, from what I can tell the security issues in RFC1323 have been fixed by RFC1948 and that has been obsoleted by RFC6528. But RFC1323 has been obsoleted by RFC7323, though RFC7323 was just released this September.
What should I do to eliminate my risk? Can I configure something on the ASA to use RFC1948 or 6528? Do I just have to disable tcp timestamps all together?
I found this page on clearing tcp timestamps but that disables PAWS
thanks for any advice

I have done some more reading and found a couple of things about TCP Normalization and Randomization that can be configured on the ASA. Does anyone have any experience with that? Maybe it will help?

Block TCP timestamp in Windows Server 2012

Hi,
we are looking for solution to disable the TCP timestamp in Windows server 2012. Reason its vulnerability in security report.
thanks
Faisal
durranifaisal

Hi,
In general, it is not recommended to disable TCP timestamp option. For more detailed information, please refer to the RFC below:
TCP Extensions for High Performance
If you readlly wanted to disable it, please set the value of the following registry in the regsitry editor to be 0:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts
If that registry does not exist, please add it to see if it can disable TCP timestamp option.
Best regards,
Susie

Solution for TCP timestamp response in VAPT report

There was a vulnerability test run on our developmental server having Red Hat Enterprise Linux Server release 5.11 (Tikanga) as the OS. There is one among others of concern here; it is to do with TCP timestamp response. The solution suggested is:
Set the value of net.ipv4.tcp_timestamps to 0 by running the following command:
sysctl -w net.ipv4.tcp_timestamps=0
I did not find the parameter net.ipv4.tcp_timestamps when I did sysctl –a.
Please suggest how to go about it.
Please revert with the reply to my query.
Regards

Btw, I don't know the source, but I found the following info:
NOTE: Disabling timestamps will negatively impact performance of TCP transfers over high BDP
links if the underlying system uses that information to adjust the receive window or transmit buffer.
For typical LAN applications, timestamp removal should have no impact. For WAN data transfer speeds
using network infrastructure where packet reordering or loss is possible (load balanced lines, wireless,
routing hardware with multiple concurrent transaction paths, etc), TCP timestamps, along with the other
RFC 1323 options and a current congestion control algorhythm, should be used or performance will suffer.
TCP PAWS is also disabled if timestamps is disabled, which will negatively impact performance. Additionally,
the underlying OS should randomize the source timer at the beginning of the TCP session, rendering
the security concern moot. You will need to check your specific OS and patch level to verify that this is
functioning properly.
Don't disable timestamps unless you understand the performance impact to the applications involved. If you run into performance issues, people will most likely never find out the reason, which I think does a lot more damage than the security this setting could ever fix.
The underlying OS should randomize the source timer at the beginning of the TCP session...
Maybe an idea for the Oracle UEK kernel team.

Cannot disable TCP/IP nagle algorithm

I'm working with DS6.3 in a MMR configuration.
What does this message means?
[06/Mar/2009:11:59:09 -0500] - WARNING<12364> - Connection - conn=-1 op=-1 msgId=-1 - Configuration warning Cannot disable TCP/IP nagle algorithm: error -5962 (The value requested is too large to be stored in the data buffer provided.). Check your system.
[06/Mar/2009:11:59:11 -0500] - WARNING<12364> - Connection - conn=-1 op=-1 msgId=-1 - Configuration warning Cannot disable TCP/IP nagle algorithm: error -5962 (The value requested is too large to be stored in the data buffer provided.). Check your system.
[06/Mar/2009:11:59:13 -0500] - WARNING<12364> - Connection - conn=-1 op=-1 msgId=-1 - Configuration warning Cannot disable TCP/IP nagle algorithm: error -5962 (The value requested is too large to be stored in the data buffer provided.). Check your system.
[06/Mar/2009:11:59:15 -0500] - WARNING<12364> - Connection - conn=-1 op=-1 msgId=-1 - Configuration warning Cannot disable TCP/IP nagle algorithm: error -5962 (The value requested is too large to be stored in the data buffer provided.). Check your system.
Is this something I must be aware??
Where do I disable this option within the DS ?
What action should i take ??
Why this messages appear?
Any help will be appreciate it.

I edited dse.ldif and added the option to turn nsslapd-nagle to "off" but it disappeared out of the config.Did you edit dse.ldif while the DS instance was running? That's not recommended as dse.ldif is read only once at startup and then frequently written out. Your choices are:
- Stop instance, edit dse.ldif and start instance
- modify cn=config on the fly.
Most importantly, check if it's possible for your load balancer to do LDAP health checks as opposed to TCP level health check. If it's LDAP level, then the load balancer will bind, do a search of some sort and unbind. TCP level checks just verify if a connection can be established (from LB to DS) and by the time DS tries to set some extra parameters on the connection, the load balancer has dropped lost interest. Editing nsslapd-nagle will only hide the problem, not solve it.
Edited by: etst123 on Mar 17, 2009 4:15 PM
(edited sentence about dse.ldif)

IDSM-2 disable tcp reset and RiskRating

Hi all, i have a IDSM-2 and it's not ywet in production because I need to set the IDSM-2 to just monitor the connection and do not take any action...
The module is in the default signatures configuration and some of the active signatures have the TCP reset option marked.... and some signatures have RiskRating set to 100. It's a problem because the Event action rule will drop the signatures with a risk rating of 100.
Is there any way to have the IDS just in monitoring state?
How can I do it?
The IDSM-2 is in promiscuous mode... and I have about 50 vlans going trough the module with a SPAN configuration
Thanks in advance.
Fabio

Yes, you may use IDSM2 in promiscuous mode to monitor SPAN-session. It is the best way in your case because the module will not affect the traffic.
But also you can disable the event-action for high-risk rating signatures. I think it will be useful because you have 50 vlans and this amount of traffic may cause high CPU load.

Unable to disable TCP keep alive probing

Hello,
I work with a mobile phone which seems to have problems if a keep alive packet arrives close with a payload packet. Therefore I would like to disable keep alive probing on my Java 1.5 windows XP plattform.
I tried it with:
Socket socket = serverSocket.accept();
socket.setKeepAlive(false);
However the Java application sends keep alive probes anyway. Is this a known bug? Are there some workarounds?
Even if the keep alive is enabled, Java seems to violate RFC recommendations guiding to set an interval of 2 hours. If I sniff with Ethereal I can see keep alive packets in an interval shorter than 2 minutes (sent from the java application socket).
Is this another bug?
Kind regards
Hans-Joerg

(a) Java doesn't send keepalives at all, so it's not 'another bug'. The TCP stack sends them.
(b) TCP may only do so if the application has specifically requested them, which you haven't.
(c) Java doesn't turn TCP keepalive on by default.
(d) TCP may only send a keepalive packet every two hours, unless a global system setting has been changed, which you haven't mentioned.
So, (e) if you're getting them unasked, and more frequently than two hours, either the TCP stack has a major bug, which isn't likely, or they're not keepalive packets, which is orders of magnitude more likely.
The phone shouldn't have any problem with real keepalive packets: they're just acknowledgements quoting a sequence number 1 less than the receiver expects, so the receiver replies with the correct sequence number. This shouldn't cause a competently implemented TCP stack any grief whether in a mobile phone or a supercomputer.
So I would examine your assumption that it's a keepalive packet.

Windows TCP Socket Buffer Hitting Plateau Too Early

Note: This is a repost of a ServerFault Question edited over the course of a few days, originally here: http://serverfault.com/questions/608060/windows-tcp-window-scaling-hitting-plateau-too-early
Scenario: We have a number of Windows clients regularly uploading large files (FTP/SVN/HTTP PUT/SCP) to Linux servers that are ~100-160ms away. We have 1Gbit/s synchronous bandwidth at the office and the servers are either AWS instances or physically hosted
in US DCs.
The initial report was that uploads to a new server instance were much slower than they could be. This bore out in testing and from multiple locations; clients were seeing stable 2-5Mbit/s to the host from their Windows systems.
I broke out iperf
-s on a an AWS instance and then from a Windows client in the office:
iperf
-c 1.2.3.4
[ 5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55185
[ 5] 0.0-10.0 sec 6.55 MBytes 5.48 Mbits/sec
iperf
-w1M -c 1.2.3.4
[ 4] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55239
[ 4] 0.0-18.3 sec 196 MBytes 89.6 Mbits/sec
The latter figure can vary significantly on subsequent tests, (Vagaries of AWS) but is usually between 70 and 130Mbit/s which is more than enough for our needs. Wiresharking the session, I can see:
iperf
-c Windows SYN - Window 64kb, Scale 1 - Linux SYN, ACK: Window 14kb, Scale: 9 (*512)
iperf
-c -w1M Windows SYN - Windows 64kb, Scale 1 - Linux SYN, ACK: Window 14kb, Scale: 9
Clearly the link can sustain this high throughput, but I have to explicity set the window size to make any use of it, which most real world applications won't let me do. The TCP handshakes use the same starting points in each case, but the forced one scales
Conversely, from a Linux client on the same network a straight, iperf
-c (using the system default 85kb) gives me:
[ 5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 33263
[ 5] 0.0-10.8 sec 142 MBytes 110 Mbits/sec
Without any forcing, it scales as expected. This can't be something in the intervening hops or our local switches/routers and seems to affect Windows 7 and 8 clients alike. I've read lots of guides on auto-tuning, but these are typically about disabling scaling
altogether to work around bad terrible home networking kit.
Can anyone tell me what's happening here and give me a way of fixing it? (Preferably something I can stick in to the registry via GPO.)
Notes
The AWS Linux instance in question has the following kernel settings applied in sysctl.conf:
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576
net.ipv4.tcp_rmem = 4096 1048576 16777216
net.ipv4.tcp_wmem = 4096 1048576 16777216
I've used dd
if=/dev/zero | nc redirecting to /dev/null at
the server end to rule out iperfand
remove any other possible bottlenecks, but the results are much the same. Tests with ncftp(Cygwin,
Native Windows, Linux) scale in much the same way as the above iperf tests on their respective platforms.
First fix attempts.
Enabling CTCP - This makes no difference; window scaling is identical. (If I understand this correctly, this setting increases the rate at which the congestion window is enlarged rather than the maximum size it can reach)
Enabling TCP timestamps. - No change here either.
Nagle's algorithm - That makes sense and at least it means I can probably ignore that particular blips in the graph as any indication of the problem.
pcap files: Zip file available here: https://www.dropbox.com/s/104qdysmk01lnf6/iperf-pcaps-10s-Win%2BLinux-2014-06-30.zip (Anonymised
with bittwiste, extracts to ~150MB as there's one from each OS client for comparison)
Second fix attempts.
I've enabled ctcp and disabled chimney offloading: TCP Global Parameters
Receive-Side Scaling State : enabled
Chimney Offload State : disabled
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : normal
Add-On Congestion Control Provider : ctcp
ECN Capability : disabled
RFC 1323 Timestamps : enabled
Initial RTO : 3000
Non Sack Rtt Resiliency : disabled
But sadly, no change in the throughput.
I do have a cause/effect question here, though: The graphs are of the RWIN value set in the server's ACKs to the client. With Windows clients, am I right in thinking that Linux isn't scaling this value beyond that low point because the client's limited CWIN
prevents even that buffer from being filled? Could there be some other reason that Linux is artificially limiting the RWIN?
Note: I've tried turning on ECN for the hell of it; but no change, there.
Third fix attempts.
No change following disabling heuristics and RWIN autotuning. Have updated the Intel network drivers to the latest (12.10.28.0) with software that exposes functioanlity tweaks viadevice manager tabs. The card is an 82579V Chipset on-board NIC - (I'm going to
do some more testing from clients with realtek or other vendors)
Focusing on the NIC for a moment, I've tried the following (Mostly just ruling out unlikely culprits):
Increase receive buffers to 2k from 256 and transmit buffers to 2k from 512 (Both now at maximum) - No change
Disabled all IP/TCP/UDP checksum offloading. - No change.
Disabled Large Send Offload - Nada.
Turned off IPv6, QoS scheduling - Nowt.
Further investigation
Trying to eliminate the Linux server side, I started up a Server 2012R2 instance and repeated the tests using iperf (cygwin
binary) and NTttcp.
With iperf,
I had to explicitly specify -w1m on both sides
before the connection would scale beyond ~5Mbit/s. (Incidentally, I could be checked and the BDP of ~5Mbits at 91ms latency is almost precisely 64kb. Spot the limit...)
The ntttcp binaries showed now such limitation. Using ntttcpr
-m 1,0,1.2.3.5 on the server and ntttcp
-s -m 1,0,1.2.3.5 -t 10 on the client, I can see much better throughput:
Copyright Version 5.28
Network activity progressing...
Thread Time(s) Throughput(KB/s) Avg B / Compl
====== ======= ================ =============
0 9.990 8155.355 65536.000
##### Totals: #####
Bytes(MEG) realtime(s) Avg Frame Size Throughput(MB/s)
================ =========== ============== ================
79.562500 10.001 1442.556 7.955
Throughput(Buffers/s) Cycles/Byte Buffers
===================== =========== =============
127.287 308.256 1273.000
DPCs(count/s) Pkts(num/DPC) Intr(count/s) Pkts(num/intr)
============= ============= =============== ==============
1868.713 0.785 9336.366 0.157
Packets Sent Packets Received Retransmits Errors Avg. CPU %
============ ================ =========== ====== ==========
57833 14664 0 0 9.476
8MB/s puts it up at the levels I was getting with explicitly large windows in iperf.
Oddly, though, 80MB in 1273 buffers = a 64kB buffer again. A further wireshark shows a good, variable RWIN coming back from the server (Scale factor 256) that the client seems to fulfil; so perhaps ntttcp is misreporting the send window.
Further PCAP files have been provided, here:https://www.dropbox.com/s/dtlvy1vi46x75it/iperf%2Bntttcp%2Bftp-pcaps-2014-07-03.zip
Two more iperfs,
both from Windows to the same Linux server as before (1.2.3.4): One with a 128k Socket size and default 64k window (restricts to ~5Mbit/s again) and one with a 1MB send window and default 8kb socket size. (scales higher)
One ntttcp trace
from the same Windows client to a Server 2012R2 EC2 instance (1.2.3.5). here, the throughput scales well. Note: NTttcp does something odd on port 6001 before it opens the test connection. Not sure what's happening there.
One FTP data trace, uploading 20MB of /dev/urandom to
a near identical linux host (1.2.3.6) using Cygwin ncftp.
Again the limit is there. The pattern is much the same using Windows Filezilla.
Changing the iperf buffer
length does make the expected difference to the time sequence graph (much more vertical sections), but the actual throughput is unchanged.
So we have a final question through all of this: Where is this limitation creeping in? If we simply have user-space software not written to take advantage of Long Fat Networks, can anything be done in the OS to improve the situation?

Hi,
Thanks for posting in Microsoft TechNet forums.
I will try to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.
Thank you for your understanding and support.
Kate Li
TechNet Community Support

Another TCP Reassembly Queue Issue - Help Understanding Sh IP Traffic Results

I recently started seeing the TCP Out-of-Order blurbs on my 1921/k9 routers logs. See following....
*Oct 28 06:41:32.793: %FW-4-TCP_OoO_SEG: Dropping TCP Segment: seq:-1475532578 1500 bytes is out-of-order; expected seq:2819411594. Reason: TCP reassembly queue overflow - session 192.168.10.11:58675 to 23.77.232.34:80 on zone-pair ccp-zp-in-out class ccp-protocol-http
*Oct 28 15:09:21.539: %FW-4-TCP_OoO_SEG: Dropping TCP Segment: seq:79628295 1488 bytes is out-of-order; expected seq:79600783. Reason: TCP reassembly queue overflow - session 192.168.10.25:55690 to 206.19.48.10:80 on zone-pair ccp-zp-in-out class ccp-protocol-http
*Oct 28 15:16:44.803: %FW-4-TCP_OoO_SEG: Dropping TCP Segment: seq:-1210068379 1500 bytes is out-of-order; expected seq:3084764253. Reason: TCP reassembly queue overflow - session 192.168.10.13:50591 to 107.167.193.162:80 on zone-pair ccp-zp-in-out class ccp-protocol-http
I temporarily disabled TCP Queue length logs (setting to 0) after having changed to several options including 128 and 1024 did not help. The output of Sh IP Traffic....
"Router#sh ip traffic
IP statistics:
Rcvd: 411466 total, 163659 local destination
0 format errors, 0 checksum errors, 2 bad hop count
0 unknown protocol, 1 not a gateway
0 security failures, 0 bad options, 0 with options
Opts: 0 end, 0 nop, 0 basic security, 0 loose source route
0 timestamp, 0 extended security, 0 record route
0 stream ID, 0 strict source route, 0 alert, 0 cipso, 0 ump
0 other
Frags: 0 reassembled, 0 timeouts, 0 couldn't reassemble
0 fragmented, 0 fragments, 0 couldn't fragment
Bcast: 162854 received, 415 sent
Mcast: 0 received, 0 sent
Sent: 5560 generated, 18211176 forwarded
Drop: 22 encapsulation failed, 0 unresolved, 0 no adjacency
2383 no route, 0 unicast RPF, 0 forced drop
0 options denied
Drop: 0 packets with source IP address zero
Drop: 0 packets with internal loop back IP address
0 physical broadcast
ICMP statistics:
Rcvd: 0 format errors, 0 checksum errors, 0 redirects, 0 unreachable
11 echo, 0 echo reply, 0 mask requests, 0 mask replies, 0 quench
0 parameter, 0 timestamp, 0 timestamp replies, 0 info request, 0 other
0 irdp solicitations, 0 irdp advertisements
0 time exceeded, 0 info replies
Sent: 2028 redirects, 2809 unreachable, 35 echo, 11 echo reply
0 mask requests, 0 mask replies, 0 quench, 0 timestamp, 0 timestamp replies
0 info reply, 2 time exceeded, 0 parameter problem
0 irdp solicitations, 0 irdp advertisements
BGP statistics:
Rcvd: 0 total, 0 opens, 0 notifications, 0 updates
0 keepalives, 0 route-refresh, 0 unrecognized
Sent: 0 total, 0 opens, 0 notifications, 0 updates
0 keepalives, 0 route-refresh
PIMv2 statistics: Sent/Received
Total: 0/0, 0 checksum errors, 0 format errors
Registers: 0/0 (0 non-rp, 0 non-sm-group), Register Stops: 0/0, Hellos: 0/0
Join/Prunes: 0/0, Asserts: 0/0, grafts: 0/0
Bootstraps: 0/0, Candidate_RP_Advertisements: 0/0
Queue drops: 0
State-Refresh: 0/0
IGMP statistics: Sent/Received
Total: 0/0, Format errors: 0/0, Checksum errors: 0/0
Host Queries: 0/0, Host Reports: 0/0, Host Leaves: 0/0
DVMRP: 0/0, PIM: 0/0
Queue drops: 0
TCP statistics:
Rcvd: 39 total, 0 checksum errors, 37 no port
Sent: 2 total
EIGRP-IPv4 statistics:
Rcvd: 0 total
Sent: 0 total
UDP statistics:
Rcvd: 163487 total, 0 checksum errors, 162603 no port
Sent: 695 total, 0 forwarded broadcasts
OSPF statistics:
Last clearing of OSPF traffic counters never
Rcvd: 0 total, 0 checksum errors
0 hello, 0 database desc, 0 link state req
0 link state updates, 0 link state acks
Sent: 0 total
0 hello, 0 database desc, 0 link state req
0 link state updates, 0 link state acks
ARP statistics:
Rcvd: 3651888 requests, 72 replies, 0 reverse, 0 other
Sent: 159 requests, 28560 replies (225 proxy), 0 reverse
Drop due to input queue full: 0"
Would someone be so kind as to help me understand a little about my IP Traffic and what might be going wrong? Thanks for any input. --Tim

With Queue Length set to 1024:
Router>show ip inspect statistics
Interfaces configured for inspection 4294967294
Session creations since subsystem startup or last reset 0
Current session counts (estab/half-open/terminating) [0:0:0]
Maxever session counts (estab/half-open/terminating) [0:0:0]
Last session created never
Last statistic reset never
Last session creation rate 0
Maxever session creation rate 0
Last half-open session total 0
TCP reassembly statistics
received 0 packets out-of-order; dropped 0
peak memory usage 0 KB; current usage: 0 KB
peak queue length 0

Solution for ICMP timestamp response in VAPT report

There was a vulnerability test run on our developmental server having Red Hat Enterprise Linux Server release 5.11 (Tikanga) as the OS. There is one point among others of concern here; it is to do with ICMP timestamp response. The solution suggested is:
ipchains -A input -p icmp --icmp-type timestamp-request -j DROP
ipchains -A output -p icmp --icmp-type timestamp-reply -j DROP
When I gave the command,
ipchains -A input -p icmp --icmp-type timestamp-request -j DROP
it gave the message as below
-bash: ipchains: command not found
Please suggest how to go about it.
Please revert with the reply to my query.
Regards

Thanks for your answer. The earlier question was dealing with TCP timestamp response but this is with dropping the ICMP responses. I tried this command by replacing ipchains with iptables,
iptables -A input -p icmp --icmp-type timestamp-request -j DROP
iptables -A output -p icmp --icmp-type timestamp-reply -j DROP
But the output of both the above commands is,
iptables: No chain/target/match by that name
Regards

How to define tcp wrappers for a new service in Solaris 10?

Hi all, I need to setup tcp wrappers for a third-party software product with /etc/hosts.allow.
I installed Trillium software on a new Solaris 10 server. It added this entry to /etc/inetd.conf:
dscserv0_rel1300 stream tcp nowait tsadmin /usr/bin/env env -i HOME=/home/tsadmin LOGNAME=tsadmin /opt/trilv13/TrilliumSoftware/server/metabase/bin/mtb_server
After the install, I ran inetconv and this new SMF service was created:
*# svcs -a|grep dsc*
online 13:22:57 svc:/network/dscserv0_rel1300/tcp:default
Here's the problem: After this, all new connections were denied by default. I had to disable tcp wrappers with this command:
inetadm -m svc:/network/dscserv0_rel1300/tcp:default tcp_wrappers=FALSE
I would prefer to enable tcp wrappers, and put an entry into /etc/hosts.allow, but I can't figure out what service name to put into /etc/hosts.allow. I've read through the man pages but I can't identify the service name to use for this new service, and it won't accept the FMRI or an abbreviation of it either.
How do I identify the service name to put into /etc/hosts.allow?

At OS level, before entering Sql*Plus, do :
$ EDITOR=vi; export EDITOR
$ sqlplus ......
Message was edited by:
Paul M.
Ciao Nicolas :-)

PKI Client starts to intialize, then 7 minutes later client agents go back to disabled for upwards of an hour

Starting a new thread on this as I have done much digging and no longer believe its a conflicting record issue.
I am SCCM 2012 SP1 on Server 2008 R2/SQL 2012 CU2. My "Lan" based management point is HTTP and I also have an Internet Management point that is HTTPS. All scenerios discussed in this thread are installing the 2012 SP1 client while connected
to the Lan. We have a fully functional PKI infrastructure with auto enrol enabled.
The issue at hand:
Wether I install the client during OSD, or manually install the client I get the same result. This is that the client agent upon successful install begins communicating with the HTTP management point and starts retrieving policy. If I open the
ConfigMgr applet in Control Panel I see the client shows "Client Certificate: PKI", "Connection Type: Currently Intranet". If I view actions I see all actions with the exception of Discovery Data Collection Cycle and Hardware Inventory
Cycle.
I have watched the client logs the only thing that seems to stick out is in the CcmNotificationAgent.log which shows the bgb client agent actions. it repeats the following aprox every 5 minutes:
bgb client agent is starting...
bgb client agent is disabled
TCP Listener is disabled
bgbController main thread us started with settings: [bgb enable = 0], {tcp enable = 0} and {http enable = 0}.
Wait 3600 seconds for even notification
The ClientIDManagerStartup.log files shows:
PopulateRegistrationHint: Using the Certificate selected by the current version of SCCM to set the hint. ClientIDManagerStartup 1/23/2013 5:00:51 PM 2100 (0x0834)
CCMCreateAuthHeadersEx failed (0x80004005). ClientIDManagerStartup 1/23/2013 5:00:52 PM 2100 (0x0834)
PopulateRegistrationHint failed (0x80004005), expected upon first start of non-upgrade client. ClientIDManagerStartup 1/23/2013 5:00:52 PM 2100 (0x0834)
Begin searching client certificates based on Certificate Issuers ClientIDManagerStartup 1/23/2013 5:00:52 PM 2100 (0x0834)
Certificate Issuer 1 [CN=myrootca; DC=mydomain; DC=com] ClientIDManagerStartup 1/23/2013 5:00:52 PM 2100 (0x0834)
Finding certificate by issuer chain returned error 80092004 ClientIDManagerStartup 1/23/2013 5:00:52 PM 2100 (0x0834)
Completed searching client certificates based on Certificate Issuers ClientIDManagerStartup 1/23/2013 5:00:52 PM 2100 (0x0834)
Unable to find any Certificate based on Certificate Issuers ClientIDManagerStartup 1/23/2013 5:00:52 PM 2100 (0x0834)
Raising event:
instance of CCM_ServiceHost_CertRetrieval_Status
ClientID = "GUID:b4aacc70-6de3-4829-88e0-498777c49379";
DateTime = "20130123230052.204000+000";
HRESULT = "0x87d00215";
ProcessID = 2352;
ThreadID = 2100;
ClientIDManagerStartup 1/23/2013 5:00:52 PM 2100 (0x0834)
Failed to submit event to the Status Agent. Attempting to create pending event. ClientIDManagerStartup 1/23/2013 5:00:52 PM 2100 (0x0834)
Raising pending event:
instance of CCM_ServiceHost_CertRetrieval_Status
ClientID = "GUID:b4aacc70-6de3-4829-88e0-498777c49379";
DateTime = "20130123230052.204000+000";
HRESULT = "0x87d00215";
ProcessID = 2352;
ThreadID = 2100;
ClientIDManagerStartup 1/23/2013 5:00:52 PM 2100 (0x0834)
PKI Client Certificate matching SCCM certificate selection criteria is not available. ClientIDManagerStartup 1/23/2013 5:00:52 PM 2100 (0x0834)
Generated a new Signing certificate ClientIDManagerStartup 1/23/2013 5:00:54 PM 2100 (0x0834)
Generated a new Encryption certificate ClientIDManagerStartup 1/23/2013 5:00:54 PM 2100 (0x0834)
Initializing registration renewal for potential PKI issued certificate changes. ClientIDManagerStartup 1/23/2013 5:00:56 PM 2348 (0x092C)
Succesfully intialized registration renewal. ClientIDManagerStartup 1/23/2013 5:00:56 PM 2348 (0x092C)
[RegTask] - Executing registration task synchronously. ClientIDManagerStartup 1/23/2013 5:00:56 PM 2348 (0x092C)
Read SMBIOS (encoded): 32003100350039002D0039003900320037002D0032003500360036002D0038003300320035002D0037003500340032002D0035003200370031002D0033003900 ClientIDManagerStartup 1/23/2013 5:00:56 PM 2348 (0x092C)
Evaluated SMBIOS (encoded): 32003100350039002D0039003900320037002D0032003500360036002D0038003300320035002D0037003500340032002D0035003200370031002D0033003900 ClientIDManagerStartup 1/23/2013 5:00:56 PM 2348 (0x092C)
No SMBIOS Changed ClientIDManagerStartup 1/23/2013 5:00:56 PM 2348 (0x092C)
SMBIOS unchanged ClientIDManagerStartup 1/23/2013 5:00:56 PM 2348 (0x092C)
SID unchanged ClientIDManagerStartup 1/23/2013 5:00:56 PM 2348 (0x092C)
HWID unchanged ClientIDManagerStartup 1/23/2013 5:00:57 PM 2348 (0x092C)
Windows To Go requires a minimum operating system of Windows 8 ClientIDManagerStartup 1/23/2013 5:00:59 PM 2348 (0x092C)
GetSystemEnclosureChassisInfo: IsFixed=TRUE, IsLaptop=FALSE ClientIDManagerStartup 1/23/2013 5:00:59 PM 2348 (0x092C)
Windows To Go requires a minimum operating system of Windows 8 ClientIDManagerStartup 1/23/2013 5:00:59 PM 2348 (0x092C)
Computed HardwareID=2:9C8C08C4B3E16249A2F1457998D16528B656DE30
Win32_SystemEnclosure.SerialNumber=2159-9927-2566-8325-7542-5271-39
Win32_SystemEnclosure.SMBIOSAssetTag=9344-3677-7824-5579-3797-0729-37
Win32_BaseBoard.SerialNumber=2159-9927-2566-8325-7542-5271-39
Win32_BIOS.SerialNumber=2159-9927-2566-8325-7542-5271-39
Win32_NetworkAdapterConfiguration.MACAddress=00:15:5D:0B:78:20 ClientIDManagerStartup 1/23/2013 5:00:59 PM 2348 (0x092C)
[RegTask] - Client is not registered. Sending registration request for GUID:b4aacc70-6de3-4829-88e0-498777c49379 ... ClientIDManagerStartup 1/23/2013 5:00:59 PM 2348 (0x092C)
[RegTask] - Client registration is pending. Server assigned ClientID is GUID:b4aacc70-6de3-4829-88e0-498777c49379 ClientIDManagerStartup 1/23/2013 5:01:00 PM 2348 (0x092C)
[RegTask] - Sleeping for 60 seconds ... ClientIDManagerStartup 1/23/2013 5:01:00 PM 2348 (0x092C)
RenewalTask: Executing renewal task. ClientIDManagerStartup 1/23/2013 5:01:43 PM 2620 (0x0A3C)
Begin searching client certificates based on Certificate Issuers ClientIDManagerStartup 1/23/2013 5:01:43 PM 2620 (0x0A3C)
Certificate Issuer 1 [CN=myrootca; DC=mydomain; DC=com] ClientIDManagerStartup 1/23/2013 5:01:43 PM 2620 (0x0A3C)
Based on Certificate Issuer 'MyrootCA' found Certificate [Thumbprint 52BFCF407B7071512CE65F8868D66578244ABDD9] issued to 'myclient.mydomain.com' ClientIDManagerStartup 1/23/2013 5:01:43 PM 2620 (0x0A3C)
Begin validation of Certificate [Thumbprint 52BFCF407B7071512CE65F8868D66578244ABDD9] issued to 'myclient.mydomain.com' ClientIDManagerStartup 1/23/2013 5:01:43 PM 2620 (0x0A3C)
Completed validation of Certificate [Thumbprint 52BFCF407B7071512CE65F8868D66578244ABDD9] issued to 'myclient.mydomain.com' ClientIDManagerStartup 1/23/2013 5:01:43 PM 2620 (0x0A3C)
Completed searching client certificates based on Certificate Issuers ClientIDManagerStartup 1/23/2013 5:01:43 PM 2620 (0x0A3C)
Begin to select client certificate ClientIDManagerStartup 1/23/2013 5:01:43 PM 2620 (0x0A3C)
Begin validation of Certificate [Thumbprint 52BFCF407B7071512CE65F8868D66578244ABDD9] issued to 'myclient.mydomain.com' ClientIDManagerStartup 1/23/2013 5:01:43 PM 2620 (0x0A3C)
Completed validation of Certificate [Thumbprint 52BFCF407B7071512CE65F8868D66578244ABDD9] issued to 'myclient.mydomain.com' ClientIDManagerStartup 1/23/2013 5:01:43 PM 2620 (0x0A3C)
>>> Client selected the PKI Certificate [Thumbprint 52BFCF407B7071512CE65F8868D66578244ABDD9] issued to 'myclient.mydomain.com' ClientIDManagerStartup 1/23/2013 5:01:43 PM 2620 (0x0A3C)
Raising event:
instance of CCM_ServiceHost_CertRetrieval_Status
ClientID = "GUID:b4aacc70-6de3-4829-88e0-498777c49379";
DateTime = "20130123230143.106000+000";
HRESULT = "0x00000000";
ProcessID = 2352;
ThreadID = 2620;
ClientIDManagerStartup 1/23/2013 5:01:43 PM 2620 (0x0A3C)
Client PKI cert is available. ClientIDManagerStartup 1/23/2013 5:01:43 PM 2620 (0x0A3C)
RenewalTask: Certificate has changed, initiating a renewal. ClientIDManagerStartup 1/23/2013 5:01:43 PM 2620 (0x0A3C)
Aborting any pending registration. ClientIDManagerStartup 1/23/2013 5:01:43 PM 2620 (0x0A3C)
Re-registration/renewal initiated. Restarting the service. ClientIDManagerStartup 1/23/2013 5:01:43 PM 2620 (0x0A3C)
[----- SHUTDOWN -----] ClientIDManagerStartup 1/23/2013 5:01:44 PM 2100 (0x0834)
[----- STARTUP -----] ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Machine: W21599927256 ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
OS Version: 6.1 Service Pack 1 ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
SCCM Client Version: 5.00.7804.1000 ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Client is set to use HTTPS when available. The current state is 448. ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Begin searching client certificates based on Certificate Issuers ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Certificate Issuer 1 [CN=myrootca; DC=mydomain; DC=com] ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Based on Certificate Issuer 'MyrootCA' found Certificate [Thumbprint 52BFCF407B7071512CE65F8868D66578244ABDD9] issued to 'myclient.mydomain.com' ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Begin validation of Certificate [Thumbprint 52BFCF407B7071512CE65F8868D66578244ABDD9] issued to 'myclient.mydomain.com' ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Completed validation of Certificate [Thumbprint 52BFCF407B7071512CE65F8868D66578244ABDD9] issued to 'myclient.mydomain.com' ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Completed searching client certificates based on Certificate Issuers ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Begin to select client certificate ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Begin validation of Certificate [Thumbprint 52BFCF407B7071512CE65F8868D66578244ABDD9] issued to 'myclient.mydomain.com' ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Completed validation of Certificate [Thumbprint 52BFCF407B7071512CE65F8868D66578244ABDD9] issued to 'myclient.mydomain.com' ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
>>> Client selected the PKI Certificate [Thumbprint 52BFCF407B7071512CE65F8868D66578244ABDD9] issued to 'myclient.mydomain.com' ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Raising event:
instance of CCM_ServiceHost_CertRetrieval_Status
ClientID = "GUID:b4aacc70-6de3-4829-88e0-498777c49379";
DateTime = "20130123230145.722000+000";
HRESULT = "0x00000000";
ProcessID = 3612;
ThreadID = 3888;
ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Failed to submit event to the Status Agent. Attempting to create pending event. ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Raising pending event:
instance of CCM_ServiceHost_CertRetrieval_Status
ClientID = "GUID:b4aacc70-6de3-4829-88e0-498777c49379";
DateTime = "20130123230145.722000+000";
HRESULT = "0x00000000";
ProcessID = 3612;
ThreadID = 3888;
ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
'RDV' Identity store does not support backup. ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
CCM Identity is in sync with Identity stores ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Begin searching client certificates based on Certificate Issuers ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Certificate Issuer 1 [CN=myrootca; DC=mydomain; DC=com] ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Based on Certificate Issuer 'MyrootCA' found Certificate [Thumbprint 52BFCF407B7071512CE65F8868D66578244ABDD9] issued to 'myclient.mydomain.com' ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Begin validation of Certificate [Thumbprint 52BFCF407B7071512CE65F8868D66578244ABDD9] issued to 'myclient.mydomain.com' ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Completed validation of Certificate [Thumbprint 52BFCF407B7071512CE65F8868D66578244ABDD9] issued to 'myclient.mydomain.com' ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Completed searching client certificates based on Certificate Issuers ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Begin to select client certificate ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Begin validation of Certificate [Thumbprint 52BFCF407B7071512CE65F8868D66578244ABDD9] issued to 'myclient.mydomain.com' ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Completed validation of Certificate [Thumbprint 52BFCF407B7071512CE65F8868D66578244ABDD9] issued to 'myclient.mydomain.com' ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
>>> Client selected the PKI Certificate [Thumbprint 52BFCF407B7071512CE65F8868D66578244ABDD9] issued to 'myclient.mydomain.com' ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Raising event:
instance of CCM_ServiceHost_CertRetrieval_Status
ClientID = "GUID:b4aacc70-6de3-4829-88e0-498777c49379";
DateTime = "20130123230145.752000+000";
HRESULT = "0x00000000";
ProcessID = 3612;
ThreadID = 3888;
ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Failed to submit event to the Status Agent. Attempting to create pending event. ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Raising pending event:
instance of CCM_ServiceHost_CertRetrieval_Status
ClientID = "GUID:b4aacc70-6de3-4829-88e0-498777c49379";
DateTime = "20130123230145.752000+000";
HRESULT = "0x00000000";
ProcessID = 3612;
ThreadID = 3888;
ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Client PKI cert is available. ClientIDManagerStartup 1/23/2013 5:01:45 PM 3888 (0x0F30)
Initializing registration renewal for potential PKI issued certificate changes. ClientIDManagerStartup 1/23/2013 5:01:48 PM 3928 (0x0F58)
Succesfully intialized registration renewal. ClientIDManagerStartup 1/23/2013 5:01:48 PM 3928 (0x0F58)
[RegTask] - Executing registration task synchronously. ClientIDManagerStartup 1/23/2013 5:01:48 PM 3928 (0x0F58)
Read SMBIOS (encoded): 32003100350039002D0039003900320037002D0032003500360036002D0038003300320035002D0037003500340032002D0035003200370031002D0033003900 ClientIDManagerStartup 1/23/2013 5:01:48 PM 3928 (0x0F58)
Evaluated SMBIOS (encoded): 32003100350039002D0039003900320037002D0032003500360036002D0038003300320035002D0037003500340032002D0035003200370031002D0033003900 ClientIDManagerStartup 1/23/2013 5:01:48 PM 3928 (0x0F58)
No SMBIOS Changed ClientIDManagerStartup 1/23/2013 5:01:48 PM 3928 (0x0F58)
SMBIOS unchanged ClientIDManagerStartup 1/23/2013 5:01:48 PM 3928 (0x0F58)
SID unchanged ClientIDManagerStartup 1/23/2013 5:01:48 PM 3928 (0x0F58)
HWID unchanged ClientIDManagerStartup 1/23/2013 5:01:49 PM 3928 (0x0F58)
Windows To Go requires a minimum operating system of Windows 8 ClientIDManagerStartup 1/23/2013 5:01:53 PM 3928 (0x0F58)
GetSystemEnclosureChassisInfo: IsFixed=TRUE, IsLaptop=FALSE ClientIDManagerStartup 1/23/2013 5:01:53 PM 3928 (0x0F58)
Windows To Go requires a minimum operating system of Windows 8 ClientIDManagerStartup 1/23/2013 5:01:53 PM 3928 (0x0F58)
Computed HardwareID=2:9C8C08C4B3E16249A2F1457998D16528B656DE30
Win32_SystemEnclosure.SerialNumber=2159-9927-2566-8325-7542-5271-39
Win32_SystemEnclosure.SMBIOSAssetTag=9344-3677-7824-5579-3797-0729-37
Win32_BaseBoard.SerialNumber=2159-9927-2566-8325-7542-5271-39
Win32_BIOS.SerialNumber=2159-9927-2566-8325-7542-5271-39
Win32_NetworkAdapterConfiguration.MACAddress=00:15:5D:0B:78:20 ClientIDManagerStartup 1/23/2013 5:01:53 PM 3928 (0x0F58)
[RegTask] - Client is not registered. Sending registration request for GUID:b4aacc70-6de3-4829-88e0-498777c49379 ... ClientIDManagerStartup 1/23/2013 5:01:53 PM 3928 (0x0F58)
[RegTask] - Client registration is pending. Server assigned ClientID is GUID:b4aacc70-6de3-4829-88e0-498777c49379 ClientIDManagerStartup 1/23/2013 5:01:54 PM 3928 (0x0F58)
[RegTask] - Sleeping for 60 seconds ... ClientIDManagerStartup 1/23/2013 5:01:54 PM 3928 (0x0F58)
[RegTask] - Client registration is pending. Sending confirmation request for GUID:b4aacc70-6de3-4829-88e0-498777c49379 ... ClientIDManagerStartup 1/23/2013 5:02:54 PM 3928 (0x0F58)
[RegTask] - Client is registered. Server assigned ClientID is GUID:b4aacc70-6de3-4829-88e0-498777c49379. Approval status 2 ClientIDManagerStartup 1/23/2013 5:02:54 PM 3928 (0x0F58)
After almost 7 minutes exactly, the all the client agent actions besides Machine Policy Retrieval and UserPolicy Retrieval disappear (as if client policy was Reset)
If I let the client sit for 45-minutes to an hour, everything starts working again and works fine from there on out. (cycling the SMS Agent service nor rebooting the machine makes it recover until the 45-min to an hour pass)
My command line I am using to install the client is:
ccmsetup.exe /mp:MYLANBASEDMP /UsePKICert /NOCRLCheck CCMHOSTNAME="myinternetmp.mydomain.com" SMSSITECODE=P10 SMSCACHESIZE=7000 FSP=MYLANBASEDMP CCMLOGMAXSIZE=1000000
If I take out the /usePKICert, /NOCRLCheck and CCMHOSTNAME Entries, the client install and continues to function without issue.
Anyone have any others ideas on where to troubleshoot this issue? It would make more sense if the client NEVER worked after install. Tearing my hair out trying to figure out why it starts to intialize, then reverts, then comes back online and
works fine. This happens at both my primary site MP as well as my secondary site/mp. It happens on my standard Win7 image as well as Windows 8 test machines so I dont believe its a client OS issue.

Good news! (and potentially bad news)
Good news, I received and email from the new support tech stating that indeed this issue was NOT fixed in CU3, however there is a workaround:
At present we have a workaround for the issue by setting the following registry
HKLM\Software\Microsoft\CCM\UserPolicyReRequestDelay (REG_DWORD) value: 6,000,000 (decimal).
Please add a step in your Task Sequence to add this registry value.
If you are also facing the issue while trying to install the client manually then please follow these steps
1. Install the client manually
2. Immediately disable and stop the CCMExec service (SMS Agent Host)
3. Set the following registry HKLM\Software\Microsoft\CCM\UserPolicyReRequestDelay (REG_DWORD) value: 6,000,000 (decimal)
4. Enable and set the CCMExec service to automatic
5. Start the CCMExec service
I have tested when doing a manual client install and it works perfectly..IF you make sure to stop CCMEXEC directly after the client finishes installing as denoted in step 2 above. I have every reason to believe that will will also work during a Task
Sequence base don these results. I'll be testing that soon.
The bad news: If you are using Client Push, this workaround would not work since there isn't a way to wrap a script around the installer to perform the steps above. Maybe you could add this value to all machines prior to client push using GPP's or a
startup script?
I don't currently use Client Push so its not a huge issue for me, I will just need to adjust my machine startup script to perform the steps but can see how this will still be an issue for others.
Either way, its a step in the right direction. Certainly tells me they have identified the issue and will hopefully be including a true fix in an upcoming hotfix or update.

Code signing and Timestamp Server Error

Warning: I’ve got exactly 2 days experience with AIR
but a client wants to add file IO capabilites to a
touchscreen/Flash application we developed and AIR seems to be our
only choice.
From CS4 I can publish an AIR 1.5 application with a self
signed code certificate but I get the error “Could not
connect to timestamp server”, I can then disable the
timestamp and get the warning: “If the AIR application is not
timestamped, it will fail to install when the digital certificate
expires. Are you sure you want to disable timestamping?” I
can proceed without the timestamp and everything seems to work.
So I’m wondering, when does my certificate expire? I
think I might have read 5 years. What do my clients do if they have
to reinstall the application after 5 years? Make them pay for
another copy ;-) Lastly, how do I avoid the timestamp error? Sign
up with a CA like VeriSign at $500/yr, not gonna happen for just
one client.
Sorry to sound a little testy but I could have written
exactly the same application in Director and not had to worry about
this code signing business.

You need to have a network connection for timestamping to
work. If that network connection uses a proxy server, you may also
need to set up the JRE to use that proxy (See
http://www.java.com/en/download/help/5000020600.xml).
When the certificate expires, the AIR file can't be used
anymore if there is no timestamp.
A timestamp verifies that the certificate was valid when the
AIR file was signed, so the AIR app can be installed even after the
cert expires when a timestamp is present.
Timestamps do not require a Verisign, or any other commercial
certificate. The service is free.

NX-OS disabled tcp timestamps

Similar Messages

Maybe you are looking for